aipod
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AIPOD_OWNER | No | Owner label for governance metadata. | |
| AIPOD_DOMAIN | No | Domain label for governance metadata. | |
| AIPOD_API_KEY | No | A single bearer token to protect /mcp with OAuth 2.1 protected resource. | |
| AIPOD_METRICS | No | Metrics exporter: 'otlp', 'prometheus', or 'console' (default is off). | |
| AIPOD_API_KEYS | No | Comma-separated list of bearer tokens (for key rotation / per-client) accepted by the server. | |
| AIPOD_PUBLIC_URL | No | Externally reachable base URL when behind a proxy / ingress. | |
| AIPOD_AUTH_ISSUER | No | Authorization-server URL advertised in the OAuth metadata (default: this server). | |
| AIPOD_AUTH_SCOPES | No | CSV of scopes a caller must hold (default: none). | |
| OTEL_SDK_DISABLED | No | Set to 'true' to force metrics off. | |
| OTEL_SERVICE_NAME | No | Sets the OpenTelemetry service name. | |
| AIPOD_AUTH_SCHEMES | No | CSV of authentication schemes. | |
| AIPOD_CONTAINS_PII | No | Indicates if the server contains PII (e.g., 'true' or 'false'). | |
| AIPOD_DATA_RESIDENCY | No | Data residency requirement. | |
| OTEL_METRICS_EXPORTER | No | Alternative to AIPOD_METRICS; switches on metrics (e.g., 'otlp'). | |
| AIPOD_REGULATORY_SCOPE | No | CSV of regulatory scopes. | |
| OTEL_RESOURCE_ATTRIBUTES | No | Additional OTel resource attributes. | |
| AIPOD_DATA_CLASSIFICATION | No | Data classification (e.g., PUBLIC, RESTRICTED). | |
| OTEL_EXPORTER_OTLP_ENDPOINT | No | OTLP collector endpoint when metrics are enabled. |
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": false
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": true,
"listChanged": false
} |
| completions | {} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| echoA | Echo the input message back to the caller. |
| addB | Add two numbers and describe the result. |
| get_tiny_imageC | Return text interleaved with an image content block. |
| get_annotated_messageC | Return content blocks carrying priority and audience annotations. |
| get_structured_weatherA | Return a typed Weather object so the client can validate it against the output schema. |
| get_resource_referenceC | Return an embedded resource content block for a dynamic resource. |
| get_resource_linksB | Return between 1 and 10 resource_link blocks pointing at dynamic resources. |
| trigger_long_running_operationA | Run a fake multi-step job, emitting a progress notification per step. |
| toggle_simulated_loggingA | Start or stop a background task that emits a random-level log message every 5s. |
| toggle_subscriber_updatesB | Start or stop a background task that emits resources/updated for every subscribed resource. |
| poetA | A pydantic-ai agent writes a short rhyming poem; the LLM comes from the client via MCP sampling. |
| summarizeC | A pydantic-ai agent returns a structured Summary; the LLM comes from the client via MCP sampling. |
| weather_reportB | A pydantic-ai agent turns the structured readings for a city into a short spoken-style forecast. |
| list_heroesB | List the Marvel heroes in the roster, optionally filtered by team. |
| get_heroA | Return the full record for one hero by codename (e.g. 'spider-man'). |
| find_heroes_by_powerA | Return every hero whose power list matches the given substring (e.g. 'flight'). |
| assemble_teamA | Pick the heroes whose powers best fit a described threat (deterministic). |
| hero_bioB | A pydantic-ai agent writes a short in-universe bio from the hero's facts; the LLM comes from the client via MCP sampling. |
| list_servicesA | List the application/service catalogue, optionally filtered by tier or environment. |
| get_serviceA | Return one service's catalogue entry: tier, team, dependencies, SLOs, repo. |
| check_service_healthA | Roll up synthetic metrics, SLOs, and open incidents into a healthy/degraded/down verdict. |
| error_budgetB | Compute the remaining SLO error budget and current burn rate for a service. |
| search_logsA | Search a service's (synthetic, deterministic) log stream for a substring, optionally by level. |
| list_incidentsA | List incidents, optionally filtered by status, severity, or service. |
| open_incidentB | Open a new incident against a service. Mutates server-side state. |
| update_incidentA | Move an incident to a new status (acknowledged/mitigated/resolved) with an optional note. Mutates state. |
| get_oncallA | Who is on call for a team or for the team that owns a service, plus the escalation order. |
| list_deploymentsB | List recent deployments, optionally filtered by service or status. |
| rollback_deploymentA | Roll back a deployment by id (simulated). Mutates server-side state. |
| get_runbookA | Return the runbook entries for a service, optionally narrowed to a symptom. |
| incident_postmortemA | A pydantic-ai agent drafts a short blameless postmortem from an incident's facts; the LLM comes from the client via MCP sampling. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| simple_prompt | A prompt that takes no arguments. |
| args_prompt | A prompt with a required city and an optional state. |
| completable_prompt | Pick a department, then a team member; both arguments offer completions. |
| resource_prompt | A prompt whose message list embeds a dynamic resource. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Server instructions | Overview of what this server implements. |
| Feature list | The full list of tools, resources, and prompts. |
TDQS
Scored across 31 tools
Most tools have clearly distinct purposes, especially in the service/incident cluster (list_services, get_service, check_service_health, error_budget, search_logs). A few borderline overlaps exist between the LLM-writing tools (poet, summarize, weather_report, hero_bio, incident_postmortem) and between find_heroes_by_power and assemble_team, but the descriptions are specific enough to prevent major confusion.
The majority of tools follow a readable verb_noun snake_case pattern (list_heroes, get_service, update_incident, rollback_deployment). However, there is a noticeable mix of bare nouns (poet, weather_report, hero_bio, error_budget, incident_postmortem) and bare verbs (echo, add, sumarize), so the naming convention is consistent in style but not in grammatical structure.
With 31 tools spanning math demos, protocol feature demos, hero management, and incident response, the server has too large a surface for an agent to navigate as a coherent tool set. Even if each tool is individually useful in a demo context, the count exceeds the threshold for a focused server and creates a sprawling, kitchen-sink feel.
The incident-response domain is well covered with services, health checks, incidents, oncall, deployments, runbooks, and postmortems, and the hero domain covers query/analysis workflows well with list, get, find, assemble, and bio tools. Minor gaps exist—there is no way to create or update services or heroes, and incident retrieval is only available via list_incidents—but these are workable for the apparent use cases.