MCP gives compatible AI clients a defined way to use a product’s tools and data. Products that support agent-mediated use can publish an MCP server alongside their APIs and SDKs, with its own documentation, permissions, versioning, tests, and telemetry.
What MCP is
Model Context Protocol is an open standard, launched by Anthropic on November 25, 2024, for connecting AI applications to external tools, data sources, and services. The protocol defines how an AI client (Claude Desktop, Cursor, ChatGPT, Gemini, Windsurf, custom agent) discovers and invokes capabilities exposed by an MCP server.
The protocol uses JSON-RPC over stdio or Streamable HTTP. It defines three core primitives:
- Tools. Actions the agent can invoke (call this API, run this query, send this email).
- Resources. Read-only data the agent can fetch (a file, a database record, a configuration).
- Prompts. Pre-built prompt templates the user or agent can invoke.
An MCP server gives compatible clients one shared description of the product’s capabilities. Client support still varies, so the server needs testing against each client the product claims to support.
Adoption
MCP moved from an Anthropic release to a cross-vendor protocol during 2025.
| Date | Milestone |
|---|---|
| Nov 25, 2024 | Anthropic open-sources MCP with Python and TypeScript SDKs |
| Mar 2025 | The specification adds OAuth-based authorization and Streamable HTTP |
| Mar 2025 | OpenAI adds MCP support to its Agents SDK |
| Sep 2025 | The official MCP Registry launches in preview |
| Dec 2025 | Anthropic donates MCP to the Linux Foundation’s Agentic AI Foundation |
By 2026, MCP had support from several major AI vendors and an official registry maintained as an open project. DevRel teams can treat it as a cross-vendor integration surface while still checking the capabilities of individual clients.
Why MCP matters for DevRel
MCP matters to DevRel for two practical reasons:
- One maintained interface can serve several clients. A team can expose the same tool definitions to each compatible client instead of maintaining a separate function-calling adapter for every vendor.
- Agents can act through the product. An MCP server can let a client send a message, query a database, inspect an error tracker, or invoke a deployment platform with explicit schemas and permissions.
Company-published MCP servers (mid-2026)
The pattern is now widespread. Categories where MCP servers are common:
- DevTools / observability. GitHub MCP, Sentry MCP, Datadog MCP, PagerDuty MCP, GitLab MCP, Linear MCP, Jira-adjacent MCP servers.
- Cloud and infra. Cloudflare MCP (Workers, R2, KV), AWS MCP servers across services, Microsoft Azure MCP, Google Cloud MCP, Vercel MCP.
- Communications and SaaS. Slack MCP, Notion MCP, Linear MCP, Figma MCP, Zapier-like aggregators exposing dozens of integrations through a single MCP server.
- Payments and commerce. Stripe MCP (read-only for payment investigations; write for sandboxed actions), Shopify MCP, PayPal MCP.
- Databases. PostgreSQL MCP, MongoDB MCP, Redis MCP, BigQuery MCP, Snowflake MCP, Supabase MCP, Neon MCP, PlanetScale MCP.
- Browser and automation. Microsoft’s Playwright MCP, browser automation servers.
- AI/ML services. Hugging Face MCP, Replicate MCP, Pinecone MCP, Together AI MCP.
Companies that already operate well-designed APIs have been able to ship MCP servers quickly. Teams with inconsistent APIs tend to reproduce those inconsistencies in their MCP tools, making the server a useful diagnostic for the underlying product surface.
What makes a good MCP server
Design considerations:
Tool descriptions are documentation
An agent uses a tool’s name and description field to decide whether and how to invoke it. Those fields are part of the product documentation and directly affect tool selection.
Good tool descriptions:
- State the action precisely in the present tense (“Sends a Slack message to a channel” not “Slack integration”).
- List parameters and their types explicitly.
- Note constraints (rate limits, side effects, idempotency).
- Distinguish read from write operations.
- Mention which other tools in the server are relevant adjacent capabilities.
Names matter
Agents pick tools by name plus description. Two tools called send_message and delete_message get treated as adjacent. Category-specific names such as slack_send_message, slack_delete_message, and slack_list_channels give the agent clearer distinctions.
Retry safety and idempotency
Agents retry. If your tool causes side effects on retry, the agent will produce duplicates, unintended charges, or corrupted state. Design for idempotency, expose idempotency keys, and document this in the tool description.
Distinguish read-only from write tools clearly
Read tools (list_records, get_user) are safe to invoke speculatively. Write tools (create_user, delete_record) need user consent. The MCP client typically handles consent, but your server should mark side-effecting tools explicitly and consider gating destructive operations.
Pagination, search, and large-result handling
Agents have finite context windows. Returning 10,000 records can consume the available context and prevent the client from completing the task. Implement pagination, return summaries with optional expand parameters, and expose operations that can be composed into a workflow.
Long-running operations and the Tasks pattern
For operations that take more than a few seconds, use the protocol’s task support where the target clients implement it. States such as working, input_required, completed, failed, and cancelled let clients track work without holding one request open.
Authentication and authorization
The March 2025 specification defined OAuth-based authorization for HTTP transports. Avoid hard-coded API keys in server configs, and use scoped tokens so an agent receives only the permissions it needs.
Error messages that an agent can act on
Bad: Error: invalid input. Good: Error: parameter 'channel' must start with '#' or be a channel ID starting with 'C'. Received: 'general'. Suggestion: try '#general'.
Include enough structured detail for a client to correct the request and enough explanation for a person to diagnose it.
Versioning
MCP itself versions; your server’s tools should also version. Reflect breaking changes in tool names or capability negotiation so clients can identify an unsupported schema instead of receiving an unexplained failure.
How DevRel teams build their MCP server
A practical sequence observed at multiple companies in 2025 to 2026:
- Identify the top 10 to 20 actions developers want an AI agent to perform on the product. Almost always: list, get, create, update, delete patterns plus a handful of product-specific verbs.
- Audit the existing public API. Most MCP servers wrap existing REST or GraphQL APIs. Define naming, descriptions, idempotency, and error shapes in that adapter without concealing problems in the underlying API.
- Write the server. Python and TypeScript SDKs are mature; Go, Rust, Java, C# SDKs exist.
- Test against multiple clients. Claude Desktop, Cursor, Windsurf, ChatGPT Desktop, and a custom test harness. Agents from different vendors handle edge cases differently.
- Publish. Submit the server’s metadata to the official MCP Registry, list it on your own developer portal, and document the setup steps.
- Maintain and monitor it. Version the server, document its support status, and record tool-call success, latency, and error patterns.
The official MCP Registry stores server metadata for downstream directories and marketplaces. Product documentation should remain the authoritative place for setup, permissions, and support status.
Hosted vs. self-hosted MCP servers
Hosted MCP servers suit many cloud products because the publisher can operate OAuth centrally, handle load in its own infrastructure, deploy updates without waiting for each user, and collect permitted usage telemetry.
Self-hosted MCP servers still make sense for local-machine-bound tools (browser automation, IDE integration, filesystem access), and many products ship both a hosted server for cloud capabilities and a local server for desktop integration.
The DevRel implication
An MCP server is relevant when a product can sensibly be invoked by an AI agent and meets the following conditions:
- Your product has well-defined actions agents would want to invoke.
- Those actions can be authenticated cleanly.
- The product’s value increases when agents can perform actions on a human’s behalf.
This test covers many API products, infrastructure tools, productivity services, observability platforms, and databases. A media product or an app with no useful agent actions may have no reason to publish a server.
MCP within Agent Experience
Designing for agents extends beyond MCP to tool naming, error messages, idempotency, schema clarity, and OpenAPI quality. These concerns now sit under the emerging label Agent Experience (AX). See Agent experience.
See also
Primary sources
- Anthropic, “Introducing the Model Context Protocol,” November 25, 2024.
- Anthropic, “Donating the Model Context Protocol and establishing the Agentic AI Foundation,” December 2025.
- TechCrunch, “OpenAI adopts rival Anthropic’s standard,” March 26, 2025.
- Latent Space, “Why MCP Won,” 2025 to 2026.
- MCP Registry documentation and announcement.
- modelcontextprotocol.io specification and roadmap.
- WorkOS, “Everything your team needs to know about MCP in 2026.”