MCP for DevRel | DevRel Almanac

llms.txt can help an agent find documentation. MCP gives the agent a defined way to use a product’s tools and data. For products that expect agent-mediated use, an MCP server now belongs beside the API and SDK documentation.

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.

The growth curve

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.

Notable 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

Hard-won 2025 to 2026 lessons:

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.

Idempotency is critical

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 context windows. Returning 10,000 records to an agent’s tool call is wasteful at best, harmful at worst. Implement pagination, return summaries with optional expand parameters, and design tools that an agent can compose into a workflow rather than tools that try to do everything in one call.

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'.

The error message is the agent’s chance to self-correct. Write them for agents and humans.

Versioning

MCP itself versions; your server’s tools should also version. Breaking changes should be reflected in tool names or in capability negotiation. Agents that depended on the old shape will fail predictably rather than mysteriously.

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 are thin wrappers over existing REST/GraphQL APIs. The thinness is fine; the wrapper layer is where naming, descriptions, idempotency, and error-shape live.
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.
Treat as a first-class product. Versioned, supported, monitored. Telemetry on tool-call success rate, average latency, 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:

Auth is hard. OAuth 2.1 is easier to operate centrally than to deploy to every user.
Scaling is hard. Your central infrastructure handles load better than thousands of individual user laptops.
Updates are continuous. Push a fix to the hosted server; every client gets it instantly. With self-hosted, every user has to update.
Telemetry. Hosted servers let the publisher learn how agents are actually using the tool.

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

If your product can sensibly be invoked by an AI agent, publishing an MCP server is now part of the basic DevRel offering. The criteria are:

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.

Agent-experience (AX) is downstream

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-ax.md.

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.”