---
title: "Tool Scope Configuration"
description: "How default and allowed scopes behave in tool settings and which precedence rules apply."
canonical_url: "https://meingpt.com/en/docs/platform/tool-scope-policy"
language: en
---

# Tool Scope Configuration

This page explains the scope model for tool settings in meinGPT, especially:

- `default*` fields (e.g. `defaultFolderId`, `defaultCalendarId`)
- `allowed*` fields (e.g. `allowedFolderIds`, `allowedLabelIds`)
- Precedence between user input, defaults, and restrictions

## UI Location

Scope settings are available in:

- `Settings > Connections` – where you set your own `default*`/`allowed*` values. This configuration applies to the tool everywhere you use it, including directly in a chat with no assistant.
- `Settings > Tool Management` (admin-level tool availability/policy)
- Assistant > Configure Tool > `Scope` tab – an additional restriction (`scopeOverride`) that applies only to that assistant and can narrow the values from `Connections` further. A connector used directly in a chat with no assistant has no such additional restriction — only the `Connections` configuration applies there.

## Core Model

In scope configuration, fields usually mean:

1. `default*`: fallback value when no explicit scope is passed in prompt/tool call.
2. `allowed*`: restriction set for permitted resources.

Practical rule of thumb:

- No `allowed*` configured -> full access within OAuth/API permissions.
- `allowed*` configured -> access should be limited to those resources.
- `default*` configured -> preferred starting point when no explicit scope is provided.

## Scope Resolution Precedence

Typical order (tool-specific):

1. Explicit user input in tool call (e.g. specific folder ID)
2. `default*` value from tool config
3. Tool-internal fallback (e.g. Inbox, current user context)

If `allowed*` is configured, it acts as an upper bound and should limit the final selection.

## What Matters for `default` vs `allowed`?

1. `default*` is convenience, not security.
2. `allowed*` is restriction.
3. For robust boundaries, set both:
  choose `default*` values that are inside `allowed*`.

## Examples

### Google Drive

- `defaultFolderId`: starting folder for list/search without explicit folder.
- `allowedFolderIds`: limits access to selected folders.

Recommendation:
- Set `defaultFolderId` to the primary working folder.
- Set `allowedFolderIds` to approved project folders.

### Gmail

- `defaultLabelIds`: default labels for unspecific requests.
- `allowedLabelIds`: only emails within those labels.

### Outlook

- Mail: `defaultFolderId` + `allowedFolderIds`
- Calendar: `defaultCalendarId` + `allowedCalendarIds`

### Teams

- `defaultTeamId`: default team.
- `allowedTeamIds`: permitted teams.
- `allowedChannelIds`: additional channel restriction within allowed teams.

For Outlook and Teams, these fields apply only at the connection level (Settings > Connections) — they can **not** be additionally restricted per assistant, unlike Google Drive, OneDrive, and SharePoint.

### SharePoint

- `defaultSiteId`: default site used when no site is given explicitly in the tool call.
- `allowedSiteIds` (UI label "Restrict to Sites"): restricts access to the selected SharePoint sites.

**For SharePoint, the unit of restriction is the site, not the folder.** Unlike Google Drive and OneDrive (`allowedFolderIds`), the SharePoint connector cannot be restricted to a single subfolder within a site — only to whole site(s). For an actual subdirectory-level restriction with a guarantee that no other SharePoint content is pulled in, a [data source with SharePoint as its source](/en/docs/integrations/data-pools-rag) is the right tool, not the native connector.

## Important Implementation Note

Unlike [method policies](/en/docs/admin-guide/tool-access-policy), scope enforcement is currently **tool-specific**, not fully centralized yet.

This means:

- `default*`/`allowed*` semantics are consistently designed.
- Runtime enforcement depends on each tool and method implementation.

Admin recommendation until full standardization:

1. Always configure scope (`default*` + `allowed*`).
2. Limit critical write/dangerous actions via [method policy](/en/docs/admin-guide/tool-access-policy) as well.
3. Validate scope behavior for each critical tool in a test chat.

## Troubleshooting

### "Why do I still see full access although I configured restrictions?"

UI restriction state is based on configuration. Runtime behavior is tool-specific. Validate with the concrete tool in a test chat.

### "Why are scope options not loading?"

Usually missing OAuth connection or missing prerequisite selection (e.g. choose team/site first, then load channels/spaces).

### "Can I only set `default*`?"

Only for convenience. For real restriction, set `allowed*` as well.