- My own "execute bash command" tool, adding output pagination, forcing the agent to choose a working directory, and working around some Cursor bugs on Windows. This avoids context explosion when a command unexpectedly returns a huge amount of text, and avoids a common agent failure mode where it misunderstands what directory it is currently in.
- SQL command execution. This can be done perfectly fine with "execute bash command" but the agent struggles to correctly encode multi-line SQL queries on the command line. You can force it to write a file, but then that's two MCP tool calls (write file, execute command) which increases the chances that it goofs it up. I simply accept an unencoded, multi-line SQL query directly via the MCP tool and encode it myself. This, again, is simply avoiding a common failure mode in the built-in tools.
I haven't needed a third tool, and if the built-in tools were better I wouldn't have needed these two, either. Everything else I've ever needed has been a bash script that both the agent and I can run, explained in the agent's global rules. It's really unclear to me what other use case I might encounter that would be better as MCP.
In theory I can see that an MCP server only launches once and is persistent across many requests, whereas bash scripts are one-and-done. Perhaps some use case requires a lot of up-front loading that would need to be redone for every tool call if it were a bash script. Or perhaps there are complex interactions across multiple tool calls where state must be kept in memory and writing to disk is not an option. But I have not yet encountered anything like this.
Context7, I assume? I wanted to like context7 but I constantly need documentation that is either private or not in a format that context7 supports. Instead, I scrape the docs to Markdown, stick them into a "context" folder[1], and use Cursor's vector codebase indexing. This allows the agent to literally ask questions like "how do I do ABC with library XYZ?" and the vector database delivers a chunked answer from all available documentation. This is, IMO, much better than how context7 works: context7 just returns whole pages of documentation, polluting the context window with info that isn't relevant to what the agent wanted to know.
I have done this with entire textbooks. Find a PDF and get GPT-5 to transcribe it page by page to Markdown. Costs a couple bucks and turns the agent into a wizard on that subject.
Context7, too, could easily have been a command line tool that both you and the agent can use. Even now, I don't see what MCP--specifically--brings to the table.
[1] One trick for Cursor users: put "/context/" in .gitignore and "!/context/" in .cursorignore. This will keep it out of git but still index it.
It's at https://github.com/brianluft/arcadia and the actual MCP server is at https://github.com/brianluft/arcadia/tree/main/server/src. If not suitable as-is, you can probably get Claude to repackage or tweak the code for your needs. The project has a .NET component for the SQL tool that isn't used at all for bash execution; only the Node.js server is needed for the bash tool.
Remember that things a "ceo" of anything says is just what he hears from people he has talked to. Now it doesn't make it obviously wrong, it's just then begs the question who he has been talking to that week. I doubt gary is doing any of the coding these days. For what it's worth, it's completely fine to ignore what he is saying - no offense.
Except he's right in this case, and it is contrary to the hypemongering we'd expect
It's 100% accurate to say that "MCP barely works" and it's meaningful to hear that even from the head of YC which is pushing through massive amount of businesses based on MCP or using it some way
It's two words with no qualifiers from someone we don't think it's technical. If it was, say, Karpathy, then sure, let's waste a whole thread discussing his farts, but I'm sure I'm not alone in having Claude Code having created an MCP, and I use it most times I use Claude Code. To move the conversation forwards though, what limitations and issues have you run into with MCPs? I wouldn't say mine are 100% bug free, but I wouldn't say it "barely works" either. Mostly works?
I see MCP as fundamentally limited: even if we had an LLM that knew how to use it perfectly, at the end of the day MCP workflows are integrations between many different APIs that were not designed to be composed and to work together.
What if $TOOL_X needs $DATA to be called, but $TOOL_Y only returns $DATA_SUBSET? What happens when $TOOL_Z fails mid-workflow, after $TOOL_W has already executed?
> What if $TOOL_X needs $DATA to be called, but $TOOL_Y only returns $DATA_SUBSET? What happens when $TOOL_Z fails mid-workflow, after $TOOL_W has already executed?
Aren’t these situations current models are quite good at?
No but mainly because passing actual data through the context is janky and expensive. So it's only useful as a one of at most.
This whole idea of doing unsupervised and unstructured work with unstructured data at scale with some sort of army of agents or something sounds ridiculous to me anyway. No amount of MCP or prompting or whatever is going to solve it.
Like if interesting problems are on the boundry of obvious and chaotic this is just like some janky thing that's way too far into the chaotic regime. You won't go anywhere unless you magically solve the value function problem here.
If TOOL_X needs $DATA and that data is not available in context, nor from other tools, then the LLM will determine that it cannot use or invoke TOOL_X. It won't try.
About the TOOL_Z and TOOL_W scenario. It sounds like you're asking about the concept of a distributed unit-of-work which is not considered by MCP.
> If TOOL_X needs $DATA and that data is not available in context, nor from other tools, then the LLM will determine that it cannot use or invoke TOOL_X. It won't try.
I didn't explain myself very well, sorry. What I had in mind is: MCP is about putting together workflows using tools from different, independent sources. But since the various tools are not designed to be composed, scenarios occur in which in theory you could string together $TOOL_Y and $TOOL_X, but $TOOL_Y only exposes $DATA_SUBSET (because it doesn't know about $TOOL_X), while $TOOL_X needs $DATA. So the capability would be there if only the tools were designed to be composed.
Of course, that's also the very strength of MCP: it allows you to compose independent tools that were not designed to be composed. So it's a powerful approach, but inherently limited.
> About the TOOL_Z and TOOL_W scenario. It sounds like you're asking about the concept of a distributed unit-of-work which is not considered by MCP.
Yes, distributed transactions / sagas / etc. Which are basically impossible to do with "random" APIs not designed for them.
I use MCP for two things only:
- My own "execute bash command" tool, adding output pagination, forcing the agent to choose a working directory, and working around some Cursor bugs on Windows. This avoids context explosion when a command unexpectedly returns a huge amount of text, and avoids a common agent failure mode where it misunderstands what directory it is currently in.
- SQL command execution. This can be done perfectly fine with "execute bash command" but the agent struggles to correctly encode multi-line SQL queries on the command line. You can force it to write a file, but then that's two MCP tool calls (write file, execute command) which increases the chances that it goofs it up. I simply accept an unencoded, multi-line SQL query directly via the MCP tool and encode it myself. This, again, is simply avoiding a common failure mode in the built-in tools.
I haven't needed a third tool, and if the built-in tools were better I wouldn't have needed these two, either. Everything else I've ever needed has been a bash script that both the agent and I can run, explained in the agent's global rules. It's really unclear to me what other use case I might encounter that would be better as MCP.
In theory I can see that an MCP server only launches once and is persistent across many requests, whereas bash scripts are one-and-done. Perhaps some use case requires a lot of up-front loading that would need to be redone for every tool call if it were a bash script. Or perhaps there are complex interactions across multiple tool calls where state must be kept in memory and writing to disk is not an option. But I have not yet encountered anything like this.
My most common use case for MCP servers is to wire the documentation for whatever I’m working on into the Context.
Context7, I assume? I wanted to like context7 but I constantly need documentation that is either private or not in a format that context7 supports. Instead, I scrape the docs to Markdown, stick them into a "context" folder[1], and use Cursor's vector codebase indexing. This allows the agent to literally ask questions like "how do I do ABC with library XYZ?" and the vector database delivers a chunked answer from all available documentation. This is, IMO, much better than how context7 works: context7 just returns whole pages of documentation, polluting the context window with info that isn't relevant to what the agent wanted to know.
I have done this with entire textbooks. Find a PDF and get GPT-5 to transcribe it page by page to Markdown. Costs a couple bucks and turns the agent into a wizard on that subject.
Context7, too, could easily have been a command line tool that both you and the agent can use. Even now, I don't see what MCP--specifically--brings to the table.
[1] One trick for Cursor users: put "/context/" in .gitignore and "!/context/" in .cursorignore. This will keep it out of git but still index it.
Is your execute bash command tool open source? It sounds like it solves two of my biggest frustrations with Claude code (especially with work trees).
It's at https://github.com/brianluft/arcadia and the actual MCP server is at https://github.com/brianluft/arcadia/tree/main/server/src. If not suitable as-is, you can probably get Claude to repackage or tweak the code for your needs. The project has a .NET component for the SQL tool that isn't used at all for bash execution; only the Node.js server is needed for the bash tool.
The s/ link in the post is a tracking link that requires Reddit login (please avoid those). Its destination can be viewed directly at https://old.reddit.com/r/mcp/comments/1paggqd/garry_tan_says...
Remember that things a "ceo" of anything says is just what he hears from people he has talked to. Now it doesn't make it obviously wrong, it's just then begs the question who he has been talking to that week. I doubt gary is doing any of the coding these days. For what it's worth, it's completely fine to ignore what he is saying - no offense.
Except he's right in this case, and it is contrary to the hypemongering we'd expect
It's 100% accurate to say that "MCP barely works" and it's meaningful to hear that even from the head of YC which is pushing through massive amount of businesses based on MCP or using it some way
It's two words with no qualifiers from someone we don't think it's technical. If it was, say, Karpathy, then sure, let's waste a whole thread discussing his farts, but I'm sure I'm not alone in having Claude Code having created an MCP, and I use it most times I use Claude Code. To move the conversation forwards though, what limitations and issues have you run into with MCPs? I wouldn't say mine are 100% bug free, but I wouldn't say it "barely works" either. Mostly works?
I see MCP as fundamentally limited: even if we had an LLM that knew how to use it perfectly, at the end of the day MCP workflows are integrations between many different APIs that were not designed to be composed and to work together.
What if $TOOL_X needs $DATA to be called, but $TOOL_Y only returns $DATA_SUBSET? What happens when $TOOL_Z fails mid-workflow, after $TOOL_W has already executed?
> What if $TOOL_X needs $DATA to be called, but $TOOL_Y only returns $DATA_SUBSET? What happens when $TOOL_Z fails mid-workflow, after $TOOL_W has already executed?
Aren’t these situations current models are quite good at?
No but mainly because passing actual data through the context is janky and expensive. So it's only useful as a one of at most.
This whole idea of doing unsupervised and unstructured work with unstructured data at scale with some sort of army of agents or something sounds ridiculous to me anyway. No amount of MCP or prompting or whatever is going to solve it.
Like if interesting problems are on the boundry of obvious and chaotic this is just like some janky thing that's way too far into the chaotic regime. You won't go anywhere unless you magically solve the value function problem here.
If TOOL_X needs $DATA and that data is not available in context, nor from other tools, then the LLM will determine that it cannot use or invoke TOOL_X. It won't try.
About the TOOL_Z and TOOL_W scenario. It sounds like you're asking about the concept of a distributed unit-of-work which is not considered by MCP.
> If TOOL_X needs $DATA and that data is not available in context, nor from other tools, then the LLM will determine that it cannot use or invoke TOOL_X. It won't try.
I didn't explain myself very well, sorry. What I had in mind is: MCP is about putting together workflows using tools from different, independent sources. But since the various tools are not designed to be composed, scenarios occur in which in theory you could string together $TOOL_Y and $TOOL_X, but $TOOL_Y only exposes $DATA_SUBSET (because it doesn't know about $TOOL_X), while $TOOL_X needs $DATA. So the capability would be there if only the tools were designed to be composed.
Of course, that's also the very strength of MCP: it allows you to compose independent tools that were not designed to be composed. So it's a powerful approach, but inherently limited.
> About the TOOL_Z and TOOL_W scenario. It sounds like you're asking about the concept of a distributed unit-of-work which is not considered by MCP.
Yes, distributed transactions / sagas / etc. Which are basically impossible to do with "random" APIs not designed for them.
MCP was generally a badly designed standard.
[dead]
[dead]