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 > Assistant Integrations (admin-level tool availability/policy)
• Assistant > Configure Tool > Scope tab

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.

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.