MCP or API: What Should a SaaS Vendor Ship First?

01The short answer

Ship the API first, always. Ship an MCP server second, and only once your users already have API-shaped workflows and your permission model can survive being called at agent frequency. Almost every MCP server worth using is a thin layer over an HTTP API that already existed. That is not a criticism of the protocol. It is how the protocol is designed to work, and any vendor who builds the server before the API has built the facade before the building.

The interesting question is not whether MCP replaces your API. It does not, and nobody credible claims it does. The interesting question is whether the second surface is worth its cost, given that the cost is not paid by you. It is paid by your customer, in context window, on every single request they make, whether or not they ever call your tools. A vendor who does not internalize that will ship a server with sixty tools and wonder why nobody uses it.

This is the vendor-side piece. The buyer-side version of the same argument, which servers to connect and which to remove, is in the MCP-first GTM stack. The two halves are the same physics viewed from opposite ends of the connection.

02Taking the objection seriously

The objection is that MCP is an API with extra steps, and for a single known call in a known order it is exactly that. A developer who knows they need to POST an order does not benefit from a protocol whose entire purpose is helping something figure out that an order endpoint exists. Adding MCP there buys a session, a transport, a schema layer, and a permanent tax on the caller's context, in exchange for nothing. Anyone selling you a decision matrix that does not concede this is selling you a decision matrix.

The most cited piece of evidence for the skeptical case is what practitioners call the context tax. Tool definitions are not lazy. They sit in the model's context whether the user invokes them or not, and they travel with every request. One measurement circulated widely on r/mcp put it in concrete terms: “The GitHub MCP alone loads ~50K tokens before the user types a single word. Add Jira, Slack, SonarQube and you've burned 30 to 40% of the context window on tool definitions.” Anthropic's own engineering team describes the ceiling case without hedging: agents connected to thousands of tools “need to process hundreds of thousands of tokens before reading a request.”

The second piece of evidence is a real company reversing course. On March 11, 2026, at Perplexity's Ask 2026 developer conference, cofounder and CTO Denis Yarats said the company is moving away from MCP for internal systems and enterprise-facing operations, in favour of REST APIs and CLIs. The reasons reported from the talk are the ones an engineer would expect: schemas, descriptions and traces loading into context on every call; missing built-in support for the OAuth flows, granular permissions, rate limiting and audit logs that enterprise buyers require; and non-determinism at production scale, where a model deciding its own call path produces less consistent outcomes than a direct call. Perplexity did not withdraw its public server. It kept MCP support for local desktop clients pulling its search, and moved everything load-bearing to APIs.

That line gets quoted as an anti-MCP argument. It is worth reading the paragraph it sits in, because Cloudflare's point is narrower and more useful than the meme version. Their observation is that models have seen enormous quantities of real code and comparatively little tool-calling, so tool-calling is the weaker modality, and MCP servers therefore end up dumbing down their interfaces to compensate. Their conclusion is not that the protocol is useless. It is that the protocol's value lives somewhere other than where everyone assumes: “it turns out MCP does something else that's really useful: It provides a uniform way to connect to and learn about an API.”

03What actually differs between MCP and a plain HTTP API

Six axes separate them, and only three of those favour MCP. Knowing which three is the whole decision. Most comparison posts in this category list twelve differences and weight them equally, which is how you end up with a matrix that recommends MCP for everything. The honest table is shorter and less flattering.

Read the table as a vendor rather than as an architect and one thing jumps out. The three axes where MCP wins are all about the moment of connection: how a client that has never heard of you finds out what you can do, how the customer grants access, and how a multi-step task stays coherent. The three where a plain API wins are all about everything after that: cost, predictability, and the ability to reason about your own system.

There is a fourth advantage the table cannot express, and for most SaaS vendors it is the real one: reach into places your API cannot go. A finance lead working inside Claude or ChatGPT cannot call your REST endpoint. They can click Connect. That is not a technical argument, it is a distribution argument, and it is the argument that actually moves the decision. If your buyer already lives in an assistant, an API-only product is invisible to them in the surface where they do their work.

Dash0's comparison, currently one of the better-ranking pages for this query, lands on the same split and adds a warning worth repeating verbatim for anyone about to auto-generate tools from an OpenAPI spec: “The trap people fall into is wrapping an existing API one-to-one in an MCP server. It feels efficient. It isn't.” One tool per endpoint is the single most common vendor mistake, and it is the mistake that makes the extra-steps objection true rather than arguable.

04The skill issue rebuttal, with numbers

The counter-argument to the context tax is that it is a design failure, not a protocol failure, and there is now measured data on both sides of that claim. The community version of the rebuttal is blunt: “Blaming the protocol for bad prompt engineering is like blaming HTTP because your API has confusing endpoints.” Nothing in the specification says you must load fifty schemas up front. That is a choice made by servers that expose everything and clients that load everything.

Someone actually tested it. A follow-up posted to r/mcp ran one server in three modes across 18 models and 5,346 runs at temperature zero: full, with all 45 tool schemas in context; toggle, where a meta-tool reveals a category on demand; and act, where every call is proxied through a single tool. The headline result supports the rebuttal. Toggle cut context by about 76 percent and dollar cost by about 72 percent, with no measured hit to answer accuracy. Act saved slightly less and cost roughly 8 points of accuracy, degrading badly on multi-step chains.

The obvious objection to gating is that models will simply toggle everything on to find out what they do not know. That was measured too. Only 2.4 percent of runs ever toggled everything, with a mean of about one toggle call per run. One small model was an outlier at 17 percent. The worst case is that you have recreated the ungated baseline, which is a bounded downside.

The finding that should change vendor behaviour is the one the author did not predict. Raw tool-selection accuracy under gating looked bad, 73 percent against 91 percent, but most of that gap was models skipping the tool call entirely and answering from memory. Count only runs that actually attempted a tool and the real routing cost is 6 points, 87 percent against 93 percent. As the write-up puts it: “hiding a tool makes models meaningfully more willing to skip it. On a calculator that's harmless. On a DB write, a live API call, or a payment, ‘I'll just answer from memory’ is the failure you don't want.”

Two caveats the author flagged, and we repeat rather than bury: the evaluation harness was written by Claude, and Anthropic's own models scored suspiciously well, so the author deliberately excluded them from the conclusions. And the whole thing ran against a single calculator server, so whether gating holds across a real multi-server fleet is genuinely open. It is still the most rigorous public number in this argument, and it is more than either side of the debate was working with six months ago.

So the skill-issue rebuttal is substantially correct: the context tax is a design choice, and the fix is measurable. But it is not free. Gating trades tokens for a higher rate of the model quietly declining to use you at all, which is a worse trade for a server whose tools return facts than for a server whose tools return a sum.

05Skills, CLIs, and code execution: the things actually competing

The real competition for your MCP server is not your REST API. It is a markdown file, a CLI, and a code sandbox, all three of which are cheaper to ship. A vendor deciding what to build should be comparing against those, not against a strawman of doing nothing.

Skills

A Skill is a folder of instructions and scripts the model loads only when the task matches. A vendor running both wrote the clearest comparison we found, on r/mcp: “MCP tool definitions sit in context whether the user invokes them or not. Skills only load when the task matches, so they're lighter by default.” The build cost is not close either: “MCP took real engineering work (OAuth, SSE transport, nginx config, session handling). A Skill is basically a markdown file pointing at your existing API.”

The same post raises a trust distinction most vendors have not thought about: “with MCP, the trust boundary runs through Anthropic's infra. With Skills, everything stays in the user's local session. For production data, that distinction matters.” For a security review at an enterprise buyer, that is a real conversation, and it can cut either way depending on whether the customer would rather audit one hosted connection or trust a local config file holding a long-lived key.

What Skills cannot do is serve a user who is not running a coding harness with a filesystem. That is most buyers. The pragmatic vendor answer showed up on r/SaaS and it is the right one: “I think MCP is dead. I use Skills. However, from a business viewpoint, I will offer MCP, but I will also offer Skills.” Personal preference and distribution strategy are allowed to disagree.

CLIs

A CLI is what Perplexity moved toward, and it has a property MCP does not: the model already knows how to use one, because it has read millions of them. A well-documented CLI with a stable set of subcommands is discovered by reading help output, costs nothing until invoked, and composes with pipes and files that the agent also already understands. If your users are engineers and your product has a natural command shape, a CLI plus good help text may outperform a server you spent a month on. It is the cheapest agent-facing surface available and the most underrated.

Code execution over the protocol

Anthropic's answer to the context tax is not to abandon MCP but to stop presenting it as direct tool calls. Expose the connected servers as a code API instead, let the agent read only the tool files it needs, and let it filter results inside the execution environment before anything reaches the model. On their Google Drive to Salesforce example, this “reduces the token usage from 150,000 tokens to 2,000 tokens, a time and cost saving of 98.7%”. Cloudflare published the same idea as Code Mode. Anthropic is explicit that it is not free either: running agent-generated code needs a sandbox, resource limits and monitoring, which is real operational overhead that direct tool calls avoid.

The vendor takeaway from that thread of work is quietly important. Both Anthropic and Cloudflare, having identified the exact weakness the skeptics point at, chose to keep the protocol and change the calling convention. The part they kept is the part Cloudflare named: a uniform way to connect and to learn. That is the part you are shipping when you publish a server.

06The gating rule: when an MCP server is worth it

Two conditions, both of which have to be true before you write a line of protocol code. The clearest statement of this we have seen came from a practitioner on r/SaaS, and it has held up against everything else we read for this piece.

The first condition is about demand and it is falsifiable in an afternoon. Look at your API traffic and your support queue. Are people already composing your endpoints into workflows, or is your API a checkbox on a pricing page that four accounts have ever called? An MCP server does not create API-shaped demand. It serves demand that already exists in a surface that already has the user. The signal to watch for is a change of phrasing: practitioners describe the request shifting from “can I call your API” to “can my agent use your product”, and the second question comes from people who will never read your reference docs.

The second condition is about survival and it is where teams get hurt. An agent is not a human with a faster mouse. It retries, it explores, it calls three tools to answer one question, and it does all of that inside a loop that a user is not watching. A rate limiter tuned for a person clicking buttons will produce a support ticket that reads, in the words of one founder, “why is my agent getting rate limited... they don't even know what endpoints the agent is calling under the hood, they just know their workflow stopped.” That is a support conversation you cannot win with a status page.

Three more checks are worth running before you commit, none of which override the two conditions but all of which change the size of the bet.

1. 1

   Is the ask coming from the economic buyer or only from engineering?

   Practitioners report MCP surfacing mostly from the technical buyer, with the VP of Ops or the CFO still unaware of what it is. A separate thread describes it becoming a genuine shortlist filter once IT joins an evaluation and is already running an agent stack. Those are different investments. The first justifies a weekend; the second justifies a quarter.

2. 2

   Can you name the questions your customers would ask an agent about your product?

   If you cannot write down five, you do not yet know which tools to expose, and you will default to one per endpoint. The five questions are the tool list. Everything else is surface area you will maintain forever for nobody.

3. 3

   Who owns it after launch?

   Kong's build-versus-buy analysis makes the point that a demo server is a weekend and a production one is authentication, governance, observability and maintenance, and that because the protocol is young and still moving, committing to a DIY build means committing to a permanent maintenance contract. The spec revises. Clients change caching behaviour. Somebody has to own that, and if the answer is nobody, you are about to add to the pile of abandoned servers rather than to the useful ones.

Size the upside honestly too. One vendor reported that “maybe 5-10% users ask and use it, but it's a bet on the future”. That is not a growth channel. It is a qualification unblocker and an option on a shift that appears to be underway. Priced as an option, an MCP server is cheap. Priced as a launch, it will disappoint you.

07The shape: a dumb wrapper, not a second product

If you clear the gate, build the thinnest thing that works. The best design principle in this category came from a team who had already shipped one.

Drift is the failure mode nobody plans for. An MCP server with its own business logic is a second product with a second set of bugs, a second permission model to keep aligned, and a second place for a security review to find something. A wrapper inherits everything: your auth, your rate limits, your entitlements, your audit trail. When you fix a bug in the API, it is fixed for agents too, because there is nowhere else for it to live.

Four more design decisions distinguish servers that get used from servers that get connected once and quietly ignored.

Group by user intent, not by endpoint

One tool per REST endpoint is the auto-generated default and it is wrong in both directions at once. It floods the context with near-identical descriptions the model has to disambiguate, and it forces multi-call sequences for things a user thinks of as one action. A tool should map to something a person would actually ask for. If your five real customer questions each take four endpoint calls to answer, that is four calls behind one tool, not four tools.

Annotate honestly, because silence is a claim

A build note posted to r/mcp makes a point most vendors miss. The specification's destructive-behaviour annotation defaults to true, so a tool that only reads a notification bell is, absent an explicit annotation, described to the client as something that may destroy data. In the author's words: “Silence is a false statement about your own tools.” They report that after annotating read-only and destructive hints properly, Claude began visually grouping their read and write tools on its own. Cheap change, visible effect.

Your descriptions are a contract only machines will read

The same notes report a schema promising posts “oldest first” while the API returned newest first, and the observation that lands: “No human ever saw that lie, only agents did.” Nobody proofreads tool descriptions the way they proofread docs, and nobody files a bug against a description. Diff your schemas against actual responses in CI, or the drift you avoided by writing a dumb wrapper comes back in as prose.

Scope narrow on purpose, and expect auth to be the hard part

A solo builder documenting their OAuth 2.0 plus Dynamic Client Registration implementation on r/mcp described scoping their exposed tools deliberately narrow, “on purpose, even though it would've been easier to just expose more”. Their debugging notes are worth reading before you start, particularly the hour lost to a www redirect silently stripping the Authorization header, which presented as a server with no tools rather than as an auth failure. Auth is where the schedule goes. Budget for it, and prefer OAuth over asking a customer to paste a long-lived key into a config file, because one of those can be revoked centrally and the other has to be hunted down on every machine it was copied to. Ours is documented at the connector authentication page if you want a worked example of the flow.

08What we could not verify

Three claims that circulate constantly in this debate, which we could not confirm from a primary source, and are therefore reporting as unresolved rather than repeating as fact. Everything else in this piece is either quoted from a page we read this week or attributed to the community thread it appeared in.

The Perplexity numbers. The decision itself is well-attested across multiple independent write-ups dated within days of the March 11, 2026 talk, all reporting the same substance. The specific figure that gets attached to it in secondary coverage, a 72 percent context overhead, we could not trace to a transcript, a slide, or a first-party post. We found no primary recording. Treat the direction as reported and the percentage as unsourced.

The token-savings range for tool gating. A benchmark summarized on r/LLMDevs found that the widely repeated claim of 60 to 90 percent token savings collapsed to between 8.5 and 35 percent on a five-tool test. That is a real caution against the marketing number, but a five-tool test is also the case where gating should help least, and we could not reconcile it against the 76 percent figure from the 45-tool evaluation above. Both are single experiments. Neither settles it.

Ecosystem health figures. A widely shared community analysis reported that roughly 9 percent of a couple of thousand public MCP endpoints were fully healthy, alongside a description of the specific failure that makes uptime monitoring useless here: “the server connects fine, the tool call returns 200, and the actual content is stale data, a parsing error wrapped in a success response. Regular uptime checks are useless here because nothing is technically ‘down.’” The qualitative point matches what anyone operating a server has seen. The 9 percent is a community measurement with no published methodology, and we are citing it as one.

09What we shipped, and what it cost

We build one of these, so the useful thing is to run our own decision through the gate rather than exempt ourselves from it.

Linkeddit is AI demand and competitor intelligence: measuring where answer engines recommend competitors instead of you, tracking what those competitors ship and what their customers complain about, and turning that into pipeline and content. The gate applied cleanly. Condition one was already true, because the work our customers do with us is inherently API-shaped: pull a brief, list the gaps, check what moved this week. Condition two forced actual work, because a per-seat rate limiter designed for a dashboard does not survive an agent that fans out across a dozen prompts, so the limits and the cost caps were rebuilt before the connector went out rather than after.

The result is a single connector at mcp.linkeddit.com/mcp with 65 tools, 37 of them Answer Radar, OAuth 2.1 with PKCE and no client secret. That tool count is well past the point where the context tax is real, and we are not going to pretend otherwise: it is the direct consequence of covering AI-search visibility, competitor intelligence, leads, keyword and Search Console data, and community signal from one connection rather than five. The trade we chose was one OAuth grant and one thing to revoke, against a larger resident tool set. If your product covers one job rather than six, do not copy that shape.

Three things we refused, for the same reason each time. We do not draft the content that closes a gap, because the client's model writes better with the user's tone and follow-ups in hand; we return the gap, the evidence and the citations. We do not narrate findings in prose, because the agent already has the structured finding. We do not render charts, because rendering is not a capability. What we do build is the part a chat session cannot provide: the measurement that has to stay comparable across tenants and across time, the schedule that outlives the conversation, and the approval gate on anything with a side effect. That reasoning is set out in full on the buyer-side companion piece, and applied to answer engines specifically on the AEO from your AI assistant page.

The rule we hold ourselves to is that every new integration ships its connector tool in the same change as the integration, not in a later phase. A capability that exists only in a web app is a capability most agent-first users will never reach. If you want to see what that looks like in practice, the full tool reference lists every tool and its parameters, and Compete is the feature most of the competitor tools read from.

Frequently asked questions

Sources

• Cloudflare: Code Mode, the better way to use MCP
• Anthropic Engineering: Code execution with MCP, building more efficient agents
• Model Context Protocol specification: Tools (2025-11-25)
• Agent-Engineering.dev: Why Perplexity is stepping back from MCP internally (March 16, 2026)
• Repello AI: MCP vs CLI, what Perplexity's move actually means (March 17, 2026)
• Dash0: MCP vs API, what's the difference and when to use each
• Kong: Build vs buy, the hidden costs of DIY MCP servers
• Scalekit: Should you build MCPs before APIs?
• Tool-gating evaluation across 18 models and 5,346 runs (via r/mcp)
• MCP vs Skills for connecting a SaaS product to AI (via r/mcp)
• Build notes: OAuth 2.0 and Dynamic Client Registration for an MCP server (via r/mcp)
• Build notes: tool annotations and description drift on a remote MCP server (via r/mcp)

Community quotes are attributed to the subreddit they were published in and never to an individual account. Vendor and engineering posts are quoted from the pages linked above as read on September 2, 2026. The MCP specification and its client implementations change frequently enough that behavioural claims about caching, transports and annotations should be re-checked against the current spec revision before you rely on them.