You're thinking like a SW engineer. Instead, think like someone who just happens to know a bit of programming. MCP is much, much easier than tool calling, I think.

As an example, I wrote a function in Python that, given a query string, executes a command line tool and returns the output. To make it an MCP server, I simply added type annotations to the function definition, and wrote a nice docstring, and added a decorator.

That's it. And now it works with all providers and all tools that support MCP. No REST APIs, etc needed. Not tied to a particular agentic tool.

Every time I've written a tool, I've ended up with "Wow, was it really that simple?"

As for security: If you write your own tool, the security implications are the same.

Sure, and MCP is just a standardized way of exposing tools. This is where I feel MCP is both overhyped (waaaaaaay too much LinkedIn influencer hot air) but also genuinely quite useful.

I've done stuff very much like the above with just regular tool calls through the various LLM APIs, but there are tons of disparate frameworks for how to harness up a tool, how they execute, how they are discovered, etc. None of it is rocket science.

But the nice thing about having a standard is that it's a well-lit path, but more importantly in the corporate workflow context is that it allows tools to be composed together really easily - often without any coding at all.

An analyst who has zero coding experience can type in a prompt, click "add" on some MCP tools, and stand up a whole workflow in a minute or two.

That's pretty cool.

And yeah, none of it is impossible to implement yourself (nor even very hard!) but standardization has a value in and of itself in terms of lowering barriers to entry.

This is pretty fair: in claude code, I have the github mcp server installed, but the agent actually prefers to use the CLI. There's also other advantages too, such as incremental discovery of subcommands for more complex CLIs. Certainly agents already don't have a problem using CLIs.

That said, this doesn't fully work in environments on websites like claude.ai. Perhaps you could have an org-wide Dockerfile or something that opens every time you start a chat which gives it MCP-like capabilities, but that sounds more complicated in many ways than what MCP does. There's also more problems that MCP solves, like with Prompts and Sampling (which are pretty under-used at the moment), and there aren't great analogs for that in the CLI world.

Also developers like you and I might find it trivial to install CLIs, set up auth, and open an agent locally, but this isn't widely true. As an example, at Stainless we have non-engineer folks who ask questions like "who are the most interesting people who have signed up yesterday", and with the right MCP tools wired to claude.ai, claude actually does an excellent job of answer these kinds of questions, all in the browser. This was all without a doubt possible before MCP, but MCP reduces the friction enough, such that it becomes worth-it/easy-enough to develop these tools.

Yes, MCP adds no new fundamental capabilities. What it does is solve an N x M problem, where to hook up a given tool to a given LLM scaffold you have to write specific integration code for that combination of scaffold and tool.

With MCP that's decoupled, the tool and the software speak a common protocol, and it's one line of configuration to hook the tool up to the LLM. Makes it easy to mix and match, reuse code, etc.

Yeah, CLIs actually often do seem better for agents with access to bash, like Claude Code.

That said, many "business users" like those referenced above interact more with a web UI, and asking them to audit bash/CLI interactions might not always work well.

(disclaimer: I work at Stainless; we're actually exploring ways to make MCP servers more "CLI-like" for API use-cases.)

If the CLI tool does IO with the agentic CLI tool of choice over STDIO, then it's MCP by definition, with the only caveat being that it runs locally on each user's machine instead of a server. For dev-teams, CLI would work but for non-coders, web-apps or Slack-channel with LLM/MCP integration would be better.

I'll take a CLI over http ten times out of ten. However, I'm skeptical that that's the ideal long term interface because it gives the model too much freedom.

I want to be the one deciding which CWD to use, which user to run as, whether to see the whole filesystem or to restrict to a chroot, etc.

So far it hasn't been malicious but I've had a number of cases while using cursor where the model has gotten confused and is now editing repos outside the open workspace.

Maybe the answer is still a CLI, but I want a standardized interface for equipping that CLI with handcuffs.

The problem with that is it doesn’t work for people who are not technical. Remote mcp is pretty good even if I would have preferred a rest api helper endpoint to support existing apis

MCP is JDBC for LLM