Admin MCP server
The /mcp/admin server for platform staff: its credential, the tools it offers and how catalog changes are sent.
Reference · Updated 2026-10-17 · Describes release 0.1.164
Admin MCP server
The same platform administration is available to your own coding agent over MCP, at /mcp/admin. It is the staff counterpart of the tenant MCP server, and it is documented here rather than in the tenant handbook because no tenant user can call it.
| Property | Value |
|---|---|
| URL | https://aiops.example.com/mcp/admin |
| Transport | streamable HTTP |
| Credential | an admin-scope personal access token belonging to a platform superadmin account, sent as Authorization: Bearer ntp_…, or an SSO access token for such an account |
Every admin MCP tool, including reads, requires an admin-scope PAT and a superadmin account, or an SSO identity for a superadmin. An admin token does not make an ordinary account a superadmin. Each tool then calls its fixed REST operation, which applies its normal validation and permissions. Tools backed by tenant routes retain their tenant permission requirements; the admin MCP connection does not bypass that boundary.
What the tools do
| Tool | Purpose |
|---|---|
admin_overview_stats, admin_tenant_config, create_tenant |
Platform overview, workspace configuration and standalone workspace creation. API names retain tenant; the overview distinguishes organizations, all workspaces, the Test Lab subset and direct unassigned workspaces. list_tenants and get_tenant remain aliases using the canonical response shapes. |
admin_list_groups, admin_group_detail, admin_create_group |
List, inspect or explicitly create customer organizations. Group records and directly assigned workspaces are separate from lab-parent relationships. Creating a group does not create a workspace or establish payment status. |
admin_patch_pillar (alias set_pillar) |
Turn a tenant's pillar on or off with body.enabled. Prompts and approval gates remain tenant-owned. |
create_datasource_type, patch_datasource_type, delete_datasource_type |
The connector catalog in Platform configuration. Create and patch are separate operations. |
mint_webhook_token |
Rotate a tenant's ingest token; also requires membership with pillars.manage in that tenant. An ordinary operator support grant does not include it. |
grant_feature, revoke_feature |
Deprecated compatibility operations; all features are included and these no longer change availability. |
mint_runner_token, list_runner_tokens, revoke_runner_token |
Runner-plane credentials. |
admin_audit (alias audit_query) |
The append-only log, newest first. Filters by tenant_id and an exact action; limit defaults to 100 and is capped at 500, with offset for pagination. |
admin_audit_verify |
Replay the audit hash chains: one tenant's with tenant_id, otherwise every chain including the platform chain. window (default 500, at most 10,000) or full. |
admin_audit_export |
Export one chain with its chain fields: a tenant's with tenant_id, otherwise the platform chain. Same parameters as the tenant export (fmt, since, until, action, after_seq, limit); the export is recorded in the exported chain. |
Feature grants and terms acceptance are no longer required. Webhook-token changes, organization access and workspace assignment are covered in Customers and workspaces. Assignment changes which organization administrators can manage a workspace's configuration and membership; direct memberships and operational records remain on that workspace.
Catalog changes use the REST contract
upsert_datasource_type is no longer advertised. Use create_datasource_type for a new key or patch_datasource_type for an existing one. Request-body fields belong inside body; a patch's connector key is a top-level argument. For example, patch_datasource_type accepts {"key":"prometheus","body":{"enabled":true}}.
Omitted patch fields stay unchanged. The canonical handler enforces the builtin structural-field guard and accepts enabled, default_readonly and pillars where permitted. A custom type can change its schema or template explicitly. Keys and validation behave exactly as in REST; MCP does not lowercase them or apply a separate upsert policy.
Tool results contain the HTTP status, the API result in data, and relevant headers. Existing aliases use the current advertised argument schema, including nested request bodies. Inspect the client's tool schema before using an older saved prompt.