MCP Servers Are the New SDK

What MCP is

The Model Context Protocol (MCP) is an open standard that lets AI applications connect to external tools and data sources through a common interface. A product ships an MCP server describing its capabilities as tools; any MCP-capable client, such as coding agents, desktop assistants, and IDEs, can then discover and call those tools on a developer's behalf. The specification and ecosystem documentation cover the protocol itself; this page covers why it belongs on a DevRel roadmap.

The DevRel-relevant property: an MCP server makes your product usable by every agent-equipped developer without them reading anything first. The agent reads the tool descriptions, the developer states an intent, and your product gets exercised. That is an onboarding surface, whether or not anyone planned it as one.

The new SDK, with the old lessons

SDKs earned a generation of DevRel attention because they were where developer experience was won or lost. MCP servers now sit in the same position, with the same failure modes:

• An SDK with confusing method names produced support tickets. An MCP server with vague tool descriptions produces agents that call the wrong tool, silently, at scale.
• An SDK with a broken install ruined evaluations. An MCP server that fails auth setup ruins evaluations that no human even witnesses.
• A well-designed SDK taught the product's mental model through its structure. A well-designed MCP server does the same for both the agent and the developer watching it work.

Treat the server as a product interface with documentation properties, not as an integration checkbox.

What to expose

Resist the temptation to mirror your entire API. An agent choosing among eighty near-identical tools performs worse than one choosing among five sharp ones, and every extra tool description consumes context the agent needs for the actual task.

A practical starting shape:

1. The three to five highest-value actions. The operations a developer would demo in their first hour: create the core resource, query it, trigger the flagship capability.
2. Docs search as a tool. A search_docs tool that returns relevant documentation snippets turns your entire knowledge base into agent context on demand. For many products this single tool outperforms everything else on the server.
3. Read-only introspection. Safe tools that let an agent inspect current state ("list projects", "get usage") make every subsequent action smarter and are low-risk to expose.
4. Deliberately excluded: destructive operations without confirmation semantics, admin surface, anything you would not want executed by a probabilistic caller. Start narrow; widen with evidence.

Auth deserves early design attention. The smoother pattern today is scoped API keys or OAuth flows that the client initiates once and reuses; anything requiring manual token surgery per session will filter out most of your audience. Whatever you choose, document the failure states exactly: agents quote error strings at their humans, so those strings are now user-facing copy.

Tool descriptions are documentation

The text fields in your MCP server are read by a model every single time it decides whether and how to call you. They deserve the same editorial care as API reference, and the same review process:

• State what the tool does, when to use it, and when not to, in plain declarative prose.
• Describe every parameter with its format, constraints, and a realistic example value.
• Say what the tool returns, including the shape of errors.
• Version and changelog the descriptions; a silent description change alters agent behavior as surely as a code change.

The DevRel work around a server

Shipping the server is the engineering half. The DevRel half determines whether anyone uses it:

1. Examples that exercise it. Publish transcripts and short videos of real tasks completed through the server, in the popular clients. Developers evaluate MCP servers by watching them work.
2. Registry and directory presence. Clients ship with registries and curated lists, starting with the official MCP registry; being listed accurately, with working install instructions per client, is table stakes distribution.
3. A quickstart per client. Installation differs across editors and assistants. One page per major client, each following the deterministic-quickstart rules from agents are your new developers, beats one generic page.
4. Feedback loop instrumentation. Log which tools get called, which fail, and where agents give up, then feed that into the same product-feedback loop DevRel already runs for humans.
5. Community support surface. Questions about the server will land in your community; make sure answers become searchable text, since those answers train the next model.

Deciding whether to build one

An honest gate, in the spirit of every other investment on this site:

Build one early when your product is developer-facing infrastructure, your API's core loop fits in a handful of operations, and your audience already lives in agent-equipped editors.

Wait when your product requires heavy human judgment per operation, when destructive actions dominate the API, or when you cannot yet resource the documentation and support work above. A half-maintained MCP server with stale descriptions actively misleads agents and burns the trust the rest of your DevRel program builds.

Whichever you choose, decide it deliberately and revisit quarterly. The measurement half of that decision lives in measuring AI-driven adoption.

Related

• Agents are your new developers for the funnel this surface serves
• Writing docs LLMs can use for the documentation discipline the server depends on
• DevRel roles and responsibilities for where this work sits in a team