Write a CLI tool that does the same thing (including external service access) and tell any agentic CLI tool (or Cursor or IDE tool) to use the tool. Much simpler, established security models, etc.
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.
It's weird you're saying it's not MCP, when this is precisely what I've done to write several MCP servers.
You write a function. Wrap it with a decorator, and add another line in __main__, and voila, it's an MCP server.
> now each MCP tool requires its own server with all the complications that come with it, including runtime overhead, security model fragmentation, incompatibility…
You can lump multiple tools in a server. Personally, it makes sense to organize them by functionality, though.
> including runtime overhead, security model fragmentation, incompatibility…
What incompatibility?
Runtime overhead is minimal.
Security - as I said, if you write your own tools, you control it just as you would with the old tool use. Beyond that, yes - you're dependent on the wrapper library's vulnerabilities, as well as the MCP client. Yes, we've introduced one new layer (the wrapper library), but seriously, it's like saying "Oh, you introduced Flask into our flow, that's a security concern!" Eventually, the libraries will be vetted and we'll know which are secure and which aren't.
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.
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.
tool --help
man toolThat 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.
MCP is for AI agents, the CLI is for one-off commands by devs who like to poke at things or CI scripts, the TypeScript SDK is for production software written in TypeScript, etc etc.
Was there something we're missing from the "data platform"? A SQL interface?
(I work with yjp20)
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.)
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.
That might prevent the model from wandering from the beaten paths, but container escapes are a thing, so if it's not lost but instead malicious then that might not do it. Luckily I don't think we're quite there yet.
So I think that's a "no".
QubesOS might work well for this. It's all about making it easy to work with a small pile of VMs under the assumption that at least one is probably compromised and keeping that one compartmentalized. Although I don't know how far that'll get you if you're letting the untrusted thing call the shots.
At the end of the day you're always going to be able to build better handcuffs by starting with nothing and gradually adding API calls that it needs. Starting with CLI access and then adding restrictions is never going to be as secure, even though it's way more convenient.
That said, I think you could strike a pretty reasonable balance by just not giving it access to anything but one or two explicitly chosen directories.