Ship an MCP Server for Your Product (2026)

The founder's guide to making your product callable by every AI agent, before your competitors do.

In under eighteen months, the Model Context Protocol went from a single Anthropic blog post to over 400 million monthly SDK downloads and more than 10,000 live servers. That number is not a vanity metric - Anthropic. It is a map of where the buyers are moving. Every one of those downloads is an AI agent learning to reach into a product it could not touch a year ago, and every server is a company that decided its software should be usable by a machine, not just a human clicking through a screen.

Here is the uncomfortable part for most founders: your product is probably invisible to that machine. When the "user" is an AI agent that plans a task by reading a list of tool schemas, a beautiful marketing site and a slick dashboard mean nothing. The agent never renders your UI. It enumerates the tools it can call, picks the ones that match the job, and acts. If your product is not in that list, you are not a slow option or an expensive option. You are simply not in the agent's action space at all.

This guide is the practical, opinionated, end-to-end answer to a single question: how do you ship an MCP server for your product in 2026, and should you? It starts from first principles (what actually changes when your customer is an agent), then goes deep into the protocol, the clients that will call you, the companies already doing this, the exact frameworks and hosting platforms to build on, the authentication and security that will bite you if you skip it, how to get discovered, how to charge for it, and the honest cases where you should not bother. It is written for founders and builders who want the insider version, not the press-release version.

---

Contents

1. Why the buyer became an agent (the first-principles case)
2. What MCP actually is, in five minutes
3. The spec in 2026: what is stable and what is moving
4. Where your server gets called: the client ecosystem
5. Proof it works: the companies already shipping MCP servers
6. How to build one: SDKs, frameworks, and generators
7. Where to host it: remote servers, edge, and stateless design
8. Authentication and security: the part that will bite you
9. Getting discovered: registries, directories, and agent experience
10. Making money: metering, x402, and agent payments
11. Do you even need MCP? The honest counter-case
12. A 2026 shipping playbook
13. The future: agents as customers

---

The table below scores the main paths a founder can take to ship a production MCP server, weighted by what actually matters when you are trying to get a working, secure, discoverable server in front of AI agents fast. Each path is scored 0 to 10 on five criteria, and the final column is the weighted average. Read the detailed reasoning for every path in section 6 (build-it-yourself frameworks) and section 7 (hosting), but use this table to see the whole field at a glance. The scores reflect the state of each tool as of July 2026, and this space moves quarterly, so treat them as a snapshot, not gospel.

How to read the criteria. Speed to ship (25%) rewards how fast you get from nothing to a working remote server. Remote plus auth readiness (25%) rewards Streamable HTTP transport and OAuth 2.1 support out of the box, because a local-only or unauthenticated server reaches almost no one and passes no directory review. Scale and cost (20%) rewards serverless economics, a real free tier, and stateless designs that scale horizontally. Distribution (15%) rewards native paths into registries and one-click install. Flexibility (15%) rewards custom logic, language choice, and freedom from lock-in. Notice the compression: the top four paths sit within a single point of each other, which tells you the decision is less about "which is best" and more about "which trade matches your team." A founder with a Next.js app should not agonize; a data-heavy Python shop should not force TypeScript.

---

1. Why the buyer became an agent (the first-principles case)

The instinct when you hear "ship an MCP server" is to file it under integrations, somewhere near webhooks and a public API, a nice-to-have you get to eventually. That instinct is wrong, and understanding why requires going back to what a product actually is. A product is a way to deliver an outcome: a payment captured, a database provisioned, a support ticket resolved, a design turned into code. For twenty years, the standard way to package that outcome was a graphical interface a human learns to operate, backed by an API for the technical minority who wanted to automate. The human UI was the front door and the API was the loading dock.

The structural shift of 2025 and 2026 is that a fast-growing share of the work is no longer done by a human at the front door. It is done by an AI agent that plans by reading machine-readable descriptions of what it can do and then acting. When the actor is an agent, the graphical interface is not just less important, it is completely invisible. The agent does not squint at your dashboard or admire your onboarding flow. It receives a list of tool definitions, each with a name, a description, and an input schema, and it reasons over that list. Your product is legible to the agent if and only if it appears in that list. This is the whole game, and the official protocol docs put the metaphor plainly: MCP is meant to be a USB-C port for AI - Model Context Protocol. A device without the right port is not slow to connect. It does not connect.

Reason forward from there and the economics get sharp. Before a shared protocol existed, connecting a set of AI models to a set of tools was an N times M problem: every model or agent needed a bespoke connector for every tool, and every tool vendor had to court every agent one integration at a time - WorkOS. A single open protocol collapses that to N plus M: build one server, and any compliant client can call it. That collapse is exactly why the standard spread so fast, and it is why "we will add agent support later" is a strategic error rather than a backlog item. The distribution surface is being wired right now, and the products that are legible get called; the ones that are not get skipped in favor of a competitor that is.

Anthropic framed the original problem in its launch announcement with a line worth internalizing: even the most capable models are constrained by their isolation from data, trapped behind information silos, where every new source demands its own custom implementation - Anthropic. Flip that sentence around and it becomes a growth thesis for your company. The intelligence is now cheap and abundant. The scarce, valuable thing is a clean, safe, machine-callable path to a real outcome that the model cannot produce on its own. That is precisely what your product is. Shipping an MCP server is how you plug the abundant intelligence into your scarce capability, and it is a close cousin of the work we covered in getting your product cited and used by AI systems in our guide to getting your site cited by ChatGPT and Claude.

There is a second, quieter reason the timing matters. The people building companies today are increasingly doing it with AI in the loop from day one, a pattern we broke down in the AI-native company tech stack. When your own build process is agent-driven, exposing your product as an MCP server is not extra work bolted on at the end. It is the natural interface for a world where both your builders and your customers increasingly work through agents. The old model put the human UI first and the machine interface last. The new model treats the machine interface as a primary surface, on equal footing with the screen a human sees.

The conceptual picture below is the mental model to hold for the rest of this guide. On the left is the product built for a human at a keyboard. On the right is the same product made legible to an agent that reads schemas and acts. They are not mutually exclusive, and the best products in 2026 ship both. But only one of them is reachable by the fastest-growing category of user, and that is the one most founders have not built yet.

2. What MCP actually is, in five minutes

Before the strategy, the mechanics, because a founder who cannot explain MCP in plain language will make bad decisions about it. The Model Context Protocol is an open standard, created by Anthropic and open-sourced in November 2024, that defines a common way for an AI application (the host) to connect to external systems (servers) and use their capabilities - Anthropic. It sits on top of the well-understood JSON-RPC 2.0 message format, which means it is not exotic; it is structured request-and-response over a transport you already understand. If you have ever built or consumed a web API, you already have the mental furniture to understand MCP.

The protocol splits into two layers worth keeping straight. The data layer defines the vocabulary: what a tool is, what a resource is, how a client discovers them, and how results come back. The transport layer defines how the bytes actually move between the client and your server. Almost every design decision you will make (local versus remote, stateful versus stateless, how you authenticate) lives in the transport layer, while almost everything the agent actually cares about (which tools exist and what they do) lives in the data layer. Getting this separation clear early prevents a lot of confused architecture later.

On the server side, MCP gives you three primitives to expose, and choosing among them is most of the design work - Model Context Protocol:

• Tools are executable functions the agent can call, like create_invoice or search_orders. This is where the real power lives.
• Resources are read-only context the agent can pull in, like a document, a schema, or a config file.
• Prompts are reusable templates that guide the agent toward the right way to use your server.

For most founders shipping their first server, tools are ninety percent of the value and the place to start. Resources and prompts are how you make a good server great: resources let the agent read your product's current state before it acts, and prompts let you nudge it toward correct, safe usage rather than leaving it to guess. The temptation is to expose everything you have as tools on day one, but that is a mistake we will return to in the security and bloat sections. The right instinct is a small, sharp set of tools that map to real outcomes, not a mechanical dump of every endpoint in your API.

There are also client-side primitives that flow the other direction, from your server back to the host, and they change the feel of an integration. Elicitation, added in the June 2025 revision, lets your server pause and ask the user a structured question mid-task, so a booking tool can ask "which of these three dates?" instead of failing - ForgeCode. Sampling let a server ask the host's model to generate text on its behalf, and roots and logging rounded out the set. These are powerful, but note the moving-target warning that runs through this whole guide: the newest spec revision deprecates several of them, which we cover next. For a first server, you can safely ignore the client primitives and focus on shipping excellent tools.

The single diagram below is the shape of every MCP integration. An AI host (Claude, ChatGPT, Cursor, and others) speaks to your server over a transport, your server exposes tools, resources, and prompts, and behind those your existing product does the real work. Nothing about this requires you to rebuild your product. It requires you to put a thin, well-described, secure interface in front of it, aimed at a machine reader.

To see the origin story and the reasoning from the people who built the protocol, the official Anthropic explainer with MCP co-creator David Soria Parra is the best primary source, and it doubles as a clear introduction to why a standard was necessary at all.

3. The spec in 2026: what is stable and what is moving

The most important operational fact about MCP is that it versions by date, not by semantic version, and the dates matter because the protocol has changed meaningfully every few months. The lineage runs from the initial 2024-11-05 release, through 2025-03-26, 2025-06-18, and 2025-11-25, to the current 2026-07-28 revision, whose release candidate was locked in May 2026 - Model Context Protocol Blog. Anything you read that predates roughly the last twelve months should be treated as potentially structurally wrong, not merely dated, because the transport model and the authorization model have both been reworked inside that window. A founder who copies a 2024 tutorial can build something that no modern client will talk to.

Two revisions carry most of the weight for someone shipping today. The 2025-03-26 revision introduced Streamable HTTP as the transport for remote servers, replacing the older two-endpoint HTTP-plus-SSE design, which is now documented only as deprecated for backwards compatibility - Model Context Protocol. The 2025-06-18 revision reclassified your MCP server as an OAuth 2.0 Resource Server, added structured tool output and elicitation, and removed JSON-RPC batching - ForgeCode. That auth change is the single most consequential shift for anyone shipping a public server, and it gets a full treatment in section 8. The practical takeaway is that "remote plus OAuth over Streamable HTTP" is the shape of a modern MCP server, and the SSE-based patterns you may have seen are on their way out.

The current 2026-07-28 revision is the biggest structural release to date, and it pulls in a direction that is very good news for founders who want cheap, scalable hosting. It moves MCP from a stateful, bidirectional protocol to a stateless request-and-response model, which means servers can run on serverless and edge infrastructure without holding a long-lived connection open per client - Anthropic. In the same release it hardens authorization to align with production OAuth 2.0 and OpenID Connect (the identity systems enterprises already run, like Entra and Okta), and it graduates MCP Apps and Tasks into a formal extensions framework. The cost of that progress, and it is a real cost, is that the same revision deprecates the Roots, Sampling, and Logging client primitives on a twelve-month sunset. Features you build on those need a migration plan.

Governance is the other half of the 2026 story, and it changes the risk calculus. In December 2025, Anthropic donated MCP to the Linux Foundation's new Agentic AI Foundation, where it sits alongside Block's goose agent framework and OpenAI's AGENTS.md as founding projects - Anthropic. The platinum-tier backers read like a who's who of the industry: Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI - Block. Technical governance sits with individual maintainers rather than reserved company seats, with a group of nine core and lead maintainers inside a wider community of dozens - Model Context Protocol. For a founder, the signal is durability: a standard backed and governed this broadly is unlikely to be abandoned, which makes building on it a safer long-term bet than any single vendor's proprietary connector format.

Be honest about the flip side, because a good guide does not oversell. "Vendor-neutral" governance does not mean vendor-independent; the same eight large companies fund the foundation, and the spec is still iterating fast enough that a server shipped today needs a version-negotiation strategy and a maintenance budget. The 2025-06-18 auth revision was not backward compatible with 2025-03-26 clients, and the 2026-07-28 statelessness change will strand code that depends on the deprecated primitives. The practical defense is to pin to a dated spec version, use a maintained SDK that tracks the spec for you, and plan to revisit your server a couple of times a year. This is the same discipline any founder applies to a fast-moving dependency, and it is the price of being early to a distribution channel that is still being poured.

4. Where your server gets called: the client ecosystem

A server nobody can call is a hobby project. The reason to ship an MCP server rather than any other kind of integration is that a single, well-built server is now reachable across nearly every major AI application at once, and that reach is the entire distribution argument. The turning point was March 2025, when OpenAI adopted MCP across its products, with Sam Altman posting that "people love MCP and we are excited to add support across our products" - TechCrunch. When the two largest AI labs back the same integration standard within four months of its release, you are no longer betting on a protocol. You are building for an established channel.

The Claude side of the ecosystem is the most direct path because Anthropic created MCP and treats it as first-class. Anthropic shipped remote MCP support (branded Integrations) in May 2025 with ten launch partners, then opened the Connectors Directory in July 2025, a browsable catalog where a Claude user adds your server in one click - Anthropic. That directory now lists over 950 servers and is used by millions of people daily - Anthropic. Custom remote connectors work across Claude on the web, Claude Desktop, the Claude Code agent, and Claude Cowork, so one hosted server reaches every Claude surface. The Claude API even exposes a direct MCP connector, letting developers wire your server into their own Claude-powered apps with an mcp_servers parameter and no separate client code, which we return to in section 6.

The ChatGPT side is where the reach numbers get large. At its October 2025 DevDay, OpenAI announced the ChatGPT Apps SDK, built on MCP, letting developers make apps discoverable and callable inside ChatGPT conversations, with launch partners including Booking.com, Canva, Coursera, Expedia, Figma, Spotify, and Zillow - VentureBeat. At the same event, OpenAI put ChatGPT's weekly active users at 800 million - Entrepreneur. That is the addressable audience for an MCP-based ChatGPT app, and OpenAI opened third-party app submissions in December 2025. For custom, unlisted connectors, ChatGPT Developer Mode lets a user connect any MCP server on paid tiers. The DevDay keynote is the primary source and is worth watching for the live demos of apps running inside the chat surface.

Beyond the two labs, MCP support is now table stakes across the developer tools where your technical users live, and the dates tell the story of how fast it became universal. Google announced fully-managed MCP servers for its cloud services in December 2025, with MCP co-creator David Soria Parra quoted on the collaboration - Google Cloud. The most consequential milestones for a founder to know are these:

• VS Code reached MCP general availability in July 2025 through GitHub Copilot's agent mode - GitHub.
• Cursor supports remote MCP servers over Streamable HTTP with one-click install and auto-reconnect - TrueFoundry.
• Microsoft Copilot Studio made MCP generally available so enterprise makers add servers in a few clicks - Microsoft.
• JetBrains IDEs act as MCP clients from version 2025.2 onward - JetBrains.

The strategic implication of that list is the whole point of this section. You do not build an integration for Claude, a separate one for ChatGPT, a third for Cursor, and a fourth for Copilot. You build one MCP server and it becomes reachable across all of them, which is exactly the N-plus-M economics from section 1 made concrete. Be clear-eyed about the friction, though: most of these hosts gate custom or remote connectors behind paid tiers and, for the curated directories, a real submission and review process. So "reachable by every AI app" is the ceiling, not an automatic outcome. The work in the rest of this guide is how you clear that bar, and it is the same class of distribution thinking we applied to third-party surfaces in our roundup of the top integrations for your online business.

5. Proof it works: the companies already shipping MCP servers

Abstract arguments only go so far, so look at who has actually done this and what they exposed, because the pattern across the leaders is instructive. The clearest developer-facing example is GitHub, whose remote MCP server went generally available in September 2025 at a hosted endpoint, backed by an open-source repository that has drawn roughly 31,900 stars and exposes more than twenty toolsets covering repositories, issues, pull requests, actions, and code security - GitHub. GitHub did not build a thin wrapper. It exposed the meaningful surface of its platform as callable tools, then hosted it so any MCP client could reach it over Streamable HTTP with OAuth, no local install required.

Payments and commerce moved early and aggressively, because that is where agents doing real work create real value. Stripe runs a hosted server at mcp.stripe.com that lets agents read and write across the Stripe API using generic tools plus helpers like search_stripe_documentation and an implementation planner, authenticating via OAuth or a restricted API key as a bearer token - Stripe. PayPal shipped one of the first remote commerce servers, exposing order creation, invoicing, refunds, and subscriptions for agentic checkout - PayPal. If you are thinking about how money moves through an agent-driven product, this is the frontier, and it connects directly to the choices we mapped in our guide to the best payment platforms for your business.

The SaaS and productivity category is where the design lessons are sharpest, and one example is worth studying closely. Block (the company behind Square) reduced its entire Square API surface, more than thirty APIs and two hundred endpoints, down to just three MCP tools using a layered tool pattern - WorkOS. That is the opposite of the naive approach of exposing every endpoint as a tool, and it is the single most important design instinct in this whole space. A handful of production servers make the range concrete:

• Linear launched at mcp.linear.app in May 2025 with a separate read-only endpoint - Linear.
• Notion shipped a hosted server tuned for token efficiency using Notion-flavored Markdown - Notion.
• Figma released a Dev Mode server exposing exactly three tools (code, image, variables) to bring design context into coding agents - Figma.
• Zapier launched a hosted MCP giving agents governed access to more than 8,000 apps through one URL - Zapier.

Look at the numbers in that list and the philosophy jumps out. Block chose three tools. Figma chose three. Notion optimized its output format to spend fewer of the model's tokens per call. These are not accidents of scope; they are deliberate decisions that fewer, sharper, well-described tools produce better agent behavior than a sprawling menu. An agent choosing among three clear tools picks correctly far more often than one drowning in two hundred, and every tool you expose consumes context and adds a chance of the wrong selection. The winning servers treat tool design like product design, and that is a lesson a founder can apply on day one regardless of which platform they build on.

The Notion example also illustrates the architecture in a way a diagram makes concrete. Notion's own explanation of its hosted server shows the request path from the AI assistant, through the MCP server, into the workspace and back, and it is worth seeing because your server will look structurally identical: a described interface in front of your real data, with the token-efficiency and permission decisions made deliberately at the boundary.

One more pattern in this section deserves a founder's attention, because it changes the build-versus-buy math. A large share of the marquee servers, including Atlassian, PayPal, Sentry, Webflow, Asana, and Intercom, were built and hosted on Cloudflare's remote-MCP toolkit rather than from scratch - Cloudflare. "Company X shipped an MCP server" very often means "company X used a platform's remote-MCP building blocks and shipped in days." That is good news for a solo founder or small team: you are not competing against a bespoke, hand-rolled protocol implementation. You are competing on which outcomes you expose and how safely you expose them, and the plumbing is increasingly a solved, commoditized problem, which is exactly what the next two sections are about.

6. How to build one: SDKs, frameworks, and generators

With the why settled, the how comes down to a fork in the road: build from the raw SDK, use an opinionated framework, or generate a server from an interface you already have. All three are legitimate, and the right choice depends on your existing stack and how much control you want. The foundation under everything is the set of official SDKs, of which there are now ten under the Model Context Protocol GitHub organization: TypeScript, Python, Java, Kotlin, C#, Go, Ruby, Rust, Swift, and PHP - Model Context Protocol. Several are co-maintained with the companies whose ecosystems they serve: the Go SDK with Google, C# with Microsoft, Java with the Spring AI team, Kotlin with JetBrains, and Ruby with Shopify. That co-maintenance is a durability signal, because it means the SDK you build on is backed by a company with a direct stake in keeping it current.

For most founders the decision collapses quickly to language. If your stack is Python, the default is FastMCP, whose original 1.0 core was merged into the official Python SDK and whose standalone 2.x and 3.x line adds the production features you actually need: server composition, proxying, testing, and, critically, enterprise authentication and OpenAPI generation - jlowin.dev. FastMCP's own README claims it powers roughly seventy percent of MCP servers across all languages with about a million downloads a day - GitHub. Treat that as a vendor claim rather than an audited figure, but the roughly 27,000 GitHub stars are real and the momentum is genuine. If your stack is JavaScript, the official TypeScript SDK (about 13,000 stars) is the base, and a small ecosystem of frameworks like xmcp and mcp-framework adds file-system routing, hot reload, and scaffolding on top of it.

The overall shape of the builder ecosystem is easiest to see as a chart. The point is not that one number beats another; it is that the attention is concentrated in a handful of mature tools (the GitHub server itself, FastMCP, and the two flagship SDKs), which is where a founder should start rather than reaching for something obscure.

The third path, generation, is the one most founders underrate and the one that often wins on speed. If you already have a clean API, you may not need to write a server by hand at all. Stainless generates an MCP server for free from an OpenAPI spec, shipping a sandboxed code-execution tool that runs against your SDK plus a documentation-search tool - Stainless. Speakeasy generates and hosts servers from specs through its Gram product. And if you run a Python API, FastAPI-MCP mounts your existing FastAPI endpoints as MCP tools with essentially zero configuration, preserving your schemas and docs - GitHub. Generation trades some bespoke control for a dramatic speed gain, and for a founder whose product is already a well-designed API, it can turn a multi-week project into an afternoon.

There is a fourth path that non-technical founders should know exists, sitting at the managed end of the spectrum. Rather than assembling any of the above, you can have the whole product, including its agent-facing interface, built for you. Platforms like Founden take a description of a company and generate the website, app, billing, and admin, and expose the result through an API and an MCP server (via a founden-mcp command and a /mcp endpoint) so any assistant like Claude or Cursor can build and operate the company over chat - Founden. That is the same idea as everything else in this section, hosted and opinionated: you trade hand-level control of the protocol for speed and a done-for-you agent surface. It sits alongside the build-it-yourself and generate-from-your-API paths as one legitimate option among several, and it fits the broader thesis we developed in building software with AI and how to build an app with AI.

If you are building on the Claude side specifically, two Anthropic tools are worth naming. The Claude Agent SDK lets you wrap custom tools as an in-process MCP server with a single create_sdk_mcp_server call, so the tools run inside your agent without spawning a separate process - Anthropic. And the Claude API MCP connector lets any Claude-powered application call a remote MCP server by URL directly from the Messages API, using the current mcp-client-2025-11-20 beta header and an mcp_toolset entry that supports tool allowlists and denylists - Anthropic. These matter because they mean a server you host is not just reachable by end users inside Claude; it is reachable by every developer building on Claude too, which multiplies its distribution. For the wider question of which model to point at your server, our guide to the best AI model to build your app covers the current Claude, OpenAI, and Google options in depth.

7. Where to host it: remote servers, edge, and stateless design

Building the server is half the job; the other half is running it somewhere agents can reach it reliably and cheaply. The first decision is transport, and it is nearly always made for you by whether the server is local or remote. Use stdio when the server runs on the same machine as a single user, launched as a child process, with no network and no transport-layer auth. Use Streamable HTTP for anything remote or multi-user, because it is the only transport that supports authentication, horizontal scaling, and stateless deployment - Model Context Protocol. The industry has decisively moved toward remote: by 2026, remote servers accounted for the large majority of the most-searched servers on the directories, and marquee vendors are actively retiring their local-only variants.

The stateless direction of the 2026-07-28 spec is the single most important architecture trend for hosting economics, and it is worth understanding why it matters for your bill. A stateful server holds a session open per client, which forces sticky routing, a shared session store, and reconnection logic, all of which fight against serverless scaling. A stateless server treats each request as independent, so any request can land on any instance with no shared state, which is exactly what serverless and edge platforms are built for - Vindler. The payoff is not theoretical. When Vercel migrated a production MCP server from the old persistent-connection SSE transport to Streamable HTTP, it cut CPU usage by more than fifty percent even as usage grew - Vercel. That is the difference between a server that scales cheaply and one that quietly bleeds money on idle connections.

On the platforms themselves, three names cover most real deployments and each has a distinct sweet spot. Cloudflare billed itself as the first platform for remote MCP servers and gives you the most complete toolkit: the McpAgent class, the workers-oauth-provider for OAuth 2.1, and, as of Agents SDK v0.20, fully stateless support for the newest spec - Cloudflare. Its pricing is founder-friendly: a free tier of 100,000 requests a day, and a paid tier from five dollars a month that includes ten million requests. Vercel is the fastest path if you already run a Next.js app, because mcp-handler drops an MCP server into a single route with built-in OAuth, and Fluid compute suits MCP's bursty, idle-heavy traffic. Smithery combines hosting with a registry, though it ended free hosting for new servers in March 2026, a reminder that "free" hosted tiers are tightening as the ecosystem monetizes.

For teams that prefer conventional infrastructure, a couple of options round out the field, and the choice hinges on whether you need per-session state or steady always-on load. Container-style hosts like Render and Fly.io run a standard always-on service, which can be cheaper and steadier than serverless for sustained load, with Fly billing per second and auto-suspending to near-zero idle cost. Docker offers a three-part stack (a catalog of 200-plus verified server images, a one-click Toolkit in Docker Desktop, and an open-source Gateway for routing and auth) that leans on container isolation and secure secrets - Docker. And for one-click desktop distribution specifically, MCP Bundles (the .mcpb format, formerly .dxt) package a local server plus its dependencies into a single file that installs in Claude Desktop with no developer tools required.

The counterweight to all this convenience is that stateless is not free of trade-offs, and a founder should choose deliberately rather than cargo-culting the newest pattern. Going stateless means giving up the deprecated server-initiated primitives and moving any durability needs to the new Tasks extension. Serverless cold starts and per-invocation CPU caps can bite a heavy AI workload inside a tool call, which is exactly where an always-on container earns its keep. And Cloudflare's Durable-Object-per-session model, powerful as it is for stateful use cases like carts and workflows, runs against the stateless grain of the 2026 spec and adds its own cost. The right answer is the boring one: if you do not need per-session state, host stateless and cheap; if you do, pay for it deliberately. This is the same infrastructure-fit reasoning we applied to storage in our guide to the best databases for your product.

8. Authentication and security: the part that will bite you

This is the section founders skim and later regret skipping, so read it carefully, because the security story of MCP in 2025 and 2026 is a series of real, public, expensive incidents. The protocol amplifies ordinary application-security mistakes to a dangerous degree, because an AI agent operating your tools has both broad reach and ambient authority, and it will follow instructions it finds in places you did not expect. The lesson from every incident below is the same: MCP does not introduce exotic new vulnerabilities so much as it removes the human judgment that used to catch old ones.

Start with authorization, because it is now a formal part of the spec and the source of the most common shipping mistakes. As of the 2025-06-18 revision, your MCP server is an OAuth 2.0 Resource Server: it publishes Protected Resource Metadata (RFC 9728) at a well-known path, returns a 401 with a WWW-Authenticate header pointing to the authorization server, and requires clients to bind each token to your specific server using Resource Indicators (RFC 8707) - Auth0. The single load-bearing rule, stated verbatim in the official security guidance, is that "MCP servers MUST NOT accept any tokens that were not explicitly issued for the MCP server" - Model Context Protocol. Accepting a token minted for a different audience is the classic confused-deputy setup, and forwarding a user's raw token downstream is the anti-pattern the spec forbids; the correct move is token exchange, where a gateway swaps the inbound token for a new one scoped to exactly your server.

Then there is the class of attacks that has no equivalent in a normal API, because it exploits the fact that the agent reads your tool descriptions as instructions. Invariant Labs disclosed tool poisoning in April 2025: malicious instructions hidden inside a tool's description are read by the model but invisible to the user, causing an agent to leak files or secrets while returning a normal-looking response - Invariant Labs. The same research documented tool shadowing (a malicious server overriding a trusted tool) and rug pulls (a tool's description mutating after the user approved it). A related trick, line jumping, plants immediate-action instructions in tool descriptions so a server influences the agent the moment it connects, without any tool ever being explicitly called. These are prompt-injection problems wearing a tooling costume, and no amount of OAuth hardening fully solves them.

The incidents got real and they got expensive, and naming them is the fastest way to make the risk concrete for a founder deciding how much hardening to do. A short, sobering list from 2025:

• CVE-2025-6514 (CVSS 9.6): the widely used mcp-remote adapter, downloaded over 437,000 times, could be tricked by a malicious server into running arbitrary OS commands - JFrog.
• CVE-2025-49596 (CVSS 9.4): Anthropic's own MCP Inspector debugging tool allowed unauthenticated remote code execution, with hundreds of exposed instances found online - Oligo Security.
• Asana disabled its MCP feature for nearly two weeks after a logic flaw exposed data across roughly 1,000 customer organizations - BleepingComputer.
• The Supabase "lethal trifecta" showed a prompt-injection payload in a support ticket causing an agent to dump a sensitive tokens table - Simon Willison.

Take those together and the pattern is unmistakable: the failures were tenant-isolation bugs, shell-injection bugs, and over-privileged credentials, all ordinary appsec problems made catastrophic because an autonomous agent, not a cautious human, was driving. Independent testing reinforces that this is systemic rather than anecdotal: one assessment found that a large fraction of MCP servers were vulnerable to command injection, most used file operations prone to path traversal, and a meaningful share were exposed to server-side request forgery - Practical DevSecOps. The chart below shows the exposure rates, and they should make you treat security as a launch requirement, not a later hardening pass.

So how do you ship a server that does not become the next headline? The defensive playbook is well understood and mostly boring, which is good news. Scope credentials to the minimum, run destructive operations behind read-only defaults or human confirmation, never surface secrets in tool outputs, validate every input at the boundary, and block private-network requests during OAuth discovery to prevent the cloud-metadata SSRF trick the spec explicitly warns about. Use the official MCP Inspector (patched) to test before you ship, run the open-source MCP-Scan from the team that found tool poisoning, and treat the OWASP MCP Security Cheat Sheet as your checklist - OWASP. The single most protective decision, and the one non-technical founders should insist on, is to keep the exposed surface small and read-heavy at launch: fewer tools, least privilege, and a human in the loop before anything irreversible. If you are using a managed platform to ship your product and its server, this is exactly the kind of hardening you are paying the platform to get right on your behalf.

9. Getting discovered: registries, directories, and agent experience

A secure, well-built server that nobody can find is only marginally better than no server at all, so discovery is a first-class part of shipping, not an afterthought. The canonical starting point is the official MCP Registry, which launched in preview in September 2025 as an open catalog and API that acts as the single source of truth other directories build on - Model Context Protocol Blog. You publish by describing your server in a server.json file, and downstream clients and sub-registries federate from the central record, so in principle one canonical listing can propagate to many places. The registry grew fast, from a few hundred entries at launch to close to two thousand within ten weeks and into the many thousands by mid-2026, which is a useful proxy for how quickly the ecosystem is professionalizing.

The registry growth curve is worth seeing, because it tells you both that the channel is real and that it is getting crowded. A listing on a curated, low-noise catalog is worth far more than a listing among tens of thousands of auto-crawled entries, which is the honest caveat to keep in mind when you read directory server counts.

Beyond the official registry, the directories that matter split into two useful groups, and knowing the difference changes where you spend effort. On one side are the high-volume, automated directories like mcp.so (21,000-plus servers) and Glama (around 37,000), which offer broad coverage and quality scores but heavy duplication - AutomationSwitch. On the other are the curated, high-trust catalogs where being listed is genuine distribution: Anthropic's Connectors Directory, the ChatGPT App Directory (open to submissions since December 2025), Docker's verified MCP Catalog, and the hand-reviewed PulseMCP. Getting into the curated set requires clearing a bar (Streamable HTTP, OAuth 2.1, clean tool annotations, a privacy policy), which is precisely why a listing there is worth more than a crawl entry on a 20,000-server list.

The deeper idea underneath discovery is a discipline some are calling agent experience optimization, and it is the natural successor to search engine optimization for a world where agents, not just people, decide what gets used - getaiform. The logic is a direct extension of section 1: if the buyer is an agent enumerating tool schemas, then being present as a callable tool with a clear name, a precise description, and clean metadata is the equivalent of ranking on the first page. Related standards like WebMCP, developed by Google and Microsoft, push this further by letting a website itself declare structured tools an agent can call - SEO WebMCP. This is early and the framing is partly vendor marketing, so temper the hype, but the direction is real and it overlaps heavily with the tactics in our guide to the top technical SEO agent skills.

Put the discovery pieces together and a practical sequence emerges that any founder can follow. Publish to the official registry with a clean server.json, submit to the curated directories relevant to your customers (Anthropic's for Claude users, OpenAI's for ChatGPT users, Docker's for developer tools), and make your tool names and descriptions clear enough that an agent picks them correctly. Then treat the whole thing as you would a marketing channel: measure which tools get called, refine the descriptions that underperform, and prune the tools that confuse. Being listed is the start of distribution, not the end of it, and the servers that win keep iterating on their agent-facing copy the way a growth team iterates on landing pages, a mindset we explored in getting people to actually use what you build in our autonomous business guide.

10. Making money: metering, x402, and agent payments

For most founders the point of shipping an MCP server is not charity; it is either distribution that drives your core business or direct revenue from the server itself. Both are legitimate, and the tooling for direct monetization matured dramatically in the first half of 2026. There are four dominant pricing models, and the honest observation from practitioners is that the payment is the easy part; the hard part is the meter - the deduplication, per-tool rates, usage caps, and turning thousands of sub-cent calls into one clean invoice - UsageBox. Before you reach for exotic payment rails, understand that this metering problem is the real engineering work in charging for agent access, and it is why most founders are better served by subscription or outcome-based pricing than naive per-call billing.

The most talked-about new rail is x402, which revives the long-dormant HTTP 402 "Payment Required" status code so agents can pay per tool call in stablecoins. An unpaid call returns a 402 with a machine-readable price and wallet, the agent signs a payment, retries with proof, and gets a 200, with no API key or account required - Eco. Coinbase introduced it in 2025 and donated the spec to the Linux Foundation in April 2026, and by then the network reported roughly 165 million transactions across about 69,000 active agents at a median price of under three cents a call - Cloudflare. It is genuinely elegant for agent-to-agent and crypto-native use cases. The honest caveat is that on-chain, stablecoin-on-Base payments carry wallet and crypto-UX friction that most mainstream B2B buyers reject, so x402 is a tool for a specific corner of the market, not the default.

For mainstream buyers, the fiat rails caught up fast, and this is where most founders should look first. Stripe's Machine Payments Protocol, launched in March 2026, lets a server return a payment request when an agent hits it, then bills through Stripe's normal PaymentIntents, aggregating a session's many calls into one clean charge and supporting cards and buy-now-pay-later - Stripe. It launched with more than a hundred adopters including Anthropic, OpenAI, and Shopify. Separately, the Agentic Commerce Protocol from OpenAI and Stripe powers Instant Checkout inside ChatGPT, letting buyers purchase from merchants without leaving the conversation - Stripe. These fiat-first standards are the pragmatic path for a company selling to normal customers, and they slot neatly into the payment infrastructure choices we covered in the payment platforms guide.

There is also a turnkey layer emerging for founders who want revenue without building a billing system, which is where the metering problem gets solved for you. Edge platforms are shipping monetization as a feature: Cloudflare's Monetization Gateway lets you charge agents for any protected resource, including MCP tools, with per-request pricing and no application changes, and AWS added a comparable action to its edge - Cloudflare. Wrappers like xpay.sh sit in front of an existing server and add per-call billing in minutes. The key decision for a founder is not which exotic protocol wins; it is to match the rail to the buyer. Choose Stripe's fiat protocols or ChatGPT's checkout for mainstream customers, reach for x402 for crypto-native and agent-to-agent flows, and, whatever you pick, respect that the metering and invoicing is where the real work sits. Micro-per-call pricing rarely pencils out on its own, so most durable MCP revenue looks like a subscription or an outcome fee, not a stream of pennies.

11. Do you even need MCP? The honest counter-case

A guide that only sold you on MCP would be marketing, not analysis, so here is the disciplined counter-argument, and it is strong enough that some products should genuinely wait. The sharpest version comes from engineers who point out that if you already expose a clean REST API with an OpenAPI spec, an agent with HTTP access can often call it directly, and wrapping it in MCP adds a layer to maintain, debug, and secure without adding capability - Zero-Shot Labs. MCP earns its keep for stateful, multi-client, discovery-driven agent use, where the standardized tool-listing and the cross-host reach are the whole point. It does not earn its keep as a mandatory wrapper on every endpoint you own. If your honest situation is "I have a clean API and one internal agent that already calls it," you may not need MCP yet.

The second real objection is tool and context bloat, and it follows directly from how agents work. Every tool you expose consumes space in the model's context window and adds a chance the agent picks the wrong one, so more tools is not better, it is often worse. This is why Block collapsed two hundred endpoints into three tools and why Figma shipped exactly three. A founder who exposes fifty tools because their API has fifty endpoints has not built a good MCP server; they have built a confusing one. The discipline required (curate ruthlessly, describe precisely) is real work, and a product without the internal clarity to name its three most valuable outcomes is not ready to expose them to an agent.

The third objection is the one no protocol can fix: agent reliability is the ceiling. MCP makes your product reachable, but whether the agent uses it correctly depends on the agent's own planning and tool-selection, which is outside your control. A machine-readable interface is necessary but not sufficient for the agent to accomplish the task, and in 2026 agents still make wrong calls, misread schemas, and give up on multi-step work. Add the protocol churn from section 3 and the security exposure from section 8, and the case for waiting gets specific: if you are pre-product-market-fit, if your API is still changing weekly, or if you have no bandwidth to maintain a security-sensitive public endpoint, shipping an MCP server now may be premature optimization. The decision tree below is the honest version of "should you."

The right way to hold all of this is not "MCP or nothing." It is a staged bet. The counter-arguments are reasons to be deliberate, not reasons to be absent, because the distribution channel is being wired now and the cost of a small, safe, read-heavy first server is genuinely low. The failure mode to avoid is the one at both extremes: shipping a sprawling, insecure fifty-tool server because MCP is hot, or shipping nothing because a blog post said REST is enough. The founder who wins exposes three sharp tools behind proper OAuth, lists them where their customers' agents look, measures what gets called, and expands from there. That is the same measured approach to new capability we advocated in weighing what software is left to build.

12. A 2026 shipping playbook

Enough theory; here is the concrete sequence to go from nothing to a live, discoverable, secure MCP server, written as the path a small team would actually walk. The order matters, because the most common mistake is to build the tools first and bolt on auth and hosting later, when both are much harder to retrofit. Decide your surface before you write a line of code. Pick the three to five outcomes an agent should be able to achieve in your product (not endpoints, outcomes), name them clearly, and write their descriptions as if an agent's success depends on reading them, because it does. This is product design, and it deserves the same care as designing a great onboarding flow.

With the surface decided, choose your build-and-host path from the assessment table at the top of this guide, matching your stack rather than chasing the highest score. The mechanical steps that follow are consistent across paths, and the discipline is to do them in this order:

1. Scaffold the server with the SDK or framework for your language (FastMCP for Python, the TypeScript SDK or a framework for JavaScript, or a generator if you have an API).
2. Wire Streamable HTTP and OAuth 2.1 from the start; retrofitting auth onto a working prototype is where most timelines slip.
3. Test with the patched MCP Inspector and scan for tool-poisoning and injection patterns before any public exposure.
4. Deploy remote and stateless on Cloudflare, Vercel, or a container host, keeping the first version read-heavy and least-privileged.
5. Publish and list: a clean server.json to the official registry, then the curated directories your customers use.

Walk that list and notice what it optimizes for: a small, safe, reachable first release rather than a comprehensive one. The instinct to expose everything and open write access on day one is exactly the instinct that produced the incidents in section 8. A first server that lets an agent read your product's state and take one or two safe, reversible actions is far more valuable than an ambitious one that leaks data, because the first can be expanded with confidence and the second gets disabled after a headline. Ship the sharp minimum, watch how agents use it, and grow the surface as your monitoring earns you the right to.

The final piece of the playbook is treating the server as a living product, not a launched artifact, because the ecosystem will not hold still. Budget to revisit it a couple of times a year as the spec revises, watch the security advisories for the SDKs and adapters you depend on, and iterate the tool descriptions based on what agents actually call and what they get wrong. Instrument it the way you would instrument a funnel: which tools fire, which error, which get chosen when the agent had a better option available. This is the operational cousin of the back-office automation we covered in automating your startup's back office, and it is what separates a server that quietly compounds distribution from one that ships and rots. For founders who would rather not run this loop themselves, the managed platforms exist precisely to own the maintenance, security, and spec-tracking on your behalf, which is a legitimate trade when your scarce resource is your own time.

A note on the author. This guide was written by Yuma Heymans ( @yumahey), a San Francisco based founder who builds autonomous AI companies and co-founded the AI recruitment platform HeroHunt.ai. His current work centers on systems where AI agents build and operate entire businesses, which is exactly the world an MCP server is built for: making a product legible and callable by the agents that increasingly do the work.

13. The future: agents as customers

Step back from the mechanics and the trajectory is clear enough to plan around, because the milestones tell a consistent story. The protocol went from an Anthropic launch in November 2024, to OpenAI adoption in March 2025, to Google and Microsoft support through the spring, to a formal auth-hardening revision in June, a public registry in September, and a donation to a vendor-neutral foundation in December, all inside a single year - Pento. That is the adoption curve of a genuine standard, not a passing trend, and the SDK download numbers put an exclamation point on it: from roughly 100,000 at launch to more than 400 million monthly by mid-2026. The chart below is the shape of a technology crossing from novelty to infrastructure.

Reason forward from that curve and the first-principles conclusion from section 1 becomes a business plan. If the number of tasks performed by agents keeps climbing, then the share of your potential customers who reach you through an agent rather than a screen climbs with it, and the products that are legible to those agents capture that flow while the ones that are not simply fall out of consideration. This is not a distant scenario. It is already true for the developer-tool category, where a product that a coding agent cannot call is at a real disadvantage, and it is spreading outward to commerce, operations, and back-office work. The question a founder should ask is not "will agents matter to my business" but "when they call, will I be in the list."

Two developments will accelerate this, and both are visible in the 2026 spec. The move to a stateless, edge-friendly protocol removes the cost and complexity that kept small teams from shipping servers, which means the supply of agent-callable products is about to expand sharply. And the maturing of agent payment rails (Stripe's fiat protocol, ChatGPT's checkout, x402 for the crypto-native edge) means a callable product is increasingly a purchasable one, so the agent is not just a user of your tool but a customer with a wallet. Put those together and the shape of the next few years is a world where being agent-legible is a prerequisite for growth, the way being mobile-friendly became a prerequisite a decade ago, and being on the web became one before that.

The honest close is that none of this guarantees your specific server will succeed, because reachability is necessary but not sufficient, and the counter-arguments in section 11 remain true. Agents can still fail to use your tools well, the spec will keep churning, and a beautiful server for a product nobody wants is still a product nobody wants. But the direction is not in serious doubt, and the cost of a small, safe first move is low while the cost of absence compounds. The founders who treat their MCP server as a primary distribution surface, built with the same care as their UI and their API, will be the ones the agents can actually work with. For the rest of the picture of what building a company looks like when agents are in the loop from the start, our guides to how to start a company in 2026 and the rise of the solopreneur pick up where this one leaves off.

---

This guide reflects the Model Context Protocol landscape as of July 2026. MCP versions by date, the spec revises every few months, and pricing, security advisories, and platform features change constantly. Verify the current spec revision, SDK versions, and provider pricing before you build, and treat every model name and version as something to confirm against the provider's live documentation rather than assume.