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
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?
- 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.
10 comments
[ 3.9 ms ] story [ 31.3 ms ] threadIt'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
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?
- 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.