MCP is eating the world

> And the moment we, as an industry, settle on something sane, I will rip out the whole thing and adopt that, because MCP brings _nothing_ to the table that I could not do with a "proper" API using completely standard tooling.

100%. I suppose I understand MCP for user-side tooling but people seem to be reinventing the wheel because they don't understand REST. making REST requests with a well defined schema from an LLM is not all that hard.

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.

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.

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.

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

Yep, we've built some really useful agents with some simple tools (3-5 templated snowflake queries with really good descriptions). The LLM is useful for shaping your question into function params and then interpreting the results based on the context it got from the tool description.

How many tools does your agent have access to?

At Stainless we use https://github.com/dgellow/mcp-front to make it easy for anyone on the team (including non-technical folks) to OAuth into a pretty wide variety of tools for their AI chats, using their creds. All proxied on infra we control.

Even our read replica postgres DB is available, just push a button.

IIRC they talk about it here

https://www.youtube.com/watch?v=m2VqaNKstGc&ab_channel=Laten...

TL;DR If you want to engage with the MCP protocol you can do so here. https://github.com/modelcontextprotocol

It never fails that if you look at their title it's: VP of XYZ at something.ai as well!

It's basically the story of the last 3 years. Can't ignore the technology, but every loser grifter in existence has been on AI full time. On average, the more they are fanatics of it, the less they're able to take advantage of what it actually can do, most often due to an inordinate amount of skill issues unrelated to AI.

All influencer content is groan-inducing, but the idea behind MCP is pretty huge: it's the ability to link LLM agent loops into basically arbitrary APIs. It would be weird if it wasn't attracting a lot of attention.

A "whole Docker container" is not very heavyweight. Other than having their own filesystem view and separate shared libraries, container processes are nearly as light as non-container processes. It's not like running a VM.

I don’t think running these commands in a docker container is the standard way of doing this, I’ve seen “npx” et al being used way more often.

Furthermore, the “docker” part wouldn’t even be the most resource wasteful if you consider the general computational costs of LLMs.

The selling point of MCP servers is that they are composable and plug in into any AI agent. A monolith doesn’t achieve that, unless I’m misunderstanding things.

What I find annoying is that it’s very unpredictable when exactly an LLM will actually invoke an MCP tool function. Different LLM providers’ models behave differently, and even within the same provider different models behave differently.

Eg it’s surprisingly difficult to get an AI agent to actually use a language server to retrieve relevant information about source code, and it’s even more difficult to figure out a prompt for all language server functions that works reliably across all models.

And I guess that’s because of the fuzzy nature of it all.

I’m waiting to see how this all matures, I have the highest expectations of Anthropic with this. OpenAI seems to be doing their own thing (although ChatGPT supposedly will come with MCP support soon). Google’s models appear to be the most eager to actually invoke MCP functions, but they invoke them way too much, in turn causing a lot of context to get wasted / token noise.

Remote MCPs should resolve some of this

Agree, but I think we should hold those Apps to a higher bar. Chat interfaces are not a replacement for good UX.

I don't think that the goal of MCP is for software developers.

MCP is great for: "I would like Claude Desktop/VSCode/Cursor to know about my JIRA tickets". AFAIK Most of the tools that are being used for AI Coding tools are not delivered through MCP.

WOW talk about quoting out of context.

Do you get mad at IDE plugins that let you extend software that you don't control?

Well you see I run dozens of agents at once so my hours of experience accumulate at 10-100x real time. I've got about 200 years of experience in MCP. I accumulated another 3 years of experience while typing this

Not a problem for the 15x programmer.

>> >> Heck, even MCP itself isn’t new—the spec was released by Anthropic in November

woosh!

You need 10+ for senior though.

1 year for a human is like 10 in AI-years.

I think you're joking but if not I'd love to see one!

Taking this question at face value, because you asked: Stainless generates MCP servers for REST APIs (a ~simple[0] translation of an OpenAPI to a suite of MCP tools).

We actually generate MCP for free (we charge for SDKs), so we're technically not selling, but I don't begrudge GP's comment/sentiment.

[0]https://www.stainless.com/blog/what-we-learned-converting-co... describes some ways in which this is less simple than you think. The "Handling large APIs dynamically" section near the bottom covers the most salient challenge related to converting large APIs to MCP tools, but there's more work to do.

It's clearly a plot by Big MCP to sell us more MCP. /s

I think "if you're not doing anything wrong you have nothing to hide" doesn't apply to B2B services.