←back to thread

MCP is eating the world

(www.stainless.com)
335 points emschwartz | 1 comments | | HN request time: 0s | source
Show context
faxmeyourcode ◴[] No.44368295[source]
Based on the comments here, a lot of folks are assuming the primary users of mcp are the end users connecting their claude/vscode/etc to whatever saas platform they're working on. While this _is_ a huge benefit and super cool to use, imo the main benefit is for things like giving complex tool access to centralized agents. Where the mcp servers allow you to build agents that have the tools to do a sort of "custom deep research."

We have deployed this internally at work where business users are giving it a list of 20 jira tickets and asking it to summarize or classify them based on some fuzzy contextual reasoning found in the description/comments. It will happly run 50+ tool calls poking around in Jira/confluence and respond in a few seconds what would have taken them hours to do manually. The fact that it uses mcp under the hood is completely irrelevant but it makes our job as builders much much easier.

replies(7): >>44368648 #>>44368903 #>>44368929 #>>44368954 #>>44369304 #>>44374580 #>>44375982 #
dkdcio ◴[] No.44368903[source]
Where I struggle conceptually is this works fine without MCP.

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.

replies(9): >>44369240 #>>44369266 #>>44369268 #>>44369270 #>>44369365 #>>44369912 #>>44371239 #>>44371639 #>>44372125 #
yjp20 ◴[] No.44369240[source]
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.

replies(2): >>44369381 #>>44371943 #
rcarmo ◴[] No.44369381[source]
What you are actually saying is that you don't have a data platform with reporting and prefer using your own product because you designed your user tier to have an MCP server, which is kind of an ourobouros.
replies(1): >>44369480 #
1. rattray ◴[] No.44369480[source]
Hmm? We have a REST API, CLI, MCP server, and SDKs that all offer the same data/functionality.

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)