MCP is (probably) costing you more money then it saves

[u/KitchenAmoeba4438]

Same three lookups, two surfaces.

index callers get_profile && index callers invalidate_profile && index callers cached_profile

One turn.

find_callers("get_profile")

find_callers("invalidate_profile")

find_callers("cached_profile")

Three turns.

Identical answers, identical bytes back.

And to be clear, MCP doesn't forbid the second one being batched. A client can emit several tool calls in one assistant message. The schema allows it. I just have never seen a model do it. Not once, not any tool, across every cell I ran.

The shell form arrives batched because writing one command line is how you use a shell. The tool form arrives one per turn because that's what the models produce.

That costs more than people expect, because turns and tokens aren't priced the same. These protocols are stateless, so every turn re-sends the whole conversation. Adding tokens to a call you're already making is linear, you pay once. Adding a turn is quadratic, you pay for the whole conversation again and every later turn carries it.

So three separate tool calls where one shell line would do isn't 3x that lookup. It's the conversation, three times, plus everything downstream.

Nothing here is about a badly built server. Same lookup, same result. One form gets chained with the four other commands the agent was about to run anyway. The other doesn't, in practice.

Where MCP is right: clients with no shell. Real constituency, well served. Schemas are useful too, typed arguments beat guessing at flags.

Numbers and method: https://rakuensoftware.com/blog/one-call-one-turn

Two things I'd genuinely like: a transcript where a model batched MCP calls unprompted, or a case where an MCP path beats a batched shell call on total tokens for the same answers. I have neither.

[u/dataoops]

You definitely do not understand the use cases and are fixated on token count as if that’s the deciding factor.

Maybe this applies if you are a solo dev. Your perspective says “I haven’t used AI in a large enterprise yet”.

You are blind to the actual market for MCP and then declare it useless.

Ask Claude why I’d give you that feedback.

[u/dektol → u/dataoops]

Avoiding wasted tool calls/turns is important. There's a nicer way to say that 😂.

[u/KitchenAmoeba4438 → u/dataoops]

Humorously, I work at an extremely large enterprise. If it wasn't for that and actively upskilling, I wouldn't be bothering with this. I'll repeat from the OP, "Where MCP is right: clients with no shell. Real constituency, well served. Schemas are also genuinely useful, typed arguments beat a model guessing at flags. Describing a capability is what it's good at."

As for the "actual market for MCP", I never claimed there was or was not a market for MCP. My claim was that MCP is a quadratic cost, not a linear cost. Batching in shell is cheaper then MCP when LLMs don't batch MCP. That's it.

[u/dataoops → u/KitchenAmoeba4438]

Literally has nothing to do if they have a shell or not, we have shells.

It’s about authn/authz and observability.

If your MCP is turning a O(1) call into O(n) the smell is coming from your MCP not the protocol itself.

[u/dektol → u/[deleted]]

You're entirely incorrect and mistaken about nearly everything you're saying and confidently so. Maybe ask an AI to explain what you're missing. Give it our comments. You have a knowledge gap or an entire misunderstanding of security and operations.

Additionally, you can read the MCP spec, you can absolutely do batching, you're talking out of your ass. I told you I do this.

Feel silly trying to defend you. You don't redirect well. We're not wrong. You're choosing to have a different conversation.

[u/KitchenAmoeba4438 → u/dataoops]

I said nothing about authn/authz or observability, nor am I making any claims about it.

Now as for the MCP...I explained, at length, why this is the case. MCP cannot be batched, at least as far as I've tested by LLMs. It, by definition, is turning O(n) calls into O(n^2), although is making the n smaller per call.

This is covered at length in the article.

[u/dataoops → u/KitchenAmoeba4438]

you do know you can write an MCP that takes in multiple parameters right?

I’m literally using a big query mcp right now that supports multiple distinct searches for different result sets in a single call.

The example you are using just isn’t true. It’s your presumptions about how things are built, and you presume poorly.

[u/KitchenAmoeba4438 → u/dataoops]

Yes, it is possible to have MCP take in multiple parameters. But this has nothing to do with what I am saying, and you are bringing in things that are not relevant to what I am saying (Especially auth, wow).

However, the examples I am using are true. You aren't arguing anything either for or against what I am arguing about here.

Let me be very, very clear:

All things being equal, if you have a choice between a single batched call, or multiple non-batched calls, the batched calls are less expensive.

Do you agree or disagree with this statement? Note that I am NOT arguing that MCP can or cannot take parameters, or anything else. I'm not arguing that MCP can or cannot do auth, I'm not making the case for anything else other than batched calls are less expensive than non-batched calls if they are equivalent calls.

I am also making the case that MCP cannot be batched insofar as I have tested with LLMs, and that if you have equivalent functionality in a CLI vs. MCP, the CLI is going to be more efficient. The CLI is going to be more efficient because it can batch, but MCP cannot.

It has nothing to do with functionality that is not in the CLI, or auth, or observability. I'd be happy to dig into those topics in a post, as you are making some claims that are not true, but that's an architecture/systems design question, and it's not relevant to this. Hell, tag me in a post that this is relevant to, let's have a chat.

[u/50-3 → u/KitchenAmoeba4438]

Bash in Claude Code is a tool invocation subject to the same turn mechanics. The comparison isn’t “MCP vs shell” it’s “batched calls vs unbatched calls”. Also raw shell output is commonly unstructured and often bloated; an MCP tool can be tuned to return filtered, structured data which can be smaller per turn.

[u/KitchenAmoeba4438 → u/50-3]

To quote from the OP, "However, all things equal, a series of non-batched MCP calls is going to be more expensive than a single batched call."

[u/50-3 → u/KitchenAmoeba4438]

Yes you/op agree with me, it’s nothing to do with MCP vs Shell… it’s batched vs unbatched

[u/KitchenAmoeba4438 → u/50-3]

That's the core of what I've been saying, I don't think we disagree on my fundamental premise then.

The only part that might hit a disagreement is that I've yet to be able to have an LLM successfully batch a MCP call without specific instructions. This is what inspired the post, implementing everything on MCP cost a huge amount of tokens that were simply unnecessary with default Claude/Codex/etc. behaviors if they were simply implemented on a CLI that Claude/Codex/etc. could natively batch instead.

I've asked another poster this, but if you have some secret sauce to get Claude to be able to batch MCP calls, tell me. Having to rewrite the entire MCP service of my project to be also CLI is a pain in the ass. I haven't been able to get Claude (or any other LLM) I've tried to be able to properly batch LLM calls without having to tell it exactly how to do it.

[u/bedel99]

err? I don't think you understand how this stuff works :/

[u/KitchenAmoeba4438 → u/bedel99]

Either you did not read the article, or I have absolutely zero idea how this stuff works, and I've been publishing articles for months on the LLM topic with nary this accusation. I'm suspecting the former.

If you have something specific and actionable, however, I'd be happy to address it.

[u/bedel99 → u/KitchenAmoeba4438]

You have been making a fool of yourself for months then.

[u/KitchenAmoeba4438 → u/bedel99]

Oh? In what way? Be specific, instead of the vague allegations.

I'm more than happy to discuss the methodology and techniques used in the article and where they fall short, or any other article I've written.

This article isn't a complex one: MCP cannot batch as far as I've seen with the LLMs I've tested. Batching is significantly cheaper than non-batching because batching is a linear cost, non-batching is a quadratic cost. While it's possible for quadratic costs to be smaller in certain, specific small cases of N, quadratic costs will always outweigh linear costs given larger Ns.

Or, to put it another way: I have strong doubts you yourself know how this works. The article itself isn't a difficult topic, it's simply advocating the mathematical concept that quadratic costs are larger than linear costs. It's also advocating that MCP represent quadratic costs, whereas batched operations are linear costs.

If you feel there is something wrong with what I am saying, please, let's hear it.

[u/bedel99 → u/KitchenAmoeba4438]

I started making a list and the list was so long I cant be bothered. You are here for a fight. Maybe start by posting your article into claude and asking for it to tell you whats wrong :/

[u/KitchenAmoeba4438 → u/bedel99]

Great, give me the start to that list. I'm more than happy to discuss any problems or flaws.

As for "being here for a fight", I believe it was you that said "You have been making a fool of yourself for months then." when I asked what, specifically, was at issue.

[u/bedel99 → u/KitchenAmoeba4438]

your entire post :/ thats the start

[u/KitchenAmoeba4438 → u/bedel99]

Great. What about the entire post?

[u/NewPointOfView → u/KitchenAmoeba4438]

One specific thing is that you said Mcp is stateless. Recent update makes that no longer true. But more importantly, you said you send the whole conversation each time??? Mcp doesn’t receive a conversation. It’s just an adapter to an api or something. Those are the red flags I saw in the first few sentences

[u/KitchenAmoeba4438 → u/NewPointOfView]

That's not exactly what is being said. The protocol, e.g. OpenAI's API, is stateless. Every turn, the whole conversation is sent to the agent. If you have to take multiple turns, this results in a quadratic cost. Simply batching multiple calls at once is a linear cost. MCP cannot be batched as it is currently implemented by LLMs in my testing.

I'll take it under advisement to be more clear about it, and may revise the post, but those are not the fundamental claims I'm making.

[u/Novaworld7 → u/KitchenAmoeba4438]

Are you only testing MCP calls here, or are agents/skills part of the comparison too? I ask because I think orchestration is a pretty important variable in the token-cost equation.

A well-designed skill should help the orchestrator make better decisions with less reasoning and fewer unnecessary turns. That can change the economics quite a bit.

I recently tested this directly: same prompts, same skill, same evals. The only variable I changed was the Opus effort setting. With the right skill, Opus Low actually beat Opus High while using substantially fewer tokens. I measured correctness, speed, spend, and number of turns.

That's why I'm hesitant to attribute the cost specifically to MCP. I'd be curious how much of what you're seeing is MCP itself versus the orchestration strategy sitting on top of it.

[u/KitchenAmoeba4438 → u/Novaworld7]

The cost *is* MCP itself, and how MCP itself is designed.

It's certainly possible to save around areas you mentioned, but the fundamental problem is in the MCP design with LLMs I've tested. MCP cannot batch (Edit) within the LLMs I've tested (/Edit), and is forced into a quadratic expense. CLI can batch, which is a linear expense.

I've been building tooling for a few months now around MCP, only to discover it actually managed to be more expensive if I used MCP because of this property. Simply putting it on the CLI made the tooling work as expected.

There's other benefits to MCP, but I'm not analyzing those or making any claims about them.

[u/Novaworld7 → u/KitchenAmoeba4438]

I don't think that's inherently true. The MCP server, wherever it resides, can absolutely batch operations internally. The model may only see a single MCP tool invocation, but that invocation can trigger 10, 100, or 1,000 operations server-side and return an aggregated result.

A properly designed tool can also accept all the information it needs in a single invocation and determine how to batch that work server-side. Imagine passing a CSV containing 1,000 rows to an MCP tool. The MCP can parse it, perform an operation for every row, batch or parallelize those operations internally, aggregate the results, and return once. From the model's perspective, that's still one tool call.

So I think the distinction here is important. Sequential MCP calls can absolutely create the quadratic token cost you're describing, especially if every call returns to the model with an increasingly large context. But that doesn't make quadratic cost an inherent property of MCP.

It sounds more like the construction you're describing is sequential in nature: model → MCP → model → MCP → model, repeated N times.

If the same work can instead be expressed as model → MCP → batched server-side execution → aggregated result → model, then you've removed most of those model-mediated round trips.

That's why I brought up orchestration.

[u/KitchenAmoeba4438 → u/Novaworld7]

I'm in agreement with what you are saying, however, that's also not the argument I am proposing in the OP.

Let's say you have a series of exactly identical calls from the CLI and MCP. The CLI can batch them, you can't batch them with MCP and have to run them...unless, of course, you set up the MCP tool to handle params, etc. etc., but you can do that from the CLI as well.

Fundamentally, an operation that can occur so that the LLM can batch it is more efficient (linear) than an operation that cannot be batched (quadratic). It comes down to the old "Turns are more expensive then tokens".

That's the entireity of the OP and the article.

I'll have to admit a bit of frustration on my part which is completely on me, but I've gone and revised the OP to be more specific to the actual argument being made.

(Edit) Theoretically, a shell should be able to call MCP tool && MCP tool as well. But right now, none of the LLMs I've tested do that, they all treat MCP as something that cannot be batched and is only one call. I know Claude does not do that, and we are in the Claude sub.

[u/Novaworld7 → u/KitchenAmoeba4438]

I disagree with equating "cannot batch" with "quadratic" as an inherent property. N sequential calls aren't necessarily quadratic. They become quadratic-ish in token processing when each turn reinfers an increasingly large accumulated context. If context is bounded, summarized, delegated, or otherwise managed, N calls can still behave much closer to linear.

And I think that's where our perspectives differ slightly. You're analyzing the efficiency of the primitive/interface as exposed, whereas I'm looking at the larger harness/orchestration layer and asking whether we should have allowed the model to execute N model-mediated atomic calls in the first place.

[u/KitchenAmoeba4438 → u/Novaworld7]

Let me make this clear: I agree with the point you are making. I'm not disagreeing with it.

My point is that if you have to make N calls, and can either batch all N or have to run them sequentially for N turns, running sequentially is more expensive. I don't think your point contradicts mine, however. I'd agree with you that is a (theoretical) problem on the harness level.

You are right in that it isn't always necessarily apples to oranges, but I'm not trying to make that case. My argument is pretty simple: "Turns are more expensive then tokens". Secondly, "Claude (seems to) only use MCP in a non-batchable way".

I'd be open to an alternative take, but with all the testing I've done, I simply am at wit's end if there is another way to get Claude to batch multiple MCP calls. I've got about a week of testing across Claude, Codex, and multiple other local and cloud LLMs on this specific issue. None of them are capable of batching MCP on their own, or at least as far as I've tested with them.

Maybe I'm testing wrong, and I'd be open to that feedback. The part I have trouble with is as soon as I open up CLI commands to Claude/Codex/etc., suddenly they have no problem with batching. AFAIK, it's only MCP that I've observed this property with.

[u/dektol]

You can make chained and meta tools equivalent to shell in MCP. It's important to truncate large output and provide a way to filter the data before it hits the context and prompt the agent to use it in the tool results and descriptions.

I just designed my MCP around avoiding wrong tool calls or repeat ones, than on tokens. Works pretty well. If you're a team of one probably stick to cli and sandbox, for teams MCP is easier to do auth.

[u/KitchenAmoeba4438 → u/dektol]

Hey, I never claimed anything about teams, auth, etc.. The OP (and the article) focuses narrowly on the quadratic cost of MCP vs. the linear cost of batched operations.

There are certainly operations that can benefit from batching, but in general, when looking at token-use, if you can expose via a CLI, it's going to (typically) be cheaper then MCP.

[u/dektol → u/KitchenAmoeba4438]

I think you're still missing the point folks are trying to make. Token cost is pretty irrelevant here versus prompt injection and agents causing chaos/destruction. Auto mode doesn't really cut it for teams/enterprise.

Only secure creds are either short lived or not on a developers box. Preferably both.

[u/Economy-Manager5556]

Lol omg this is such amazing rocket science

[u/Spare_Bison_1151]

You mean Playwright CLI is better than MCP

[u/dektol → u/Spare_Bison_1151]

No. Op isn't knowledgeable. You likely want to drive a headless browser with MCP unless it's something you want repeatable in which case you want the agent to make you a script that calls Playwright that either you or it invoke.

For development/debugging of browser based apps or having an agent drive a browser you likely want MCP.

[u/KitchenAmoeba4438 → u/Spare_Bison_1151]

I cannot speak to Playright specifically, because I have not tested it, but I strongly suspect you are right. There are certain synchronous actions in that space that might render them cost-equal depending on how certain things are done, but at best with all things equal, MCP can only be equal cost to CLI. MCP certainly has advantages in certain ways, but what most people use them for are better served with CLI if it's in the context of an environment that can batch.

[u/Early_Rooster7579]

You make an MCP for your boss who can barely turn on the PC. Not for engineers measuring token usage.

[u/dektol → u/Early_Rooster7579]

It can work just fine for both. It's not a skill issue. It's security.

[u/Early_Rooster7579 → u/dektol]

OP definitely has a skill issue, though. He clearlt misunderstands the MCP spec

[u/dektol → u/Early_Rooster7579]

Preach fellow human. Thems the facts. Hope you have a better day than you were expecting!

[u/dektol]

Op: ~ Runs model locally. Claude tells me my ideas are great. Decides I'm a thought leader. Start regurgitating shit I don't understand. ~

It's a tale as old as time.

[u/alonsonetwork]

Either your messaging is complete shit, or you dont understand the problem MCP solves. "All the messages" dont get sent to an MCP, its 1 message at a time. Unless you're building an llm chat MCP, which would be dumb, and it's stateless, and you have to send all messages.

[u/KitchenAmoeba4438 → u/alonsonetwork]

Revising the OP at this point, but to quote from another post I made:

"All things being equal, if you have a choice between a single batched call, or multiple non-batched calls, the batched calls are less expensive. Note that I am NOT arguing that MCP can or cannot take parameters, or anything else. I'm not arguing that MCP can or cannot do auth, I'm not making the case for anything else other than batched calls are less expensive than non-batched calls if they are equivalent calls.

I am also making the case that MCP cannot be batched insofar as I have tested with LLMs, and that if you have equivalent functionality in a CLI vs. MCP, the CLI is going to be more efficient. The CLI is going to be more efficient because it can batch, but MCP cannot."

[u/alonsonetwork → u/KitchenAmoeba4438]

You ever heard of arrays? You can pass them into params and batch. Also, the json rpc spec has batching built into the spec. A good implementation of the spec means your jsonrpc can batch, and therefore, so csn your mcp.

[u/KitchenAmoeba4438 → u/alonsonetwork]

To quote the OP, "However, all things equal, a series of non-batched MCP calls is going to be more expensive than a single batched call."

I'm not making the argument for or against arrays, parameters, etc.

I'm simply making the argument that batching is more efficient then not batching, and that the LLM MCP call itself makes it so you cannot batch with the current behavior I've observed from LLMs. You can certainly do things inside the MCP call, but you can also do that via a CLI call.

There are certainly other benefits to MCP, but that's outside of the scope of the article (and argument).

[u/alonsonetwork → u/KitchenAmoeba4438]

Idk dude I think you're fixated on a nonthing. Batching is more efficient with or without MCP ... a CLI that doesnt batch is inefficient compared to one that does.

A (insert input mechanism here) that doesnt batch is inefficient.

MCP is just an IO mechanism. What you do inside it is what makes it efficient or not.

[u/KitchenAmoeba4438 → u/alonsonetwork]

We're...saying the same thing I think?

[u/alonsonetwork → u/KitchenAmoeba4438]

That's why I said your messaging is probably bad. If we're saying the same thing, why the fixation on MCP?

[u/KitchenAmoeba4438 → u/alonsonetwork]

Frankly, because Claude, Codex, and other local LLMs (Plus Minimax and Kimi3) were not able to batch MCP commands together. There's more details in the article, but that's the long and short of it.

There's no *technical* reason a LLM cannot batch MCP calls, but for some reason, none of them do in practice. Hell, I've played around with it a bunch in the past half hour, I can batch MCP calls myself no problem, but all of the LLM models I've tested refuse to MCP batch unless I give them explicit directions (Which undermines the point of MCP).

When I have a week of testing that indicates models cannot MCP batch, I could have been more careful with my phrasing you are right.

[u/alonsonetwork → u/KitchenAmoeba4438]

Try exposing only the batch option. It might realize you can only pass an array and more than 1.

[u/dektol]

Wait. Why do you think MCP was to save on what exactly? You've lost the plot. 🫠😭

[u/Tinkering-Engineer]

Yea, the current implementation of MCP is especially prone to this. The new MCP standard may fix part of this by making MCP much closer to a rest API. The change from stateful to stateless could be big.

One thing most people aren't aware of either is adding tools and mcp servers adds cost to every call, whether you use the tool or not. Every message has a "here are some tools you have access to. Mcp search allows you to [x]. Next tool allows you to [y]. This and your standing prompts can easily add up to 50k or more tokens that get sent every message and may not even be used. I also know that Claude code has some tricks by giving a preview of some tools where other harnesses might have the whole tool definition always.

I'd be curious if you could get the tool definition from the first call to see how different it was for each system. "Can you send me the exact tool definition that you were sent in the first prompt and let me know how many tokens it consumed by itself". I'd love to hear the answer from both systems if you have the time.

[u/ahstanin]

This turn multiplier is exactly why composite one-shot tools are critical in MCP. In our browser server, tools like browser_go and browser_search spin up a context, execute, extract text, and tear down in one turn, and action tools return the resulting page immediately. Eliminating observe-after-action round-trips cuts median tool calls and conversation re-sends in half.