The Interface Is Changing

For twenty years, the interface to observability data has been the dashboard. Metrics visualized as time series. Logs displayed in a scrollable stream. Traces rendered as waterfall diagrams. Engineers query data by writing PromQL, LogQL, SQL, or vendor-specific query languages. They navigate between pre-built dashboards and ad-hoc explorers. The expertise is in the query language. The bottleneck is the human.

That interface is changing. The Model Context Protocol (MCP), developed by Anthropic and now an open standard, defines how AI agents connect to external data sources and tools. In the context of observability, MCP means that instead of writing a PromQL query to check the p99 latency of a service, you ask an AI agent to do it. Instead of navigating between three dashboards to correlate a spike in errors with a deployment, you describe the investigation in natural language and the agent assembles the data.

Several observability vendors have already shipped MCP servers. Datadog has one. Grafana has it. Coralogix launched one in July 2025. The protocol is gaining adoption faster than most infrastructure standards because the value proposition is immediately obvious: natural language access to operational data reduces the expertise barrier for incident response and infrastructure analysis.

But there is a significant gap between a basic MCP server and an enterprise-grade AI operations layer. That gap is where the real architecture decisions live. And it is a gap that most current implementations have not yet addressed.

The Protocol Is Moving Fast. The Governance Is Not.

The Model Context Protocol (MCP) is becoming the standard for connecting AI agents to external data sources. Anthropic open-sourced the specification. Datadog, New Relic, Grafana, and Coralogix have all shipped MCP servers. AI agents running in Claude, ChatGPT, Cursor, and custom frameworks can now query observability platforms through a standardized interface.

This is a genuine shift. Natural language access to logs, metrics, and traces changes how engineers interact with observability data. But the speed of adoption has outpaced the governance conversation. Public documentation for many early MCP implementations in observability focuses on connectivity and tool access. Enterprise governance requirements,  server-side query validation, identity propagation, and auditable interaction trails are less prominently described across the market. That creates four problems that enterprise security and platform teams need to solve before approving MCP for production use.

AI Introduces a New Security Boundary

This is the point most MCP discussions miss entirely. AI agents accessing observability data are not just a new interface. They are a new security surface.

An AI agent with MCP access can query across services, environments, and time ranges in ways that individual engineers typically cannot. A single natural language prompt can generate a query that touches every service’s metrics. A chain of prompts can build a picture of the entire production architecture. The agent does not need to know what it is looking for — it will find whatever the query returns.

This is not a theoretical risk. It is a governance requirement. Organizations that enforce RBAC on their observability dashboards but grant unrestricted access through MCP have created a policy gap. The AI interface needs the same authentication, the same authorization boundaries, and the same audit trail as the human interface.

Four Problems With Basic MCP Implementations

A basic MCP server is straightforward to build. You expose an API that accepts natural language queries, translate them into the platform's query language, execute them, and return results. For a single engineer running queries from a local development environment, this works.

For a production environment with hundreds of engineers, compliance requirements, and AI agents running autonomous workflows, it does not. Here is why.

The query safety problem

AI agents generate queries based on natural language prompts. They are good at translating intent into query syntax. They are not good at understanding the operational cost of the queries they generate.

An engineer writing PromQL by hand has learned, through experience and occasionally through outages, not to run a bare metric selector without label filters. They know that querying a high-cardinality metric across all label combinations for the last 30 days will produce millions of time series and either time out or overwhelm the query engine. They know to scope their queries by namespace, service, region, and time window.

An AI agent does not have that operational intuition. If you ask it 'show me the error rate for the last month,' it will generate a query that does exactly that — across every service, every label combination, every data point. The query is syntactically correct. It is operationally dangerous.

In environments where observability infrastructure is shared across teams — which is most enterprise environments — a single unscoped query from an AI agent can degrade query performance for everyone. The agent does not know it is being reckless. It is doing what you asked.

The authentication problem

A local MCP server running on an engineer's laptop inherits whatever access credentials are configured in that environment. In a production deployment, this model breaks immediately. Different engineers have access to different data. Different teams have different RBAC policies. AI agents operating on behalf of different users need to authenticate as those users and respect their access boundaries.

A basic MCP implementation that does not authenticate requests — or that uses a single service account for all queries — creates an access control gap. Every query runs with the same permissions regardless of who initiated it. The audit trail, if one exists, shows the service account, not the user.

The audit problem

When an engineer writes a query manually, the query shows up in the platform's access logs. When an AI agent generates and executes a query through an MCP server, the entire interaction needs to be logged: who asked the question, what query the agent generated, when it executed, how long it took, what it returned, and whether it encountered errors.

For organizations in regulated industries, this is not optional. FIPS environments, FedRAMP deployments, and SOC 2 audited platforms require comprehensive query audit trails. A basic MCP server that does not log AI interactions creates a compliance gap in the observability infrastructure.

The scaling problem

A local MCP server is a single process. It handles one user's queries. An enterprise MCP server needs to handle hundreds of concurrent users, potentially thousands of concurrent AI agents, and do so with consistent latency and availability. If the MCP server goes down, every AI-assisted workflow in the organization goes dark. It needs to scale horizontally behind a load balancer with the same availability expectations as the observability platform itself.

Where the Market Is Today (March 2026)

Datadog launched its MCP Server in March 2026 as a managed remote service compatible with tools such as Claude Code, Cursor, OpenAI Codex, and VS Code. Datadog positions the server within its existing security and governance controls, including API/application key authentication and RBAC. Public materials emphasize access, tool coverage, and security/governance controls, but do not prominently describe server-side query validation controls of the kind Kloudfuse positions as Query Safety Mode.

New Relic introduced its MCP Server in public preview in November 2025, providing MCP-based access to New Relic observability data through supported tools and clients. Public documentation reviewed for this article focuses primarily on setup and tool access, and does not prominently describe server-side query validation controls or a detailed scaling model.

Grafana documents an official MCP server that gives AI assistants access to a Grafana instance, including metrics, logs, dashboards, alert rules, Incident, and Sift, with Grafana RBAC applying to tool access. Authentication supports service account tokens and username/password configurations. Grafana Cloud Traces also documents a separate MCP server path for Tempo data. Public documentation reviewed for this article does not prominently describe MCP-specific server-side query validation controls of the kind Kloudfuse positions as Query Safety Mode.

Coralogix introduced its MCP Server in July 2025 for natural-language access to observability data. Documentation describes support for logs, metrics, traces, and additional operational tools including alerts and parsing rules. Access is authenticated via per-user API key, with OAuth support added subsequently. Coralogix positions its MCP interactions as safe, auditable, and compliant. Public documentation reviewed for this article does not prominently describe a server-side query validation model comparable to Kloudfuse's Query Safety Mode.

Enterprise MCP Comparison

How Kloudfuse Approaches Enterprise MCP

We built the Kloudfuse MCP Server with the view that natural language access to observability data is an enterprise infrastructure capability, not a developer convenience. That distinction shaped every architecture decision.

Remote, centrally managed deployment

The Kloudfuse MCP Server runs within the Kloudfuse platform as a remote service. It is not a local tool that engineers install on their laptops. It is a centrally managed component of the observability infrastructure, deployed alongside the rest of the platform in the customer's VPC. This means one deployment for the entire organization, one configuration, one upgrade path.

Query Safety Mode

Every AI-generated query passes through a validation layer before execution. Query Safety Mode evaluates PromQL and LogQL queries against a set of constraints designed to prevent the most common and most dangerous patterns:

• Bare selector rejection: Queries that select a metric without any label filter are rejected. A query like http_requests_total without a namespace, service, or status_code filter would return data across every service in the cluster. Query Safety Mode requires at least one constraining label.

• Lookback ratio limits: Queries where the lookback window is disproportionate to the step interval are flagged. Asking for 30 days of data at 1-second resolution produces an unreasonable number of data points. The system enforces a maximum ratio between the lookback period and the query resolution.

• Data point caps: Queries that would produce more data points than a configurable threshold are rejected before execution. This prevents both accidental resource exhaustion and intentional abuse.

Query safety is not a suggestion. It is enforced at the server level, before the query reaches the storage engine. The AI agent receives a clear error message explaining why the query was rejected and what constraints it violated, allowing it to reformulate.

Built-in authentication

Every MCP request is authenticated against the platform's existing identity and access management system. The AI agent operates with the permissions of the user who initiated the request. If a user does not have access to a particular namespace or service, the AI agent querying on their behalf does not have access either. There is no shared service account. There is no permission escalation through the AI layer.

Complete audit logging

Every MCP tool invocation is logged with the user identity, the natural language prompt, the generated query, the execution timestamp, the duration, and the error status. Outbound API calls made by the MCP Server are also logged. The audit data is self-ingested into the Kloudfuse data store, which means it is queryable through the same interface as your infrastructure telemetry. For regulated environments, this provides a complete, queryable audit trail of every AI interaction with your observability data.

Horizontal scaling

The MCP Server scales behind a load balancer for high availability. It is not a single-process tool that fails when demand exceeds one machine's capacity. Multiple MCP Server instances handle concurrent requests with the same scaling model as the rest of the Kloudfuse platform. If the AI operations layer is critical to your incident response workflow — and it will be — it needs to be as available as the data it serves.

Specialized observability toolsets

Beyond general-purpose queries, the Kloudfuse MCP Server provides specialized tools for specific observability workflows:

• Profiling via MCP: Query and compare application performance profiles through natural language. Discover profile types, retrieve flame graphs, query time series, and compare profiles across time ranges. AI-assisted performance analysis that would normally require deep profiling expertise.

• RUM tools: Analyze frontend performance, user sessions, and browser metrics through AI. Investigate page load performance, session replay data, and user interaction patterns without navigating the RUM interface manually.

• APM breakdown tools: Analyze service execution time and downstream dependency contributions. When a service is slow, the AI agent can break down where time is spent across dependencies, databases, and external calls.

MCP and Cost Protection

Query governance is also cost governance. An AI agent without query safety controls can generate queries that scan terabytes of data. On hosted platforms with consumption-based pricing, that translates directly to cost. An engineer asking “show me all errors from last month” through an AI agent could generate a query that costs more in compute than a week of normal dashboard usage.

Kloudfuse’s query safety controls cap the damage. Lookback limits prevent month-long raw scans. Data point caps prevent unbounded result sets. Bare selector rejection prevents full-table scans. These controls protect both performance and cost simultaneously.

What Comes Next: MCP as Standard Infrastructure

MCP adoption is accelerating because it solves a real problem: operational knowledge is concentrated in a small number of senior engineers who know the query languages, the data model, and the dashboard locations. MCP distributes that knowledge through AI agents that any engineer can use.

Over the next 12 months, we expect MCP for observability to transition from a convenience feature to a standard infrastructure component. When that happens, the differentiator will not be whether your platform has an MCP server. It will be whether that server is safe to run in production.

The platforms that treat MCP as a developer tool — a local process with no authentication, no query validation, no audit trail, and no scaling story — will hit a wall when their enterprise customers try to deploy it. The platforms that treat MCP as enterprise infrastructure from the beginning will not.

We built the Kloudfuse MCP Server for the second scenario. Remote. Managed. Authenticated. Audited. Safe. Production-grade. Running in your VPC, protected by the same FIPS 140-3 validated encryption as the rest of the platform.

Because the interface to your observability data is changing. The security, governance, and operational standards should not change with it.

The Question for Your Security Team

When AI agents query your observability platform, do they go through the same authentication, authorization, and audit controls as your human users? If the answer is no, you have a governance gap. And that gap will widen as AI adoption accelerates.

AI-native observability is not a feature. It is an architecture.