A founder asked me last week why their fancy new SDK is not getting picked up, while a tiny MCP server a competitor shipped over a weekend is already showing up in agent transcripts everywhere. I told her the answer she did not want to hear. The integration target moved, and her team is still aiming at the old one.
The old playbook
For roughly a decade the integration playbook for any SaaS product looked the same. You wrote an OpenAPI spec, generated client libraries for half a dozen languages, polished the TypeScript types, wrote a quickstart, posted a few examples on the blog, and then waited. The hope was always that a human developer would read your docs, install your package, and stitch your product into their app. Sometimes that worked. Most of the time the SDK sat on npm with three thousand weekly downloads and a graveyard of stale GitHub issues.
An SDK is a thing you make for a person who is writing code. It assumes that a human will read a function signature, understand the domain model, and make decisions about which calls to chain. The whole shape of an SDK, from naming to error types to pagination helpers, is optimised for the developer experience of typing in an editor with autocomplete.
The new caller
The caller has changed. In 2026 a very large slice of integration traffic is no longer a human in an editor. It is an agent reading a tool description, deciding what to do next, and calling something. Claude, Cursor, the in-house assistants companies are stitching into their own products, the long tail of vertical agents. They do not install your npm package. They do not read your docs the way a developer does. They want a list of tools with clear names, clear input schemas, and clear descriptions of what each one does.
MCP is the protocol that turned this from a vibe into a contract. An MCP server exposes your product as a set of tools that any compliant client can discover and call. The model does not need a client library. It needs a tool list, a schema, and a transport. That is it.
What changes in practice
An SDK serves the human writing code. A tool serves the model picking actions. The end user value is the same, get the thing done, but the delivery path is different. The SDK lives inside an application someone built on purpose. The tool lives inside an agent the user is already running, and shows up the moment they connect your server.
I watched a real example play out earlier this year. A small SaaS in the document signing space had been planning an SDK release for months. Specs, generators, packaging, docs site, three languages on day one, the works. The internal estimate was three months. In parallel a competitor with a smaller team shipped an MCP server in three days. Six tools, clear schemas, an auth flow that piggybacked on their existing API keys. By the end of the week, every Claude and Cursor user could plug it in and start sending documents from inside their assistant. The traffic graph went vertical. The SDK team is still shipping their SDK, and it will probably be good, but the market moved while they were generating types.
This is not either or
I am not saying SDKs are dead. They are not. There are real workflows where you need to compose fifty calls, hold complex state, stream large payloads, or run inside a tight latency budget. A model picking tools one at a time is the wrong shape for that. A typed client library with proper retries and connection pooling is still the right shape. Mature products will ship both, and that is fine.
What I am saying is that if you can only ship one in 2026, ship the tools. The reach of a single MCP server today is larger than the reach of an SDK that takes a quarter to land, because every agent user is already a potential caller the second you publish.
Honest pushback
Tools are not a silver bullet. Long-running operations are still awkward. Complex multi-step flows that need transactional guarantees are hard to express as a flat tool list. Discovery is messy when you have hundreds of tools. Auth and capability scoping is something the ecosystem is still figuring out. If your product is genuinely a deep integration target, like a database driver or a payments processor doing high-volume sync calls, an SDK is going to keep doing most of the work for a long time.
But for most products, most of the time, the unit of integration is no longer a function call inside someone else's codebase. It is a tool inside someone else's agent.
What I would do if I were starting a product today
I would design the public API surface tools-first. I would write the tool descriptions before I wrote the marketing site. I would think hard about which calls are safe to expose, what the capability scopes look like, and how errors come back in a way the model can recover from. I would publish an MCP server on day one, even if it only exposes ten tools. I would let the SDK follow once I knew which flows real users were composing.
The integration target shifted. Write for the agent, not just the developer. The product that meets the agent where it already lives is the product that gets used.