MCP administration and limits

Updating tenant users

astrato_management_directory_update_user applies role, licence team and sign-in status in that order. Each is a separate write. All requested fields are validated before the first write, but the operation is not atomic and does not roll back earlier changes.

Updates are refused for your own account, the workspace owner, identity-provider-managed accounts, or accounts whose protection status cannot be verified.

If your workspace cannot be identified, these administration tools return a generic error before reading the directory or changing any user, without exposing internal lookup details.

A complete result has data.status: "complete" and data.applied lists the confirmed changes. If a write fails, the tool returns an MCP error (isError: true, ok: false) with its partial receipt in data: applied lists confirmed changes, failure identifies the field and whether its outcome is rejected or unknown, and notAttempted lists the remaining fields. The user snapshot is null on an incomplete result. A timeout or connection failure may mean the write succeeded without confirmation. Re-read the user before retrying; do not claim that all changes failed or that earlier changes were undone.

Not covered by MCP

• Charts and visualizations. MCP tools do not create or modify charts. Use @astrato-io/visualizations as described in the Visualizations reference.
• Advanced data queries. astrato_semantic_layer_execute_question executes a governed question by reference. astrato_data_prepare_query and astrato_data_execute_query run caller-defined queries against the published semantic layer. Neither path covers pivot or hierarchy queries, nested or OR filter groups, or querying draft changes that have not been published. Use the SDK’s query service for those.
• Semantic layer listing. The list is paged in batches of at most 50 semantic layers. Follow pagination.nextOffset while pagination.hasMore is true.

Exit-node routing

MCP data operations respect your organization’s exit-node routing configuration. When exit-node routing is enabled, eligible requests use the exit node configured for the data source. Otherwise, requests use Astrato’s gateway. The same MCP tools remain available in both cases; authorization requirements are unchanged.

Default-connection migration requires your administrator to enable both exit-node routing and legacy-engine routing for your environment. If either is disabled, connections without a selected exit node use Astrato’s gateway. With both enabled, eligible data requests for those connections use your organization’s designated migration profile. Connections with an enabled exit-node profile keep that selection, and the migration does not rewrite your connection settings. Routing failures are reported rather than retried through a different engine. Your administrator can disable migration to restore the previous routing for new requests; tools and their required permissions stay the same.

Validation summaries report error and warning counts. When a request is rejected, MCP includes available validation messages and field paths so you can identify the part of the semantic layer that needs correction.

Recurring work and Slack delivery

See Recurring Nash tasks for the preview’s delivery tools, required scopes and host-selection workflow. External assistants use their own scheduler; Astrato task lifecycle tools are reserved for in-product Nash. Company integration access remains subject to user/group and specific-destination permissions.