AI Admin API MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANTHROPIC_BETA | No | Comma-separated Anthropic beta headers. | |
| MCP_USER_AGENT | No | Optional user agent context for future outbound request metadata. | |
| OPENAI_BASE_URL | No | Override for tests or compatible OpenAI Admin API gateways. Defaults to https://api.openai.com/v1. | |
| OPENAI_ADMIN_KEY | No | OpenAI Admin API key (required for OpenAI static mode). | |
| ANTHROPIC_VERSION | No | Anthropic API version. Defaults to 2023-06-01. | |
| ANTHROPIC_BASE_URL | No | Override for tests or compatible Anthropic Admin API gateways. Defaults to https://api.anthropic.com/v1. | |
| MCP_HTTPS_KEY_PATH | No | PEM private-key path for local HTTPS. | |
| ANTHROPIC_ADMIN_KEY | No | Anthropic Admin API key, sent as x-api-key (required for Anthropic static mode). | |
| MCP_HTTPS_CERT_PATH | No | PEM certificate path for local HTTPS. | |
| MCP_HTTP_AUTH_TOKEN | No | Bearer token required by the MCP HTTP endpoint unless unsafe local mode is used. | |
| ANTHROPIC_OAUTH_TOKEN | No | Optional Anthropic OAuth bearer token with admin scope. | |
| MCP_CACHE_TTL_SECONDS | No | Dashboard bundle cache TTL in seconds. Defaults to 60. | |
| AI_ADMIN_CREDENTIAL_MODE | No | Only static is implemented in this runtime build. pass_through and hybrid are documented gateway contracts and fail fast. | |
| AI_ADMIN_ENABLED_PROVIDERS | No | Comma-separated openai,anthropic. Defaults to providers with static credentials present. | |
| AI_ADMIN_REQUIRED_PROVIDERS | No | Comma-separated providers that must be enabled and statically configured at startup. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| ai_admin_list_providersA | List enabled providers, health, configured reporting surfaces, and known limitations. |
| ai_admin_query_usageA | Query normalized usage facts from one or more enabled providers. Pass provider-specific options under provider_options[provider_id]. |
| ai_admin_query_costsA | Query normalized cost facts from one or more enabled providers. Pass provider-specific options under provider_options[provider_id]. |
| ai_admin_query_dashboard_bundleA | Build dashboard bundles across one or more enabled providers. Pass provider-specific options under provider_options[provider_id]. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| build_usage_dashboard | Guide an agent to request normalized dashboard bundles and build a dashboard. |
| investigate_cost_spike | Compare recent provider cost buckets against a baseline. |
| export_finance_report | Produce a finance-friendly cost report from provider-reported facts. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| providers | |
| provider-capability-schema | |
| usage-fact-schema | |
| cost-fact-schema | |
| dashboard-bundle-schema |
TDQS
Scored across 4 tools
Each tool targets a distinct concern: listing providers, querying usage, querying costs, and querying dashboard bundles. The descriptions make clear boundaries between them, and the dashboard bundle is a combined view rather than overlapping the individual queries.
All tool names follow the same verb_noun pattern with a consistent 'ai_admin' prefix. The verbs are distinct and appropriately chosen for their actions, and the naming is uniform and predictable.
With 4 tools, the server is well-scoped for its purpose. Each tool fulfills a necessary role in the admin/query domain, and the count is neither too thin nor excessive.
The tools cover the core read-side needs for AI administration: listing providers and querying usage, costs, and dashboards. However, there are no write or management operations (e.g., enabling/disabling providers), which could be considered a gap for a full admin API, though it's acceptable for a monitoring-focused server.