MCP was created so llm companies can have a plugin system. So instead of them being the API provider, they can become the platform that we build apps/plugins for, and they become the user interface to end consumers.

Will have a think about how this can extended to other types of uses.

I have personally been trying to replace all tools/MCPs with a single “write code” tool which is a bit harder to get to work reliably in large projects.

They are great if you have a UI that you want and it needs a plugin system, obviously.

But the benefits become much more marginal for a developer of enterprise AI systems with predefined tool selections. They are actually getting overused in this space, if anything, sometimes with security as a primary casualty.

You need Claude Skills.

Well, stdio security issues when not sandboxed are another huge miss, although that's a bit of a derail.

You guys should just see https://rtcode.io Agent Folder Share feature!

Browser → FS → AI CLI = perfection with nothing but files!

If there was some certainty MCP could add to this equation that would perhaps be theoretically nice, but otherwise it's just .. parsing, a perhaps not "solved" problem, but one for which there's already ample solutions.

"What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!"

LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.

Not only do you not need MCP, but you should actively avoid using it.

Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.

MCP shines when you want to add external functionality to an agent quickly, and in situations where it's not practical to let an agent go wild with code execution and network access.

Feels like we're in the "backlash to the early hype" part of the hype cycle. MCP is one way to give agents access to tools; it's OK that it doesn't work for every possible use case.

This occurred with langchain and now seems to be occurring with mcp. Neither of those really solved the actual problems that are difficult with deploying AI - creativity, context, manual testing, tool design etc. The owners of these frameworks are incentivized to drag people into them to attain some sort of vendor lock-in.

At my company we started building our tool based data scientist agent before MCP came out and it's working great.

https://www.truestate.io/

Can I “just call the API”? Yeah, but that takes extra work, and my goal is to reduce extra work.

Overwhelmed by Sentry errors recently I remembered sentry-cli. I asked the agent to use it to query for unresolved Sentry errors and make a plan that addresses all of them at once. Zeroed out my Sentry inbox in one Claude Code plan. All up it took about an hour.

The agent was capable of sussing out sentry-cli, even running it with --help to understand how to use it.

The same goes for gh, the github cli tool.

So rather than MCPs or function style tools, I highly recommend building custom cli tools (ie. shell scripts), and adding a 10-20 word description of each one in your initial prompt. Add --help capabilities for your agent to use if it gets confused or curious.