←back to thread

MCP is eating the world

(www.stainless.com)
335 points emschwartz | 3 comments | 21 Jun 25 16:30 UTC | HN request time: 0.801s | source
Show context
faxmeyourcode ◴[24 Jun 25 16:58 UTC] 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 ◴[24 Jun 25 17:57 UTC] 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 #
BeetleB ◴[24 Jun 25 23:20 UTC] No.44372125[source]▶
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.

replies(2): >>44379214 #>>44384879 #
1. brabel ◴[25 Jun 25 16:37 UTC] No.44379214[source]▶
You just described how to write a tool the LLM can use. Not MCP!! MCP is basically a tool that runs in a server so can be written in any programming language. Which is also its problem: now each MCP tool requires its own server with all the complications that come with it, including runtime overhead, security model fragmentation, incompatibility…
replies(1): >>44379448 #
2. BeetleB ◴[25 Jun 25 16:56 UTC] No.44379448[source]▶
> You just described how to write a tool the LLM can use. Not MCP!! MCP is basically a tool that runs in a server so can be written in any programming language.

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.

replies(1): >>44380645 #
3. brabel ◴[25 Jun 25 18:48 UTC] No.44380645[source]▶
You’re just confused. You can write a tool , or if your framework supports it, the tool can be also a MCP. But llm cares only about tools. Try to learn the underlying mechanics and you will understand the difference.