# 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 {#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 {#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](/help/ops-platform.md). 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 {#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.


## Next steps

- Next: [aiopsctl (command line)](/help/aiopsctl.md)
- [All Reference pages](/help/reference/llms.txt)
- [Documentation home](/help/)