The Model Context Protocol (MCP) is an open, JSON-RPC-based standard that lets AI applications connect to external tools, data sources and prompt templates in a uniform way. MCP servers expose capabilities, MCP clients inside a host application such as an IDE or chat assistant discover and call them, so one integration works across many AI applications.
What is the Model Context Protocol (MCP)?
The Model Context Protocol (MCP) is an open protocol that standardizes how AI applications access context and capabilities outside the model. Before MCP, every combination of AI application and tool needed its own integration: a coding assistant had one plug-in for the issue tracker, a chat assistant another one for the same system. MCP replaces this with a single interface. A tool or data source is wrapped once as an MCP server, and any MCP-capable application can use it.
Anthropic introduced MCP as an open-source project in November 2024. Adoption spread quickly across AI vendors, IDEs and developer tools, and in December 2025 Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, so the protocol is now governed vendor-neutrally. The specification takes inspiration from the Language Server Protocol and is published at modelcontextprotocol.io in dated revisions.
Architecture: hosts, clients and servers
MCP distinguishes three roles:
- Host: the AI application the user works with, for example an IDE, a desktop assistant or an AI agent runtime.
- Client: a connector inside the host that talks to exactly one server.
- Server: a program that exposes capabilities, for example access to a database, a ticketing system or an observability platform.
Messages are encoded as JSON-RPC 2.0. The specification defines two standard transports: stdio, where the client launches the server as a local subprocess, and Streamable HTTP for remote servers. Remote servers are typically protected with an OAuth-based authorization flow defined in the specification.
Core primitives: tools, resources and prompts
An MCP server can offer three kinds of capabilities:
- Tools are functions the model can decide to call, such as
search_errorsorrun_query. Each tool has a name, a description and a JSON schema for its input. - Resources are context and data, for example files, database schemas or documents, identified by a URI.
- Prompts are reusable, parameterized message templates that users can select.
The host lists the available tools, passes their descriptions to the model, and executes the calls the model requests. The result is fed back into the conversation, so the model can reason about it or call the next tool.
When a client connects, both sides agree on the protocol revision and the capabilities they support. This keeps clients and servers interoperable as the specification evolves: a server can add new tools, and the client discovers them without a code change. Official SDKs exist for several languages, including Python and TypeScript, so a simple server that wraps an internal API often needs only a few dozen lines of code.
Example: an observability MCP server in the IDE
An illustrative workflow: a developer asks a coding agent why checkout requests have become slow since this morning. The agent sees that an observability MCP server offers the tools find_slow_traces and list_deployments. It calls the first tool for the endpoint POST /checkout, receives the slowest traces with the dominant spans, then calls the second tool and finds a deployment shortly before the latency increase. With that evidence it opens the relevant code and proposes a fix, without the developer copying data between tools.
Security and governance
MCP gives models access to real systems, so the protocol itself stresses user consent and tool safety. Important points in practice:
- Least privilege: give each server only the scopes it needs; prefer read-only access.
- Treat tool output and tool descriptions as untrusted. Content returned by a server can carry prompt injection, and a malicious server can describe its tools misleadingly.
- Human approval for tools with side effects, and an allowlist of trusted servers.
- Audit logging of every tool call with user, server, arguments and result status.
Monitoring MCP traffic
Because agents chain many tool calls, MCP calls belong in the same trace as the LLM calls that triggered them. The OpenTelemetry GenAI semantic conventions include conventions for MCP, still marked as development, with attributes such as mcp.method.name and metrics such as mcp.client.operation.duration. That makes it possible to see which tools are slow, which fail and how often an agent calls them per task.
How Obseria helps
Obseria works on both sides of MCP. The Obseria MCP server gives coding agents read-only, scoped access to errors, traces, logs and deployments, with every tool call in the audit log. With AI observability, MCP and LLM calls of your own agents appear as OpenTelemetry traces with latency, errors and token usage.
