The best MCP alternatives, compared honestly
MCP still does one thing better than anything else here: it decouples the person who writes a tool from the person who runs the model, over one JSON-RPC wire format and two standard transports. There is no price to compare, because MCP is a specification. The reason to re-read the field is that most published comparisons describe a version of MCP that no longer exists: revision 2026-07-28 removed the initialize handshake and protocol-level sessions, deprecated three of its own primitives, and reclassified HTTP+SSE as deprecated, and MCP has not belonged to Anthropic since 2025-12-09. This page compares what each option actually specifies, and what it deliberately leaves to you.
Nothing here has a protocol fee, so the choice is which layer you let someone else specify:
- You own both ends, one provider, under about ten tools → provider function calling: a JSON Schema per tool in your own process, no server to host, and a published fixed cost of 286 tokens of tool-use system prompt on Claude Opus 5.
- The tools are already an HTTP API you own → OpenAPI: generate tool definitions from the document you already publish, currently the OAS 3.2.0 line, and skip the extra hop.
- One agent handing work to another agent → A2A: Agent Cards plus a defined task lifecycle, v1.0.0 since 2026-03-12. Not a rival; the project frames the two as complementary, MCP at the tool boundary and A2A at collaboration between agents.
- You want the integrations, not the protocol → a hosted connector platform such as Composio or Zapier MCP, where the real decision is the meter: Composio bills $0.0003 per tool call, Zapier charges 2 tasks per successful call.
Narrower cases are in the table below: Agent Client Protocol if you are wiring an agent into an editor, LangChain if the tools live in your own process and what you want is model-provider portability, direct SDK calls if no third party will ever plug in.
Why teams look elsewhere
What changed in MCP, and what it never covered
MCP did not get worse at its core job, and adoption is still climbing: the 2026-07-28 release post reports close to half a billion SDK downloads a month, self-reported by the maintainers. What changed is the surface. One revision removed sessions, deprecated three primitives and pushed more of the hard parts onto the host, which is why a comparison written in early 2025 now describes features that are gone.
Sessions and the handshake are gone
Revision 2026-07-28 removed the initialize handshake and the Mcp-Session-Id header. The spec's own security guidance states it flatly: MCP is stateless and has no protocol-level sessions. Every request now carries its protocol revision and client capabilities in _meta, and cross-call state becomes your design problem, carried in server-minted handles passed as ordinary tool arguments.
Three primitives deprecated at once
SEP-2577 deprecated Roots, Sampling and Logging in a single release, under a new feature-lifecycle policy with a minimum twelve-month window. Every suggested migration points out of the protocol: pass directories or files as tool parameters, integrate directly with LLM provider APIs instead of Sampling, and log to stderr or use OpenTelemetry instead of Logging.
One transport fewer, and no stream resumability
HTTP+SSE, deprecated since 2025-03-26, was reclassified as formally Deprecated; stdio and Streamable HTTP are the two that remain. Server-initiated JSON-RPC requests went too, replaced by the Multi Round-Trip Requests pattern (SEP-2322). Last-Event-ID and SSE event IDs were removed, so a broken stream loses the in-flight request and the client must re-issue it with a new request ID.
Tool definitions cost real tokens
This is the loudest criticism of MCP and it is conceded first-party. Anthropic's engineering post of 2025-11-04 says clients load all tool definitions upfront into context, forcing models to process hundreds of thousands of tokens before reading a request, and gives a worked case cutting 150,000 tokens to 2,000 by having the model write code against the servers instead. Read that as a statement about 2025 defaults: the 2026-07-28 revision now requires ttlMs and cacheScope on the list methods and asks for deterministic tool ordering, which helps caching without taking definitions out of the model's context.
Security is documented, then delegated
The spec documents the confused-deputy attack against MCP proxies in full, forbids token passthrough (servers must not accept any token not explicitly issued for them), and says tool descriptions and annotations should be treated as untrusted unless the server is. It also concedes that MCP cannot enforce its own security principles at the protocol level, which leaves the burden with the host.
New owner, same final say
Anthropic donated MCP to the Agentic AI Foundation at the Linux Foundation on 2025-12-09, alongside Block's goose and OpenAI's AGENTS.md; the entity is now Model Context Protocol a Series of LF Projects, LLC, and the spec is Apache-2.0. Read the governance page before calling it vendor-neutral: two named Lead Maintainers hold final authority and can veto any decision by Core Maintainers.
The shortlist
8 MCP alternatives worth evaluating
This is not one category, which is why generic listicles read strangely. Two of these are the honest no-protocol answer (provider function calling and direct SDK calls); one describes the HTTP API underneath (OpenAPI); two specify a different layer of the same stack (A2A for agent to agent, Agent Client Protocol for editor to agent); one is an in-process library (LangChain); and two are commercial services with real prices. The order is how often each is genuinely the right answer, not preference, and every pick lists one honest strength and one real weakness.
Standardizes the shape of a tool definition (JSON Schema) and the tool_use to tool_result turn-taking, and nothing else. Tools live in your process, so there is no server to host, no OAuth proxy to secure and no third-party binary to trust. The overhead is published rather than guessed: on Claude Opus 5 the tool-use system prompt costs 286 tokens for auto or none and 406 for any or tool. Weakness: definitions are request-scoped and vendor-specific, so nothing you build is portable to another client or another model provider.
No protocol at all, on purpose: your agent calls your function, which calls the vendor SDK. You get zero protocol surface, zero token overhead for definitions you never send, no consent model to design, and no dependency on a spec that removed sessions and deprecated three primitives inside one release cycle. Weakness: every integration is code you write and maintain, and nobody outside your team can ever plug in, which is precisely the decoupling MCP exists to provide.
The only option here with a decade of registries, codegen and tooling behind it, stewarded by the OpenAPI Initiative at the Linux Foundation under Apache-2.0. OAS 3.2.0 is the current line and 3.1.2 the newest 3.1.x patch; 3.2.0 added multipurpose and nested tags, more HTTP methods, and streaming support for sequential media types such as server-sent events. It is also the historical root of this whole category: the original ChatGPT plugin manifest was an OpenAPI document. Weakness: it describes an API, not a model-facing tool, so tool-call semantics, agent lifecycle and consent are all yours, and real OpenAPI documents are routinely far too large to put in a context window.
An adjacent layer rather than a rival, and the project frames the two as complementary: its docs put MCP at how an agent interacts with individual tools and resources, and A2A at how different agents collaborate. It specifies Agent Cards for discovery and capability declaration, a task lifecycle with explicit states (submitted, working, input_required, completed, failed, canceled, rejected, auth_required), message and artifact exchange, three bindings (JSON-RPC 2.0, gRPC, HTTP+JSON), streaming and push notifications, and Signed Agent Cards for cryptographic identity. v1.0.0 landed 2026-03-12, v1.0.1 on 2026-05-28; Linux Foundation, Apache-2.0, donated by Google Cloud. Weakness: it deliberately gives an agent no access to your tools or data, so it replaces nothing MCP does.
Zed Industries' protocol for the editor to coding-agent boundary: JSON-RPC, wire compatibility through versions negotiated at initialization, and its own types for agentic-coding UX such as displaying diffs. It reuses MCP's JSON representations where it can, which tells you how the two relate. Apache-2.0, no CLA, official SDKs for Kotlin, Java, Python, Rust and TypeScript, around 4,000 GitHub stars. Weakness: it is the wrong axis for this question, it still leaves tool and data access to MCP, remote-agent support was described as under development, and neither the docs site nor the README surfaced a current version number.
A library abstraction rather than a protocol, and worth picking for exactly that reason. It describes itself as a minimal, highly configurable harness over models, tools, prompts and middleware: you define a Python or TypeScript function and hand it to create_agent, and the abstraction covers provider differences so one definition works across model vendors. MIT licensed. Weakness: none of it exists on the wire, so a LangChain tool is not consumable by any client that is not running LangChain in the same process, and it ships an MCP adapter rather than replacing MCP.
What you buy is managed OAuth for third-party SaaS, a maintained tool catalogue and hosting, and it speaks MCP at the far end. The free tier is hard-capped and needs no card: 100,000 tool calls, 50,000 triggers and 1,000,000 LLM tokens a month with 3 team members, and usage pauses at the cap rather than billing you. Pro is $29 per month including $29 of usage credit that resets monthly with no rollover. Overage, on monthly billing, runs $0.0003 per tool call, $0.003 per trigger event and $3.75 per million LLM tokens; connected accounts on your own app are unlimited and free on every tier. Read the dates on that pricing: Composio states these rates apply to signups from 2026-08-15, that accounts opened earlier stay on their existing plan until 2026-12-31, and that premium tool calls bill separately for every customer from 2026-09-01. Weakness: the billed unit is the tool call, so the invoice tracks how chatty your agent is, and you accept their catalogue instead of writing servers.
Not a separate SKU. Zapier's pricing page says each successful step in a Zap and each programmatic call, MCP included, consumes tasks, and the help centre puts the rate at two tasks per successful tool call, with failed calls free. It is available on Free, Professional, Team and Enterprise. Weakness: do that arithmetic before adopting it. Free gives 100 tasks a month, which is 50 successful tool calls. Professional at $19.99 per month billed annually, or $29.99 per month billed monthly, gives 750 tasks, which is 375 calls. Team starts at $69 per month billed annually for 2,000 tasks. Overage bills at 2.5 times base on monthly plans and 1.25 times on annual, and Agents and Chatbots are separate add-ons with their own units.
Deliberately off the shortlist. Pipedream Connect is a genuine option (hosted managed auth for end users, a catalogue of 3,000+ integrations, hosted MCP servers), but its pricing page is a client-rendered shell with no prices in the HTML, so the only figures verifiable at source are a free tier limited to 3 connected accounts with a daily credit cap and a workflow meter of one credit per 30 seconds of compute at 256 MB of memory; the per-external-user rate circulating in secondary write-ups is not printed here. The OpenAI Apps SDK is not an alternative at all: you still build an MCP server, and the SDK adds Skills, optional UI and packaging above it. IBM and BeeAI's Agent Communication Protocol, the other ACP, merged into A2A on 2025-08-29, and IBM now directs its users to A2A. LlamaIndex is omitted because its licence and version were not verified, and hosted platform pricing for LangSmith and LlamaCloud was out of scope.
Side by side
MCP alternatives compared
Prices as of August 2026, from each vendor's own pricing page, and most cells honestly read that there is no price, because most of these are specifications. The columns that decide the choice are the two in the middle: the layer a thing specifies, and what it leaves to you. MCP's own row is the baseline.
| Option | Type | Layer it specifies | What it leaves to you | Custodian and licence | Price |
|---|---|---|---|---|---|
| MCP | Open spec, host to server | JSON-RPC 2.0 wire, stdio and Streamable HTTP, tools/resources/prompts, mandatory server/discover, subscriptions/listen, optional OAuth 2.1 resource-server auth, per-request versioning, list caching |
All state, in server-minted handles passed as tool arguments; sampling, roots and logging (deprecated); stream resumability; a global tool namespace; agent-to-agent; enforcement of its own security principles | MCP a Series of LF Projects, LLC (Agentic AI Foundation, Linux Foundation) since 2025-12-09. Apache-2.0 spec and code, CC-BY-4.0 docs, legacy MIT contributions | ✗ no price: it is a spec. Revision 2026-07-28 |
| Provider function calling | Vendor API feature, in process | Tool-definition shape (JSON Schema) and tool_use to tool_result turn-taking, request-scoped |
Transport, discovery, authorization, hosting, and any portability across clients or providers | OpenAI and Anthropic, proprietary APIs, no published spec version | No protocol fee; tool schemas are billed as input tokens |
| Direct SDK calls | No protocol, by design | Nothing, deliberately | Every integration is code you write; no third party can plug in | You. Your licence | No price |
| OpenAPI | Open spec, HTTP API description | Paths, methods, parameters, schemas, auth schemes, servers. Discovery by URL convention, not protocol | Everything model-facing: tool-call semantics, agent lifecycle, consent, and shrinking the document to fit a context window | OpenAPI Initiative (Linux Foundation), ✓ Apache-2.0 | No price: it is a spec. OAS 3.2.0 current line, 3.1.2 newest 3.1.x |
| A2A | Open spec, agent to agent | Agent Cards and discovery, task lifecycle states, artifacts, three bindings (JSON-RPC, gRPC, HTTP+JSON), streaming and push, auth schemes, Signed Agent Cards | Agent internals, plans and tool implementations, and tool or data access, which is MCP's layer | Linux Foundation, donated by Google Cloud, ✓ Apache-2.0 | No price: it is a spec. v1.0.0 on 2026-03-12, v1.0.1 on 2026-05-28 |
| Agent Client Protocol | Open spec, editor to agent | JSON-RPC, version negotiation at initialization, agentic-coding UX types such as diffs; reuses MCP's JSON shapes | Tool and data access, which is still MCP; agent-to-agent; remote agents, still in progress | Zed Industries, ✓ Apache-2.0, no CLA | No price: it is a spec. Introduced August 2025; current version not confirmed |
| LangChain | Library, in process | Nothing on the wire: an abstraction over provider differences | Transport, out-of-process servers, discovery, authorization, cross-language and cross-vendor interop | LangChain Inc., ✓ MIT | Library free; LangSmith priced separately and not researched here |
| Composio | Commercial service | Nothing: hosted managed OAuth, a tool catalogue and MCP endpoints | Nothing to build; you accept the catalogue and the meter | Composio, ✗ proprietary service | Free $0 per month, hard-capped at 100,000 tool calls; Pro $29 per month; overage $0.0003 per tool call on monthly billing; rates apply to signups from 2026-08-15, premium tool calls billed separately for all customers from 2026-09-01 |
| Zapier MCP | Commercial service | Nothing: an MCP endpoint over Zapier's existing action catalogue | Nothing to build; you accept the task meter | Zapier, ✗ proprietary service | 2 tasks per successful call. Free 100 tasks per month, so 50 calls; Professional $19.99 per month billed annually or $29.99 billed monthly, so 375 calls; Team from $69 per month billed annually |
| Pipedream Connect | Commercial service | Nothing: hosted managed auth for end users, a catalogue and hosted MCP servers | Nothing to build | Pipedream, ✗ proprietary service | Rate not published in static HTML. Verified: free tier of 3 connected accounts with a daily credit cap; workflow meter of 1 credit per 30 seconds of compute at 256 MB |
| OpenAI Apps SDK | Proprietary layer above MCP | Packaging and distribution on top of MCP: Skills, optional ChatGPT UI, plugin bundling, directory, platform-applied safety behaviour | The MCP server itself; you still build one | OpenAI, ✗ proprietary, no published licence | No protocol fee; ChatGPT and API pricing apply |
Numbers that do not fit in cells. Anthropic publishes the fixed tool-use system-prompt overhead per model: 286 tokens for tool_choice auto or none and 406 for any or tool on Claude Opus 5. Its code-execution post measured one MCP workload at 150,000 tokens of tool definitions and cut it to 2,000. The official MCP Registry is still labelled preview, with no data-durability guarantee and no GA announcement we could find, and the live site rendered no server total. MCP download figures are the maintainers' own numbers from the 2026-07-28 release post and are unaudited. Prices and free tiers change often; check each vendor for current terms. Compiled August 2026.
Official pages: MCP specification · MCP governance · Anthropic on code execution with MCP · Anthropic tool use · OpenAI function calling · OpenAPI Initiative · A2A specification · Agent Client Protocol · OpenAI Apps SDK · Composio pricing · Zapier pricing · Pipedream pricing docs
The unglamorous answer
When you do not need MCP at all
Most teams asking this question do not need a protocol. If you write the tools, run the model, and no third party will ever connect, provider function calling is the whole answer: declare a JSON Schema, receive a tool call, execute it, return the result. MCP's value is decoupling who wrote the tool from who runs the model. When that is the same team, you are paying protocol overhead for a boundary that does not exist.
The same goes for tools that are already a documented HTTP API you own. Generating tool definitions from your OpenAPI document and calling the API directly avoids a hop, a deployment, an OAuth proxy to secure and the confused-deputy risk class the MCP spec documents at length. Putting an MCP server in front of your own REST API buys portability you may never use.
And if the pain is context rather than connectivity, more servers make it worse, not better. Anthropic's own guidance for that case is to stop calling tools directly and let the model write code against the servers instead, the change that took one workload from 150,000 tokens to 2,000; provider-side tool search attacks the same problem by loading definitions on demand. Neither fix involves adopting or dropping a protocol.
A fair call
When MCP is still the right choice
Adopting MCP costs you a server to run, an authorization story to get right, and a token budget for definitions you send on every turn. That is worth paying when the tool author and the model operator are different people, and it is the one thing nothing else on this page does.
MCP is still right if…
- The tool author and the model operator are different teams, companies or products. That boundary is the entire point of the protocol, and no library abstraction crosses it.
- You want one server reachable from many clients, including clients you do not control or cannot ship code into.
- You need the core rather than the removed edges. The 2026-07-28 revision deleted features; tools, resources and prompts, the parts almost everyone uses, are untouched and now have a mandatory
server/discoverin front of them. - You want a real version story. Date-based revisions declared per request,
UnsupportedProtocolVersionErrorwith the list of supported revisions, and a minimum twelve-month deprecation window mean the old listicle line about MCP having no versioning is simply out of date. - Session affinity was your problem, not your feature. A stateless protocol with no
Mcp-Session-Idputs identical server instances behind a plain load balancer.
Look elsewhere if…
- You control both ends and have fewer than about ten tools: provider function calling covers it.
- The tools are a documented HTTP API you own: generate definitions from your OpenAPI document.
- One agent has to delegate to another agent across an org or vendor boundary: that is A2A, and modelling someone else's agent as a tool is the wrong shape.
- You are wiring an agent into an editor: that is Agent Client Protocol. MCP does not describe diffs, permission prompts or editor UI.
- You were only going to use Roots, Sampling or Logging: all three are deprecated, and every migration path leads out of the protocol.
- You need durable multi-step state or guaranteed stream resumability: 2026-07-28 removed both, and a plain authenticated API with real sessions is simpler than binding server-minted handles to users yourself.
- You cannot accept third-party binaries on user machines: the spec's own local-server section lists arbitrary code execution, no visibility and data exfiltration as the risks, and leaves mitigation to the host.
- You just want the integrations: then it is a metering decision between Composio, Zapier and Pipedream, not a protocol decision.
A worked example
What the token complaint looks like on a server that exists
Disclosure: this site is published by Buddy, which runs a remote MCP server. It is deliberately absent from the shortlist and the table, because a first-party server for one platform is not an alternative to a protocol. It is here for one reason: it puts a number on the criticism above. The server exposes "over 90 tools" across twelve categories, and the mitigation its documentation reaches for is not the spec's new cache metadata but a filter on the server URL, ?tools=pipelines,source. That distinction is the useful part: ttlMs and cacheScope let a client re-use a list it already fetched, while only filtering makes the list smaller, and that call belongs to whoever runs the server rather than to anything the protocol negotiates. The same docs ship a CLI-driven skill next to the MCP server and describe the two as complements, which is the second half of the same admission.
Where the agent runs is a separate decision, and the one MCP says nothing about: on Buddy that is a pipeline action, a throwaway sandbox, or Claude Managed Agents with the loop at Anthropic and execution on sandboxes you control. Every option in the table leaves that part to you.
Common questions
Common questions about MCP alternatives
Is MCP still controlled by Anthropic?
No. Anthropic donated MCP to the Linux Foundation on 2025-12-09, where it became a founding project of the Agentic AI Foundation alongside Block's goose and OpenAI's AGENTS.md. The legal entity is now Model Context Protocol a Series of LF Projects, LLC, and spec and code contributions are Apache-2.0. Read the governance page carefully, though: technical authority is not a committee vote. It is a contributor ladder topped by two Lead Maintainers who hold final authority and can veto any decision below them, and Anthropic states that its investment in MCP is unchanged.
What is the current MCP specification version?
Revision 2026-07-28, which replaced 2025-11-25. Revisions are date-based and declared on every single request, in _meta and in the MCP-Protocol-Version header over HTTP, so there is no handshake to negotiate them. A server that does not support the requested revision returns UnsupportedProtocolVersionError, error code -32022, listing the revisions it does support. The same release added a mandatory server/discover method and a formal feature-lifecycle policy with a minimum twelve-month deprecation window.
Is A2A a competitor to MCP?
No, and the A2A project frames the two as complementary: its own docs say MCP 'defines how an AI agent interacts with and utilizes individual tools and resources' while A2A 'focuses on enabling different agents to collaborate with one another'. MCP tells one agent how to reach your database or your ticketing system. A2A tells one agent how to discover another agent through an Agent Card, hand it a task, and track that task through a defined lifecycle of states such as submitted, working, input_required and completed. A2A deliberately gives agents no access to each other's tools or internals, so it replaces nothing MCP does. Systems that need both use both.
What does ACP mean, and is it an MCP alternative?
Ask which ACP, because two projects have used the acronym. Agent Client Protocol, from Zed Industries, standardizes the boundary between a code editor and a coding agent, is Apache-2.0, and reuses MCP's JSON representations where it can; it sits above MCP rather than replacing it. Agent Communication Protocol, from IBM Research and BeeAI, was a different project that merged into A2A on 2025-08-29, announced on the LF AI and Data community blog and co-authored by IBM Research; IBM's own documentation now directs ACP users to A2A, so treat it as a closed path.
Is the OpenAI Apps SDK an alternative to MCP?
No, it is built on MCP. OpenAI's own documentation has developers build an MCP server that defines the tools available to ChatGPT and Codex, and adds packaging above it: Skills, which are repeatable workflows around your MCP tools, optional ChatGPT-specific UI, plugin bundling and directory distribution. An open proposal, SEP-2640 Skills Extension, would serve Skills over MCP as skill:// resources with digest-verified manifests; it was opened by an Anthropic maintainer and is not merged. The earlier generation of ChatGPT plugins used an OpenAPI manifest rather than MCP and has been retired; we could not confirm the exact retirement dates at a primary source, so this page does not print them.
Why do MCP tools cost so many tokens?
Because clients load every tool definition into context upfront, and every intermediate result passes back through the model. That is not a critic's claim, it is Anthropic's: its engineering post of 2025-11-04 describes models processing hundreds of thousands of tokens before reading a request, and measured one case at 150,000 tokens of tool definitions, cut to 2,000 by having the model write code against the servers instead. The 2026-07-28 spec attacks the same problem in-band by requiring ttlMs and cacheScope on list results so clients can cache them, and by asking servers to return tools in a deterministic order for better prompt-cache hits.
Do I need MCP at all if I only use one model provider?
Usually not. If you write the tools, run the model, and no third party will ever plug in, plain provider function calling covers it: declare a JSON Schema, get a tool call back, execute it, return the result. MCP earns its keep when the person who wrote the tool and the person running the model are different, or when one server has to be reachable from many clients you do not control. Anthropic even publishes the fixed overhead of the simpler path, at 286 tokens of tool-use system prompt on Claude Opus 5 for tool_choice auto or none and 406 tokens for any or tool.
Do I have to install an MCP server on my own machine?
No. The two live transports split exactly along that line: stdio for a server running as a local process, Streamable HTTP for a remote one. The distinction matters because the local case is where the spec's own risk list bites, listing arbitrary code execution, no visibility into what the binary does and data exfiltration, with mitigation left to the host. A remote server turns that into an authorization problem instead. A remote server is reached over HTTPS with an OAuth flow or a bearer token, so the question becomes who holds which scope rather than what is running on the laptop.