MCP vs API: What Each One Actually Costs an AI Agent (2026)

MCP and a REST API are not two designs competing for the same slot. The MCP server calls the REST API underneath, so the real question is what the extra layer costs and when that cost buys something. We measured both paths against the same Reddit query on 2026-09-08 and the numbers are not close to what the argument assumes.

TL;DR: MCP and REST are not rivals, the MCP server calls the REST API underneath. Measured on 2026-09-08: 43 tool schemas cost 24,694 tokens every turn, one search result at page size 100 cost 85,534, and latency through the wrapper was 2,096.6 ms against 2,235.2 ms direct. Choose on token budget, not architecture.

What you will get from this post: the measured token cost of both paths, a latency comparison with the null result reported honestly, the spec diff that makes four of the nine top-ranking pages wrong about statefulness, a decision table keyed to your situation, a section on when not to use MCP at all, and a one-call probe that tells you which protocol revision any server implements. Every number carries the date it was true and the command that produced it.

What is the difference between MCP and an API?

An API is an interface a developer programs against. MCP is a protocol that describes an API to a language model so the model can find and call it without a developer writing a wrapper for each host first. The difference is the intended consumer, not the transport. Both are HTTP underneath.

That framing is not ours. Priyanka Vergadia, who has spent 15 years building AI and cloud systems at Google, Microsoft and Intel, put it in one line that has held up better than most of the explainers written since:

The practical consequence is the one worth internalising before any cost argument. When you write a direct REST integration you decide the endpoint, the arguments, the order and the error handling, and the model never sees any of it. When you put an MCP server in front of it, the model reads a description of what is available and decides. You have moved a build-time decision to runtime, and runtime decisions are paid for in tokens and turns.

Nothing in that stack is optional except the middle layer. The REST endpoint exists in both designs, Reddit exists in both, and the model exists in both. If you are choosing, you are choosing whether to add a layer, not which of two layers to pick. For the wider set of paths available, including RAG and framework-native tools, the hub on the Reddit API for AI agents covers all four and this post deliberately does not restate it.

The same comparison in text, so it can be quoted without opening the image:

Is MCP just a wrapper around a REST API?

Mostly yes, and conceding it immediately is the only honest way to start. An MCP server holds no data of its own. It receives a tools/call, issues the same HTTP request your code would have issued, and returns the response. What it adds is a machine-readable description, a standard discovery path, and somewhere for the credential to live.

This is the question every team shipping a server ends up answering for itself, and the most useful answer comes from one that went all the way:

They exposed roughly 150 tools across 21 domains behind OAuth 2.1, ran their own project management through it, and came back with three things worth borrowing. Agents are the most brutal API reviewer you will get, because every inconsistent parameter name and every endpoint that returns too little surfaces the moment one starts calling you daily. Tool descriptions stop being documentation and become the thing that decides whether a tool is ever selected. And the payoff only arrived once the whole domain was exposed, rates and time and invoices together, rather than one convenient slice. Auth, tool surface, live data: that is a better decision rule than most of what ranks for this query, and the rest of this post is an attempt to put numbers behind each of those three clauses.

So the framing is not MCP against REST. It is: does the wrapper earn the tokens it costs. That reframing is what makes the question answerable, because tokens are measurable and architecture arguments are not. The answer for our own server, measured rather than estimated, is 24,694 tokens of schema in every single turn. Whether that is cheap depends entirely on what you are doing with it.

What the 2026-07-28 MCP spec revision changed, and why page one is out of date

The single largest factual problem with the current search results for this query is that most of them describe a protocol version that no longer exists. Four of the nine ranking pages lead with a stateful-MCP-against-stateless-REST framing. As of revision 2026-07-28, the core protocol is stateless.

Read the specification's own Key Changes page rather than any explainer. Three of the major changes matter for this comparison:

1. Protocol-level sessions and the Mcp-Session-Id header are removed from the Streamable HTTP transport, under SEP-2567. List endpoints no longer vary per connection. A server needing cross-call state uses explicit, server-minted handles passed as ordinary tool arguments.
2. The initialize and notifications/initialized handshake is removed, under SEP-2575. Every request now carries its own protocol version and client capabilities in _meta. A mismatch returns UnsupportedProtocolVersionError.
3. server/discover is added and servers MUST implement it, advertising supported protocol versions, capabilities and identity. Clients may call it before anything else, or use it as a backward-compatibility probe on stdio.

There is a fourth change that will bite anyone porting an older server: Roots, Sampling and Logging are all deprecated under SEP-2577, with a minimum twelve-month removal window and a deprecated features registry tracking every feature in that state. The suggested migrations are worth knowing because they push work back toward plain code: pass files via tool parameters or resource URIs instead of Roots, integrate with a provider API directly instead of Sampling, and log to stderr or OpenTelemetry instead of Logging.

Two more changes are quieter and directly relevant to the token argument that dominates every practitioner thread. SEP-2549 makes ttlMs and cacheScope required fields on tools/list results, so a client can cache the tool catalogue instead of refetching it. And the Tools page now says servers SHOULD return tools in a deterministic order specifically to "enable clients to reliably cache the tool list and improve LLM prompt cache hit rates." The protocol grew an answer to its loudest complaint, and nothing on page one mentions it.

Industry context: what actually changed in 2026, and who is arguing

The MCP argument in 2026 is not a two-sided technical disagreement, and the Reddit API for AI agents hub already maps the four integration paths it keeps collapsing into two. It is a measurement problem wearing a philosophy costume. One camp cites context bloat, the other cites tool count, and both are describing the same number from different distances.

Three positions are actually in play, and they separate cleanly once you ask what each one measured before it spoke:

• The protocol is the problem. MCP eats the context window, so drop it for CLIs and plain APIs. Loud, widely shared, and almost never carrying a figure.
• Tool shape is the problem. The overhead is real and it tracks how many tools you loaded and how verbose their schemas are, both of which you chose.
• Neither, the middleware is what moved. APIs are not going away. The layer between the model and the API is being rebuilt, and MCP is a candidate for that layer rather than a replacement for the API.

Only the second and third arrive with numbers attached, which is why the rest of this post reports its own rather than joining the first.

@levelsio

@levelsio

Thank god MCP is dead Just as useless of an idea as LLMs.txt was It's all dumb abstractions that AI doesn't need because AI's are as smart as humans so they can just use what was already there which is APIs

The objection has weight because the people making it ship things. It also has almost no numbers in it. The rebuttal from inside the practitioner threads is more precise, and it relocates the argument from the protocol to what you are willing to maintain:

Its case is that skills and CLI ship fast and save tokens by using the model as a database, with state living in the prompt rather than in code, and that a context window is not a storage layer. MCP servers are more work, and that is the point. The room split almost exactly down the middle on it, 43 comments at a 0.39 upvote ratio, which is a better description of where this debate actually sits than either side's headline.

Meanwhile the vendor side has converged on a third position that is neither camp. A Google Cloud advocate's framing, widely reshared, is that APIs are not dying but being rebuilt so that models rather than only humans can use software, and that MCP replaces the middleware between the model and the API rather than the API itself. That is the same conclusion our measurements support, arrived at from the opposite direction.

MCP vs API: Simplifying AI Agent Integration with External Data

IBM Technology

What changed in 2026 specifically: the protocol went stateless in July under the 2026-07-28 changelog, the tooling ecosystem discovered that tool shape beats tool count, and at least three separate teams published measurements showing the same thing. That last part is why this post is measurements and not opinion.

The RedditAPI Two-Tax Test: the framework that survived our measurements

Every MCP-against-REST decision reduces to two token taxes, and almost every public argument is about the smaller one. Name them separately and the decision stops being contested. We call this the RedditAPI Two-Tax Test, and it has exactly two terms plus one ratio.

The definition tax is the tokens your tool schemas occupy in the model's context. It is a function of tool count and schema verbosity, it is resident in every turn whether or not any tool is called, and it is what everyone means when they say MCP eats context. On our published server that is 24,694 tokens.

The result tax is the tokens a tool's response occupies. It is a function of rows times fields, it is paid per call, and it has no ceiling other than whatever page cap the API enforces. On our search endpoint at the maximum page size that is 85,534 tokens.

The Result-to-Definition Ratio, or RDR, is the second divided by the first for one typical call. RDR above 1 means your context problem is your data, not your tool count, and scoping the catalogue will not save you. Measured on our own surface:

• limit=10 gives RDR 0.41. Schema dominates, so pruning tools is the real lever.
• limit=25 gives RDR 1.02. The crossover. Both taxes cost about the same.
• limit=100 gives RDR 3.46. Data dominates, and no amount of tool pruning touches it.

Read the ratio before you read anyone's opinion. It tells you which of the two arguments you are actually having.

The reason this matters more than a feature table: the definition tax is under your control and the result tax mostly is not. You choose how many tools to expose. You do not choose how many fields Reddit returns on a post, and there are 22 of them.

Does MCP use more tokens than a direct API call?

Yes, and the schema is the smaller half of the answer. Measured on 2026-09-08 against our own published server with tiktoken encoding cl100k_base, 43 tool definitions total 98,099 bytes and 24,694 tokens. That is 12.35 percent of a 200,000 token window, paid in every turn, before any question is asked.

The distribution inside that figure is the actionable part. The median tool costs 434 tokens. The two most expensive, reddit_monitor_add at 2,366 tokens and reddit_monitor_update at 2,151, together cost more than the four read tools an exploratory agent actually uses. The ten-tool monitoring family accounts for 8,045 tokens, 32.6 percent of the whole catalogue, for a capability most agents never touch.

So the lever is obvious and it is entirely yours: exposing only reddit_search, reddit_subreddit_posts, reddit_post_comments and reddit_subreddit_about costs 2,311 tokens instead of 24,694. That is a 90.6 percent reduction with no change to the protocol, no change to the server, and no loss of any capability the agent was going to use. The search tool alone costs 1,204 tokens, 0.60 percent of the window.

Which puts the loudest public numbers in perspective. Notion's official server has been measured at 21,411 tokens and Firecrawl at 18,511; a Google Workspace setup at 142 tools reached roughly 37,000. Our 43-tool surface at 24,694 sits squarely inside that band. None of those figures are a protocol property. They are all the same authoring decision made at different scales.

Aakash Gupta

@aakashgupta

Google just gave your AI agent a way to access every Workspace API that doesn’t eat half your context window. Here’s the problem everyone’s been hitting. The standard way to connect Claude Code or Cursor to Gmail, Drive, and Calendar is through MCP servers. Google ships official

How big is one tool result? The number page one omits

This is the measurement that reframes the whole argument, and not one of the ten pages ranking for this query publishes anything like it. One search call at page size 100 returned 336,115 bytes and 85,534 tokens. That is 42.77 percent of a 200,000 token window, from a single tool call.

The scaling is close to linear at roughly 855 tokens per post, because a Reddit post record carries 22 top-level fields and one serialises to about 919 bytes. That linearity gives a break-even worth memorising: at about 29 posts, one search result costs as much context as all 43 tool definitions combined. Twenty-nine posts is not a large query. It is a default page.

Two things follow, and they point in the same direction:

• A team that carefully prunes its tool catalogue and then lets an agent request full pages has optimised the wrong term. The saving is real and it is the smaller number.
• At a nominal $3 per million input tokens, 85,534 tokens costs about $0.257 in model input for a call whose API price is $0.002, as the Reddit API pricing breakdown sets out. The token cost is roughly 128 times the API cost.

Substitute your own model rate. The ratio is what matters, and it does not favour putting raw pages into a context window.

The spec contains a trap here worth naming, because it doubles the result tax silently. The Tools page says that for backwards compatibility, a tool returning structured content SHOULD also return the serialised JSON in a text block. A server that does both puts the same payload into context twice. Ours returns one text block and no duplicate, which we checked rather than assumed: the MCP result text measured 122,317 bytes against 122,318 for the identical direct response, a one-byte difference that is a trailing newline.

What is the latency cost of putting an MCP server in front of an API?

Smaller than the upstream API's own variance, and we are reporting that as a null result rather than dressing it up. Twelve timed calls per path, same query, page size 25, one keep-alive connection each: direct REST measured a p50 of 2,235.2 ms, and the same call through the MCP server measured 2,096.6 ms.

The wrapper measured 138.6 ms faster. That is not a finding about MCP being efficient. It is a finding about both numbers being dominated by the same roughly two-second upstream call, with run-to-run spread wider than the difference. The direct path's own p95-to-p50 gap is 227.1 ms, larger than the 138.6 ms delta, which is the arithmetic that turns this into a null result rather than a win.

What the measurement does not include, and this is the honest caveat: a model turn. Our harness sent tools/call directly. A real agent has to decide to call the tool, which is one inference pass, and that pass is almost always larger than the hop. So the correct statement is that the MCP server adds no meaningful latency and the agent loop around it adds plenty. If latency is your constraint, the number to attack is turns, not hops.

One more figure, because it is the one people actually feel. Cold initialize against a locally spawned stdio server measured 2,760.8 ms, almost all of it process spawn rather than protocol. Subsequent tools/list took 22.5 ms. A remote server over HTTP would add a network round trip that a local stdio server does not have, so treat our hop figure as the floor. For latency and uptime on the API itself across a longer window, the Reddit API benchmark for latency, uptime and cost has the sustained numbers this snapshot does not.

How does MCP handle pagination on large result sets?

It does not handle it for you, and after 2026-07-28 the specification says so in normative language. This is the single most consequential gap for anyone pointing an agent at a deep data source, and pagination appears meaningfully in none of the ranking article bodies for this query.

Read that carefully: the model is responsible for carrying the handle forward. There is no protocol machinery that pages for you, and there never was; before 2026-07-28 people could at least imagine the session was doing something. The protocol does define pagination, but only for its own list endpoints such as tools/list, which return a nextCursor. Your data is not a list endpoint, so none of that applies to a tool result.

Here is what that means concretely against our own endpoint, measured. A call at limit=25 returns 25 posts plus an after cursor. A call at limit=100 returns 100 posts plus a cursor, in our run the opaque token eyJhIjoidDNfMXNzZ2JjcyIsImQiOjEwMH0, which base64-decodes to {"a":"t3_1ssgbcs","d":100}. Passing that back as the after argument returned the next 100. Asking for limit=101 or limit=150 returned HTTP 400 with {"error":"limit must be an integer between 1 and 100"}.

So the failure mode is precise and silent. If your tool schema does not declare the cursor argument, the agent reads page one and stops, and reports success. It has no way to know a second page exists. That is the top-voted concern in the highest-ranking discussion for this query, and the fix is one property in an input schema plus a description telling the model what the cursor is for.

The spec's own handle guidance applies directly: treat the handle as a name rather than a capability and authorise it on every call, keep it opaque, state its lifetime in the tool description so the model can see it, and return a clear execution error when it expires so the model can recover by starting over. Our cursor is opaque and short-lived by construction. For the mechanics on the REST side, Reddit API pagination covers cursor behaviour and the practical ceilings in more depth than a tool schema can carry.

How does authentication differ between MCP and a REST API key?

This is the one axis where MCP has a structural answer rather than a convenience one, and it is the reason to build a server even when the token math is unflattering. In a direct REST integration the key lives wherever your code puts it, and if an agent is making the call, the agent is holding it.

With a remote MCP server the credential lives server-side. The client authorises against the server, usually over OAuth, and the model never sees a bearer token at all. Nothing about the REST path can offer that, because the REST path has no third party to hold anything.

The 2026-07-28 revision tightened the surrounding machinery in three ways worth knowing before you build. Authorization servers SHOULD include the iss parameter in authorization responses per RFC 9207, and clients MUST validate a present iss against the recorded issuer before redeeming the code. Client credentials are now explicitly bound to the issuing authorization server, so clients MUST key persisted credentials by issuer and MUST re-register when it changes. And RFC 7591 Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents, remaining only for backwards compatibility.

There is also a new way to leak a secret that did not exist before. The x-mcp-header annotation lets a server mirror a primitive tool parameter into an Mcp-Param-{name} HTTP header so load balancers and WAFs can route on it without parsing the body. Values must match HTTP field-name token syntax per RFC 9110 Section 5.1 and may only be applied to string, integer or boolean parameters. The spec's warning is blunt and correct: server developers SHOULD NOT mark sensitive parameters, passwords, API keys, tokens or PII, with x-mcp-header, because those values are visible to network intermediaries.

For a local stdio server, note that none of the OAuth benefit applies. A locally spawned process reads the key from its own environment, which is the same trust boundary your own script has. Our own server reads REDDITAPIS_KEY from the environment, so a local install is exactly as safe as a local script and no safer. If you want the custody benefit, you want a remote server. The Reddit API authentication and OAuth guide covers the token model on the REST side, and the full API documentation has the header shape.

What happens to rate limits, quotas and per-call billing when an agent drives the API?

The protocol changes nothing about your quota and everything about how fast you spend it. Only three of the nine ranking pages mention rate limiting at all, and none of them quantify how an agent loop multiplies call volume, which is the part that shows up on an invoice.

Start with the fixed facts. Reads on our endpoint cost $0.002 a call, identically through MCP or direct, so 1,000 calls is $2.00. That figure is on the pricing page and does not move with your protocol choice. Upstream, Reddit's own API documentation sets the OAuth ceiling at roughly 100 queries per minute, and the Reddit Data API Terms govern the commercial position regardless of which path you take.

Now the multiplier. A deterministic script that needs 500 posts issues 5 calls and stops. An agent asked the same question decides how many calls to make, and it decides badly in two specific directions: it re-queries when a result looks incomplete, and it re-reads pages it already has because the earlier result scrolled out of its context. Both are direct consequences of the result tax. At 855 tokens per post, an agent that has read 200 posts is carrying 171,000 tokens and is about to start forgetting the beginning.

The specification does put an obligation on the server side here. Under Security Considerations for tools, servers MUST validate all tool inputs, implement proper access controls, rate limit tool invocations, and sanitise tool outputs. Rate limiting is not optional for a compliant MCP server, which is a useful thing to know when you are evaluating somebody else's.

Three controls are worth building before you let a loop run:

• Cap the page size the tool accepts rather than passing the API's maximum straight through. One line, and it is the difference between a bounded call and an unbounded one.
• Return a count and a cursor rather than the full page when the agent is only checking whether results exist. Most exploratory calls do not need the rows at all.
• Put a hard call ceiling per task in the server, not in the prompt, because a prompt is a request and a ceiling is a constraint. Webhooks against polling for Reddit data streams covers the push-shaped version of the same problem. Reddit API rate limits covers the upstream ceilings those controls have to respect.

Can an AI agent call a REST API without MCP?

Yes, and it is still the cheapest path in tokens. Function calling and tool use predate MCP: you describe the endpoint in the model's own tool schema, the model emits a structured call, and your code executes the HTTP request. OpenAI's function calling documentation describes the mechanism, and every major provider supports some form of it.

The reason it is cheaper is not subtle. You write one schema with exactly the arguments you need, so you pay for those and nothing else. Our reddit_search definition costs 1,204 tokens because it exposes 19 properties including six numeric filters and four boolean flags. A hand-written schema exposing q, limit and after would cost a small fraction of that, and would lose only the filters your specific agent was never going to use.

What you give up is portability, and this is the actual product MCP sells. A hand-written function schema works in the one runtime you wrote it in. An MCP server works in Claude, in Cursor, in an IDE extension and in any other MCP-speaking host with no rewrite. If you have one client, that portability is worth nothing and you are paying for it in schema tokens.

A recurring question from practitioners deserves a direct answer here, because nobody on page one gives one: why not just hand the model the OpenAPI spec? You can, and for a small API it works. What it does not give you is a uniform invocation path across hosts, a place for the credential to live, or a discovery call with a version contract. It also does not solve the token problem, since an OpenAPI document for a real API is usually larger than the equivalent tool schemas, not smaller. The honest answer is that MCP is a specific, standardised API with a client ecosystem, which is exactly what its critics say, and the ecosystem is the value.

For the framework-native middle ground, the concepts guide on what AI agents are, with tool use and function calling covers how the same call looks in each mechanism.

Do I have to maintain both an MCP server and a REST API?

Yes, and it is the most-repeated objection in practitioner threads for good reason. Adding an MCP server does not retire the REST API, so you now have two pieces of software to deploy, version, monitor, secure and keep in agreement. The wrapper is not free after it ships.

Our own architecture makes the shape visible. The REST endpoint has six consumers:

• the MCP server
• a CLI
• an agent skill
• hand-written function calls inside customer code
• backend services on a schedule
• humans in notebooks

The MCP server is one of six. Removing it removes none of the others, and the API layer would exist unchanged if it had never been built.

That is the version of the maintenance argument worth taking seriously, and it cuts both ways. If you already run the API, the marginal cost of the MCP server is one more deployable, and it buys you every MCP client at once. If you are choosing between building one or the other, there is nothing to choose: you build the API, because the MCP server needs it to exist.

There is a real architectural constraint on top of the maintenance cost, and it is the one that decides whether a pure-MCP integration survives contact with a production agent stack. In Claude Code, sub-agents cannot use MCP; only the main orchestrator can. Teams therefore end up needing a CLI or direct-REST fallback path anyway, at which point they are maintaining three surfaces rather than two. Reddit API as an agent skill covers the skill-shaped alternative, which is closer to a CLI in context cost.

How many MCP tools can an agent hold before answer quality drops?

There is no published threshold, and anyone quoting one is guessing. There are two hard signals and one measurement, and together they are more useful than a number would be:

• A vendor ceiling. Cursor caps users at 40 MCP tools.
• A practitioner's reversal. A former Manus backend lead dropped typed tool catalogues entirely, because selection accuracy falls as the catalogue grows.
• Our own scoping result. 43 tools cost 24,694 tokens; the four read tools an exploratory agent actually uses cost 2,311.

The first signal is a product decision: Cursor caps users at 40 MCP tools. Practitioners cite that cap constantly as evidence the limit is structural rather than a configuration mistake they made themselves, and it is a reasonable reading. A vendor does not impose a ceiling on a feature people want unless the alternative is worse.

The second is a practitioner reversal, and it is the most-upvoted account of the problem anywhere in these threads:

After two years building agents, a former backend lead at Manus stopped exposing a catalogue of typed functions and gave the model one command tool instead, on the grounds that the more tools you add the harder the selection gets and the worse the accuracy. His replacement for schema loading is progressive discovery: a one-line summary per command upfront, full usage only when the model asks for it, rather than three thousand words of tool documentation sitting in the system prompt on every turn. He names the tension in his own design too, that the injected command list still grows with the command count, which is the same tax wearing different clothes.

The strongest available evidence says the variable is tool shape, not tool count. One tester ran the same models and tasks with 35 raw tools against 2 workflow tools built from the same primitives. Raw tools: 10 percent success, about 12,880 tokens per run. Workflow tools: 79 percent success, about 1,078 tokens per run. Putting the 35 tools behind a search interface cut tokens but left completion at 10 percent, which is the finding that matters, because it separates the context problem from the orchestration problem. Compressing schemas does not teach a model to chain calls.

The same conclusion arrives from the server side. One team moved orchestration behind the tool boundary completely, exposing a single goal-shaped tool whose sub-agents run server-side, and reports the schema tax nearly disappearing because the client loads one small definition instead of a catalogue, with token cost staying roughly flat as the reasoning gets deeper. They are honest about the price: each call does more work so each call is slower, and the client can no longer inspect or steer the chain mid-flight.

Our own contribution to this is the 90.6 percent figure, and its limitation. Scoping 43 tools to 4 saved 22,383 tokens without changing anything the agent could do, because the 39 tools removed were monitoring, webhook and feedback surfaces an exploratory agent never calls. That is a real saving and it is also the easy case. It says nothing about whether four endpoint-shaped tools beat two capability-shaped ones, which is the harder question and the one the 35-against-2 result answers.

Which is better for high-throughput data pulls, MCP or REST?

REST, and this one is not close. Bulk retrieval is a deterministic, high-call-count workload with no discovery step, so routing each page through a model turn adds tokens and latency in exchange for nothing. The arithmetic settles it before any preference does.

At roughly 855 tokens per post, ten pages of 100 posts is about 855,000 tokens of results. No production context window holds that, so the agent will drop earlier pages, and an agent that has silently dropped page three is an agent producing a wrong answer confidently. This is not a tuning problem. It is the wrong shape.

The correct architecture for volume separates retrieval from reasoning completely:

• Pull pages with a deterministic loop over the REST endpoint, with your own retries and your own cursor bookkeeping.
• Land them in your own storage, where rows are rows rather than tokens.
• Let the agent query that storage, where you control how much comes back per question.

Intermediate rows never enter the context window, which is the whole point. Bulk fetch by id on the Reddit API covers the retrieval loop itself.

That pattern has a name in the wider discussion now, and it is worth knowing because it is the strongest current answer to the token problem. One team let the model write short scripts against the APIs instead of chaining tool calls, so intermediate results stayed out of context, and went from 508 tools and 75.1 million input tokens at $377 per test run (the run is posted in full) down to 5.4 million tokens at $29, with 100 percent of test cases still passing. The saving scaled with tool count: 58 percent at 96 tools, 84 percent at 251, 92 percent at 508.

For the retrieval-and-index shape specifically, Reddit as a RAG data source covers the storage side, and Reddit API pricing has the per-call arithmetic for sizing a bulk pull before you start one.

When should I use MCP instead of calling the API directly?

Use MCP when more than one MCP-speaking client needs the capability, when the agent must choose calls at runtime, or when the credential must not reach the agent. Call REST directly when the workflow is fixed, throughput matters, or you need deterministic control over pagination and retries. The table below keys those to a situation rather than a feature list.

Five conditions justify the server, and meeting one is usually not enough:

• Many clients, so the schema cost is divided across hosts rather than paid by one.
• Runtime choice, so the agent picks calls you did not enumerate in advance.
• Key custody, so a bearer token never reaches a model.
• A small tool count, under roughly ten, so the definition tax stays near one percent of the window.
• Long sessions, so the one-off schema cost amortises across many turns instead of being paid per question.

The decision rule that came out of our own numbers is narrower than any of the ranking pages offer, and it fits in one line: build the MCP server when your RDR is below 1 and your client count is above 1. Below RDR 1 the schema is the dominant cost and scoping it is a real lever. Above RDR 1 the data dominates, and no amount of tool pruning helps, so the protocol question is answering the wrong problem.

Applied to our own surface that means MCP for interactive exploration at page sizes of 10 to 25, where RDR sits between 0.41 and 1.02, and REST for anything requesting full pages. That is not a compromise position. It is what the two taxes imply once you stop treating them as one number.

When not to use MCP at all

None of the nine ranking pages carries this section, while the live People Also Ask box for this query is openly sceptical, asking whether MCP is just a fancy API and why not use direct API calls. The gap is worth filling plainly, because the honest answer to both questions is sometimes yes and often nothing.

Four cases, and they are common ones:

• A single consumer. If one pipeline calls the API, a protocol designed for many hosts is overhead with no beneficiary, and you are paying schema tokens to serve an audience of one.
• A fixed workflow. If you already know the endpoint, the arguments and the order, there is nothing for the model to discover, and letting it discover anyway adds a turn and a failure mode.
• Bulk pulls and deep pagination, for the reasons the throughput section covers. Ten thousand rows through a context window is the wrong shape at any token price, and it stays wrong when tokens get cheaper. The mechanics are in Reddit API pagination.
• One call. A single webhook or one-off query does not need a catalogue, a discovery step or a schema. The received wisdom in the builder crowd, attributed to Andrej Karpathy, puts CLI at the top of the hierarchy, API in the middle and MCP at the bottom, and for one-shot work that ordering is defensible. Where it stops being defensible is multi-client, multi-turn work, which is where the amortisation argument actually applies.

One qualifier on all four. If you are already shipping an API and evaluating whether to add a server, the calculation is different from choosing between them, because the API exists either way. The question is never MCP or REST. It is REST, plus a server or not.

How do I expose an existing REST API as an MCP server?

Six steps, in order, and step five is the one that decides whether the server survives real use. This is the walkthrough the highest-ranking pages raise as a heading and answer in prose without a procedure. FastMCP is the usual Python starting point.

1. Pick the endpoints an agent needs, not all of them. Our own catalogue is the counter-example: 43 tools where 4 carry almost every exploratory session, at 10.7 times the schema cost.
2. Shape tools around capabilities, not endpoints. One tool per endpoint pushes orchestration onto the model, which is exactly what the 35-against-2 measurement shows it is bad at.
3. Declare the pagination cursor explicitly, with a description saying what it is for. Omit it and the agent reads page one and reports success.
4. Hold the credential server-side. For a remote server this is the main thing you are buying. For a local stdio server it is the same trust boundary as a script, so do not claim it.
5. Cap the page size in the tool, below the API's maximum. This is the single highest-value line of code in the server, because it is the only thing standing between one tool call and 42.77 percent of the context window.
6. Probe your own protocol version before shipping, so you know which revision you implement rather than which one you assume.

Here is the shape, with the cursor and the cap as first-class arguments:

# reddit_mcp.py
import os
import httpx
from fastmcp import FastMCP

mcp = FastMCP("reddit-search")
KEY = os.environ["REDDITAPIS_KEY"]          # never a tool argument
BASE = "https://api.redditapis.com/api/reddit"
MAX_PAGE = 25                                # step 5: below the API's own 100

@mcp.tool()
async def search_reddit(q: str, limit: int = 10, after: str | None = None) -> dict:
    """Search Reddit posts. Returns up to `limit` posts plus an `after` cursor.
    Pass the cursor back as `after` to get the next page. `limit` is capped
    server-side at 25 to keep one call from filling the context window."""
    params = {"q": q, "limit": min(limit, MAX_PAGE), "sort": "relevance"}
    if after:
        params["after"] = after              # step 3: the handle, as an argument
    async with httpx.AsyncClient(timeout=30) as client:
        r = await client.get(f"{BASE}/search", params=params,
                             headers={"Authorization": f"Bearer {KEY}"})
        r.raise_for_status()
        body = r.json()
    return {"posts": body.get("posts", []), "after": body.get("after"),
            "returned": len(body.get("posts", []))}

The min(limit, MAX_PAGE) is not defensive style. It is the difference between a tool that costs at most 25,255 tokens per call and one that can cost 85,534. For the full server with monitoring and write tools, how to build a Reddit MCP server walks the whole loop, and Reddit MCP servers that need no API key covers what the keyless options actually do and where they stop working.

The RedditAPI Revision Probe: one call that dates any MCP server

Step six needs a method, and there is a clean one that did not exist before July 2026. Because server/discover is mandatory in revision 2026-07-28, a server that answers it with -32601 Method not found has told you it predates that revision. One call, unambiguous answer.

We ran it against our own published server and are reporting what it said rather than what we would prefer.

redditapis-mcp v0.5.3 accepted an initialize with protocolVersion: 2025-06-18, returned capabilities: {tools: {listChanged: true}}, and answered server/discover with -32601. So it implements the pre-2026-07-28 model: the handshake it should no longer need, and not the discovery call it now MUST have. That is a migration gap, we are naming it, and the probe is the reason we know rather than assume.

Two side findings from the same four calls are worth keeping. A tools/call with a misspelled argument returned isError: true carrying MCP error -32602: Input validation error: Invalid input: expected string, received undefined at q. That is a tool execution error rather than a protocol error, which is what the spec recommends, because the model can read it and retry. Calling a tool that does not exist also returned isError: true rather than the JSON-RPC protocol error the spec suggests for unknown tools, which is a small divergence but one a strict client could notice.

Run the probe against any server you are evaluating, including ones you did not write. It costs one message, it needs no credentials, and it answers a question no README reliably answers: which revision is this, actually.

Methodology: how these numbers were produced, and what would falsify them

Every figure above came from a live server and a live endpoint on 2026-09-08, and each table carries its own methodology and falsification condition. This section states the shared parts once so the tables do not have to repeat them.

Tokenizer. Every token count uses tiktoken with encoding cl100k_base, over the exact bytes measured. Percentages of a context window use 200,000 tokens as the denominator, stated rather than assumed, so a different window size rescales cleanly.

Definition tax. redditapis-mcp v0.5.3 was started over stdio, sent initialize, then notifications/initialized, then tools/list. Each returned tool definition was serialised back to JSON and counted individually and in named subsets. Byte counts are UTF-8 length.

Result tax. One GET per page size to the managed search endpoint, query model context protocol, sort=relevance, uncompressed, tokens counted over the raw response body. Page sizes of 101 and 150 were probed to establish the cap.

Latency. Twelve timed calls per path, page size 25, query mcp vs api, run back to back. The REST leg used one keep-alive connection with the first call discarded as warm-up, so no TLS handshake is inside any timed figure. The MCP leg drove a local stdio server, timed from write to the matching response id. Both legs ran from the same machine on the same network within a few minutes of each other.

What would change these numbers. A new package version altering the tool set changes the definition tax. A change to the endpoint's field set or page cap changes the result tax. A remote rather than local MCP server adds a network hop to the latency figure and would make the wrapper measurably slower. And a client that caches tools/list under the 2026-07-28 ttlMs contract changes the definition tax from per-turn to per-cache-window, which is the single change that would most improve these figures.

What we did not measure. Task success rate against tool count, which needs an eval harness and a fixed task set. We cite other people's numbers for that and label them as theirs. We also did not measure a remote MCP server over HTTP, so every latency figure here is a local-transport floor rather than a production ceiling.

What we got wrong while measuring this

Four instruments produced plausible wrong answers before producing right ones. We are printing them because a measurement post without this section is asking to be trusted on the numbers it happened to keep.

A 3.2 ms latency win that was a validation error. The first MCP timing run sent the argument query where the tool requires q. Median came back at 3.2 ms with a 199-byte result, which read as the wrapper being 700 times faster than the API. A 3 ms result is the shape of a rejection, not a call. Worse, the server returned it as isError: true inside a normal result, so a harness that only checks for a JSON-RPC error key scores it as a success. Reading the payload size, not the status, is what caught it.

A 567 ms difference that was a TLS handshake. The first latency comparison ran the REST leg as one curl per call and the MCP leg over a persistent stdio process. REST measured 2,705.6 ms at p50 against 2,138.7 ms through MCP, which looks like a real finding and is a connection-reuse artefact. Re-running the REST leg on one keep-alive connection moved the delta from 566.9 ms to 138.6 ms. The comparison was never about the protocol.

A byte count that was 2.6 times too small. curl -w '%{size_download}' with --compressed reported 46,751 bytes for a 25-post page that is 122,318 bytes uncompressed. size_download is the wire size after compression. Any token estimate derived from it would have been low by the same factor, and it would have looked entirely reasonable.

An empty page inside a loop. One payload run crashed indexing into an empty posts array mid-sequence. The useful part is that it crashed: had the loop averaged a zero-length response into the per-post figure, the result would have been a slightly low number with nothing to indicate it was wrong.

The pattern in all four is the same. Each produced a specific, plausible figure that supported an interesting conclusion, and each was caught by asking whether the number was the right order of magnitude before asking what it meant. If a wrapper appears to make an API 700 times faster, the instrument is broken.

Verdict

MCP does not replace your REST API; it sits on top of it, and the API is what does the work. So the decision is not which to pick but whether to add a layer, and that decision is a token-budget decision with two terms.

The definition tax is what everybody argues about and it is the smaller half. Ours is 24,694 tokens across 43 tools, 12.35 percent of a 200,000 token window, and scoping to the four tools an agent actually uses cuts it 90.6 percent to 2,311. That lever is entirely yours and it is cheap to pull.

The result tax is what nobody publishes and it is the half that decides architectures. One search at page size 100 returned 85,534 tokens, 3.46 times the entire catalogue, and at a nominal $3 per million input tokens that is roughly 128 times the $0.002 the call itself costs. Latency, for what it is worth, was a null result: 2,096.6 ms through the server against 2,235.2 ms direct, a difference smaller than the direct path's own spread.

So, in the order you will need them:

• Build the MCP server when your RDR is below 1 and your client count is above 1.
• Cap the page size inside the tool, below whatever the API allows.
• Declare the cursor as an explicit argument, or the agent silently reads one page and reports success.
• Keep the key server-side, and do not claim that benefit for a local stdio install, because there it is not true.
• Pull volume over REST into your own storage and let the agent query that instead. Reddit as a RAG data source covers that shape end to end.
• Run the revision probe on whatever you built, because knowing which protocol revision you implement beats assuming it.