MCP Observability Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_TRANSPORT | No | Transport mode for the MCP server. Options: 'stdio' or 'http'. Default is 'http'. | |
| MCP_REQUIRE_AUTH | No | Set to '1' to enable authentication on the MCP server. Default is disabled. |
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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_servicesA | List every monitored service with its team, tier and SLO targets. Call this first when you don't already know a service name — the other tools reject names that aren't in this list. |
| query_logsA | Search a service's logs within a time window. Use |
| get_metricsA | Summarise one metric for one service over a window. Returns min/mean/p95/latest plus whether the service's SLO is breached, so you get the judgement and not just the numbers. |
| get_deploysA | Deploy history, newest first. Omit |
| correlate_deploy_with_errorsA | Find whether a recent deploy explains a service's current errors. Compares error rate and p99 latency before vs. after the most recent deploy in the window, pulls matching ERROR log samples, and returns a verdict with a confidence level. This is the tool to reach for on "why is X broken" — it does in one call what would otherwise be a get_deploys + two get_metrics + query_logs chain, and it does the before/after arithmetic for you. |
| open_incidentA | File an incident. This pages the on-call engineer — use it deliberately. Requires the |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| investigate_service | A structured triage workflow for a service that looks unhealthy. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| services_resource | The service catalog: names, owning teams, tiers, SLOs. |
TDQS
Scored across 6 tools
Each tool has a clearly distinct purpose: service discovery, log search, metric retrieval, deploy history, deploy-error correlation, and incident creation. There is no overlap between these functions, and the correlator tool explicitly bundles several lower-level operations, reducing potential confusion.
All tool names follow a consistent verb_noun pattern in lowercase snake_case (list_services, query_logs, get_metrics, get_deploys, correlate_deploy_with_errors, open_incident). The verbs are specific to each action, and the naming style is uniform across the set.
Six tools is well within the ideal range for a focused observability server. Each tool earns its place by covering a distinct aspect of monitoring and operations, without unnecessary bloat or missing essential capabilities.
The set covers the core observability workflow: discovering services, inspecting logs, fetching metrics with SLO status, reviewing deploys, and opening incidents. A minor gap is the lack of incident management features beyond creation (e.g., listing or updating incidents), but this is secondary to the server's primary monitoring purpose.