Production context for your coding agent

What is an MCP server?

The Model Context Protocol (MCP) is an open protocol that lets AI applications connect to external tools and data sources in a standard way. An MCP server exposes a set of tools, for example "search errors" or "run query", that an MCP client such as a coding agent can discover and call. The agent decides when a tool is useful, calls it and uses the result in its answer or its next step.

For observability, this means a coding agent can look at what actually happens in production instead of reasoning only about the source code in front of it.

Why observability data belongs in the IDE

When developers fix a bug, they usually switch between several tools: the editor, an error tracker, a tracing view, log search and the deployment history. Coding agents have the same problem. Without access to runtime data, they can only infer what might be going wrong from the code and from whatever the developer pastes into the chat.

An observability MCP server closes that gap. The agent can fetch the stack trace of the error it is supposed to fix, check which endpoint is slow and by how much, or find out whether the problem started with a specific release. That leads to fixes based on observed behavior and fewer round trips between tools.

How the Obseria MCP server works

The Obseria MCP server is part of the Obseria platform, next to the API and the CLI. It works with MCP-capable clients such as Claude Code, Cursor, GitHub Copilot and Windsurf. You add it to your client configuration with an Obseria API token, and the client discovers the available tools automatically.

The tools cover the data that is most useful while writing code:

• Errors: recent errors per service, release or endpoint, with stack traces and frequency.
• Traces: slow or failing traces and the spans that dominate their duration.
• Logs and metrics: queries in OQL, PromQL or SQL against Obseria Lake.
• Deployments: which version runs in which environment and what changed recently.
• Services: ownership and dependencies from TopoGraph.

All data comes from the same OpenTelemetry-based telemetry your team already sends to Obseria. There is no separate data store for the MCP server.

Example prompts

Once the server is connected, you can ask your coding agent questions like these:

What are the top errors in the checkout service since the last deploy?
Show me the stack trace for the NullPointerException in OrderService and suggest a fix.
Why is GET /api/cart slow today? Which spans take the most time?
Did error rates in payments change after release 2.14.0?
Write a test that reproduces the most frequent error in this file.

The agent decides which Obseria tools to call, retrieves the data and combines it with the code in your workspace. You see the tool calls in your client and can review them.

Security and access control

Giving an AI agent access to production data requires clear limits. The Obseria MCP server uses API tokens that you create and revoke in Obseria. By default, tokens have read-only scopes, so the agent can query data but not change alerts, dashboards or configuration. You can further restrict a token to specific projects, environments or data types.

Access is governed by the role-based access control of your organization, so an agent never sees more than the token and its owner are allowed to see. Every tool call is recorded in the audit log with the token, user, time and query. If you mask personal data in Obseria Pipeline, masked values stay masked for the agent as well.

Best practices

1. Use one token per developer or agent. It keeps the audit log meaningful and lets you revoke access precisely.
2. Keep scopes narrow. Start with read-only access to the projects a developer works on.
3. Mask sensitive data at ingest. Treat the pipeline as the first line of protection for everything downstream.
4. Review the tool calls. Check which queries the agent ran before relying on its conclusions.