Nothing here mutates: no dashboard updates, no metric or log writes, no monitor deletions, which is what makes it reasonable to attach to a production tenant mid-incident. The pairing that earns its place is fetching a monitor's configuration next to the logs that tripped it, without leaving the code you are reading.
Chronosphere's MCP server for its Observability Platform. It connects a large language model to your tenant so telemetry and platform resources can be queried from the client, and it is read-only by design.
- Telemetry queries over change events, metrics, logs and traces
- Single resources by name: get_dashboard, get_monitor, get_slo, get_drop_rule, get_rollup_rule, get_mapping_rule, get_recording_rule, get_notification_policy
- List tools beside them — list_dashboards, list_drop_rules, list_mapping_rules — for finding the one you want
- Log tools that go past search: get_log fetches a message by its ID, get_log_histogram shapes a query over time
- get_events_metadata, which tells you what properties events can be queried on
- A separate documentation MCP server that serves public Chronosphere docs and needs no authentication
A Chronosphere tenant, and either an API token or OAuth. The token can be a personal access token — actions are then attributed to you and bounded by your team's permissions — or a service-account token for programmatic access; Chronosphere recommends holding it in a separate file or a Kubernetes Secret and passing it through an environment variable. OAuth needs a client that supports it, and has been tested with Claude Code, Cursor, Codex and Gemini.
One command plus a key — npx -y mcp-remote https://<org name>.chronosphere.io/api/mcp/mcp, then supply credentials