Tool Scope Configuration

How default and allowed scopes behave in tool settings and which precedence rules apply.

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.

Attention

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 is the right tool, not the native connector.

Important Implementation Note

Unlike method policies, 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 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.

Was this page helpful?