What if you don't need MCP at all?

If I may make a suggestion, many problems folks face with MCP would be solved if their agents were JIT compiled, not ran in a static while loop.

We've been developing this in case folks are interested: https://github.com/stanford-mast/a1

What I've started experimenting with and will continue to explore is to have project-specific MCP tools.

I add MCP tools to tighten the feedback loop. I want my Agent to be able to act autonomously but with a tight set of capabilities that don't often align with off-the-shelf tools. I don't want to YOLO but I also don't want to babysit it for non-value-added, risk-free prompts.

So, when I'm developing in go, I create `cmd/mcp` and configure a `go run ./cmd/mcp` MCP server for the Agent.

It helps that I'm quite invested in MCP and built github.com/ggoodman/mcp-server-go, which is one of the few (only?) MCP SDKs that let you scale horizontally over https while still supporting advanced features like elicitation and sampling. But for local tools, I can use the familiar and ergonomic stdio driver and have my Agent pump out the tools for me.

MCP sounds like the modern equivalent of COM, where you could query an object to see what functions it exposed but had zero idea of what they did. MCP is the same: apparently it is LLM-readable, but the explanations of what everything does are human readable, and there is no standard on operations available.

select * from protocols # ipc, tcp, http, websockets, ...?

MCP and A2A are JSONRPC schemas people follow to build abstraction around their tools. Agents can use MCP to discover tools, invoke and more. OpenAPI Schemas are good alternatives to MCP servers today. In comparison to OpenAPI Schemas, MCP servers are pretty new.

my fav protocol is TCP, which I am a proud user of nc localhost 9999.

but not everyone have same taste of building software.

https://github.com/cagataycali/devduck

You hit it! I am also thinking of programatic control of DevTools so I made this: https://github.com/devtoolcss/chrome-inspector

Though it is more about debugging CSS, I think we are on the same way: let agents use tool by scripting.

Instead of tools for humans, and a separate set of tools for machines, we should just make tools for humans+machines.

The agent should look at my README.md, not a custom human-like text that is meant to be read by machines only.

It also should look at `Makefile`, my bash aliases and so on, and just use that.

In fact, many agents are quite good at this (Code Fast 1, Sonnet).

Issue is, we have a LONG debt around those. READMEs often suck, and build files often suck. We just need to make them better.

I see agents as an opportunity for making friendlier repos. The agent is a free usability tester in some sense. If it can't figure out by reading the human docs, then either the agent is not good enough or your docs aren't good enough.

> Each tool is a simple Node.js script that uses Puppeteer Core. By reading that README, the agent knows the available tools, when to use them, and how to use them via Bash.

> When I start a session where the agent needs to interact with a browser, I just tell it to read that file in full and that's all it needs to be effective. Let's walk through their implementations to see how little code this actually is.

Cool, now you want to package that so others can use it? What next?

Put it behind an MCP is an easy approach. Then I can just install that MCP and by choosing it I have all the capabilities mentioned here.

Or in this particular case, a Claude Skill could likely do as well.

But I mean, that's MCP. I don't even really understand the people discussing that MCP is bad or whatever, it's a plug and play protocol so I can package tools for others to use in their preferred agent client.

CLI access also has the issue that if you want to integrate it in an application, well how do you bundle bash in a secure way so your agent can use it? And would you allow users custom tool call, now they can run arbitrary bash commands?

I still think it's better to have MCP, after all, it's unrealistic for any company to integrate all functions into one

GraphQL works better https://chatbotkit.com/reflections/why-graphql-beats-mcp-for...

The scripts+README approach works well for individuals, but it doesn’t address what MCP is actually for. MCP matters when you’re packaging tools for other users, because it handles automatic tool discovery so people don’t need to load anything. It also provides a server boundary that keeps credentials and remote operations isolated from the model—and enforces scope so only specific capabilities are exposed.

MCP has been a weird ride. I built https://terminalwire.com before MCO was a thing to make it way easier for people to add a CLI/TUI to their web apps/SaaS.

Then MCP comes out and AI explodes, sucking all the air out of the room for non AI tools.

Now it seems like AI can work with CLIs better than MCP, so I’m tempted to slap AI integration all over the project to better convey the idea.

It’s crazy how quickly MCP has run it’s course and watching an entire ecosystem rediscover things from first principals.

So basically rewrite MCP tools with your own scripts.

MCP is just an API with docs.

The problem isn’t MCP itself. It’s that each MCP “server” has to expose every tool and docs which consumes context.

I think the tools should use progressive reveal and only give a short summary like the skill does. Then agent can get full API of the tool on request.

Right now loading GitHub MCP takes something like 50k tokens.