[HN Gopher] MCP is eating the world
___________________________________________________________________
MCP is eating the world
Author : emschwartz
Score : 184 points
Date : 2025-06-21 16:30 UTC (3 days ago)
(HTM) web link (www.stainless.com)
(TXT) w3m dump (www.stainless.com)
| 0x500x79 wrote:
| I believe that MCP is a bit over-marketed.
|
| MCP allows you to bring tools to agents you don't control. It's
| awesome, but it isn't the right match for every problem. If you
| believe the hype of X/LinkedIn you would think that MCP
| everywhere is going to be the solution.
|
| Bringing tools to your local Claude client is awesome, but there
| are still challenges with MCP that need to be solved and like all
| technology, it isn't applicable universally.
|
| Not to mention it's a recipe for burning tokens!
| tempodox wrote:
| > ... agents you don't control. It's awesome ...
|
| What have we come to when losing control in software
| development is called "awesome".
| loloquwowndueo wrote:
| WOW talk about quoting out of context.
| 0x500x79 wrote:
| 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.
| 0x457 wrote:
| Do you get mad at IDE plugins that let you extend software
| that you don't control?
| theOGognf wrote:
| Along with burning tokens, how MCP servers are ran and managed
| is resource wasteful. Running a whole Docker container just to
| have some model call a single API? Want to call a small CLI
| utility, people say to run another Docker container for that
|
| Feels like a monolith would be better
| MaxLeiter wrote:
| Remote MCPs should resolve some of this
| MyOutfitIsVague wrote:
| 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.
| jcelerier wrote:
| > 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.
|
| why does the smallest script take seconds to even start
| then?
| stingraycharles wrote:
| That is not normal. Small scripts should launch in
| milliseconds, not several seconds.
| antonvs wrote:
| Below is a transcript of a "smallest script" which runs
| in 328 ms total on my machine. And that includes loading
| an ubuntu OS image, which could be optimized depending on
| what dependencies the script needs.
|
| Of course, if you're invoking it on a remote cluster,
| there are many reasons it can talk longer, especially if
| the cluster has to scale to satisfy the request. But all
| those reasons are nothing to do with containers
| specifically - it's things like cluster capacity, node
| provisioning time, container pull time, network latency,
| etc. If you architect things properly, you can get the
| number below + network latency even for a remote cluster
| invocation. $ time docker run ubuntu
| echo hello world hello world
| real 0m0.328s user 0m0.011s sys
| 0m0.010s
| stingraycharles wrote:
| 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.
| pydry wrote:
| It's not the solution to every problem but it's a great
| substitute for a infrequently used app with mediocre UX and
| most of the world's apps probably do fall into that category
| actually.
| 0x500x79 wrote:
| Agree, but I think we should hold those Apps to a higher bar.
| Chat interfaces are not a replacement for good UX.
| pydry wrote:
| Have you tried holding Jira to a higher bar? I don't know
| how. I'd rather somebody just layered a conversational UX
| over it.
| Aurornis wrote:
| > I believe that MCP is a bit over-marketed
|
| MCP is pretty cool, but the way every AI influencer pivoted to
| producing MCP glorification posts at the same time has been
| groan-inducing. I can usually ignore the hype cycles, but I've
| been bombarded with so much MCP influencer content in the past
| few months that I feel exhausted every time I see those three
| letters.
| 0x500x79 wrote:
| It never fails that if you look at their title it's: VP of
| XYZ at something.ai as well!
| qsort wrote:
| 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.
| tptacek wrote:
| 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.
| brandensilva wrote:
| As a developer the hype is over the top for sure, but for
| the average marketer or influencer I can see how it is
| warranted.
|
| Now if there is a good way to deal with authentication and
| authorization piece without agents gone wild that would
| excite me as a dev a lot more at this point.
| tptacek wrote:
| If you're talking very specifically about MCP, and not
| about tool calling more generally, and you're just sort
| of making the point that the standards aren't fully baked
| or ready for general use --- that you can't yet reliably
| plug _any_ API into an agent like Claude Code you don 't
| control, then sure. But MCP is the public face of tool
| calling, and for tool calling _generally_ that 's not a
| real problem: you can make your own arrangements in your
| own agents, which are truly simple to write.
|
| I think as a developer, as opposed to an IT integrator or
| something like that, you should be _the most_ excited
| about this situation.
| pphysch wrote:
| MCP is a major lifeline for OpenAI and Anthropic. Their only
| reasonable way to compete with the big vertical AI integrators
| is if the "community" does all the hard work of integration,
| hence MCP. After the initial burst of greenfield enthusiasm I
| suspect it will stagnate as a yet another maintenance burden.
| nisegami wrote:
| It isn't hard to see why. I had a really hard time wrapping my
| head around why MCP was necessary and useful but I tried using*
| one recently and it's remarkable how big the gap between just
| being able to reply and being able to interact is.
|
| *after forking and modifying it for my use case
| dack wrote:
| yeah current AIs are surprisingly good at figuring out which
| tools to call and how to call them!
| ge96 wrote:
| Finally the rapping spider makes it big
| nickpeterson wrote:
| This is an aqua teen hunger force reference?
| mekael wrote:
| I want candy, bubblegum, and taffy...
| tempodox wrote:
| Doesn't everyone get a unicorn?
| dansiemens wrote:
| MCP is currently too difficult to setup and too complicated for
| consumers to understand. Once somebody big enough figures out
| distribution and integration a la the App Store, and the market
| starts to understand MCP integrations as extensions your AI
| client can orchestrate across (do one thing in App A, another in
| App B, etc all with a single prompt), it'll be off to the races.
| csomar wrote:
| MCP is too simple actually. You just use one command? I think
| the problem is that most MCP "servers" do not work. They are
| either too early/alpha, not well supported, too limited, etc.
| Everyone is trying to write blog post but not actually do the
| product development.
| svachalek wrote:
| This is true. Most of the MCP servers I have seen are also
| some of the worst examples of software I have ever seen.
| Given the people who are attracted to it, it's likely they're
| all vibe coded.
| time0ut wrote:
| In some ways MCP is like the next evolution of API over HTTP.
|
| We've exposed our APIs as SOAP endpoints. These were not well
| suited to web based clients, leading to the development of
| "RESTful" JSON endpoints. As web clients became more complex,
| GraphQL arose as a solution to some of the problems encountered.
| Maybe MCP is the next step.
|
| I don't mean that MCP will supersede these protocols. My company
| exposes our endpoints as SOAP, REST, and GraphQL still as they
| fit different use cases and customer bases. We are piloting an
| MCP version to see how that goes now.
|
| It is fun to work on something new and play with agents to see
| how they consume our endpoints in this form. I think there is a
| lot of potential.
| v3ss0n wrote:
| Unecessary complication. LLM Can call tools without MCP 100%
| fine. You don't need a Stateful SSE JSORPC Meshedup server
| running APIs rebraneded as tools at somewhere on the cloud .
| taude wrote:
| I think there's going to be a lot of places where you want
| the middleare that's only exposing a sub-set of apis. and the
| Ideas that you copy some URL, put it in your LLM Client, and
| then it magically gets all the tools/endpoints available to
| you, and you start interacting with it, simplifies the
| process greatly for a lot of users. No swagger, no http post,
| body vs params, etc....just play with with your prompt
| sentance until you get it to do what you want.
|
| (edit: sorry, I responded to wrong thread.)
| v3ss0n wrote:
| Yeah that but - Why SSE? - Why JsonRPC - Why Statefulness
|
| REST based Tool Call Server would work 100% fine. Now auth
| have to be redone for those specifically.
|
| And for users of MCP Tools - they are sending a lot of
| their information to whatever service they are running -
| that they have never control of
|
| For developer it is not necessary and security nightmare if
| you use someone's MCP service or run your own.
|
| For users , it is a privacy nightmare .
| jcelerier wrote:
| > LLM Can call tools without MCP 100% fine.
|
| but can the LLM host UI ask me for permission (in an outside-
| of-LLM domain) if the LLM wants to call API foo.bar ?
| fullstackwife wrote:
| Sounds like NPM:)
| v3ss0n wrote:
| Thats all part of how you code the LLMHost Backend and
| Frontend. I build several MCP and MCP-Less tool calling
| agents using autogen and they can ask the user permission.
| That is nothing to do with MCP at all.
|
| Look into AutoGen by microsoft or if you want more basic ,
| learn how tool calling in LLMs work.
| rTX5CMRXIfFG wrote:
| I'm still getting the hang of this but Apple's Foundation Models
| framework [1] (the one recently announced in WWDC) follows this
| protocol, correct? Does this mean that MCP, as a protocol, can
| actually take on different forms depending on how platforms/OSes
| want to allow their users to integrate with LLMs?
|
| [1] https://developer.apple.com/documentation/foundationmodels
| thm wrote:
| That Google Trends curve does/will look a bit like Smart
| Contracts.
| hk__2 wrote:
| > That Google Trends curve does/will look a bit like Smart
| Contracts.
|
| What do you mean? The curve for "Small Contract" is mostly flat
| compared to MCP:
| https://trends.google.com/trends/explore?q=Smart%20Contract,...
| ravenstine wrote:
| > Heck, even MCP itself isn't new--the spec was released by
| Anthropic in November, but it suddenly blew up in February, 3
| months later.
|
| Wow, the idea of what's "new" in software has always been really
| short, but damn, it's becoming questionable whether anything can
| be considered new these days.
| dack wrote:
| yeah it's crazy to think that claude 4 has only been out a
| month. And the previous iteration 3.7 was launched only in
| February!
|
| but also I think the interesting thing is that people didn't
| jump on MCP immediately after it launched - it seemed to go
| almost unnoticed until February. Very unusual for AI tech - I
| guess it took time for servers to get built, clients to support
| the protocol, and for the protocol itself to go through a few
| revisions before people really understood the value.
| sidewndr46 wrote:
| Yeah, if this was the Javascript ecosystem 3 months would mean
| the original implementation has been moved to maintenance mode
| and only gets security updates from here forward. Everyone
| would need to start migrating to the replacement as soon as
| possible.
| dack wrote:
| MCP still feels so early. It's getting better - we went from "set
| up `npx` on your system and edit this JSON file in an obscure
| directory" to "set the name and URL of your MCP server" in
| claude.ai. But you're right, even knowing how to find a URL for
| the MCP server is a tall order for most.
|
| I wonder what the optimal form factor is. Like what if your AI
| could /suggest/ connecting with some service? Like your AI is
| browsing a site and can discover the "official" MCP server (like
| via llms.txt). It then shows a prompt to the user - "can I access
| your data via X provider?". you click "yes", then it does the
| OAuth redirect and can immediately access the necessary tools.
| Also being able to give specific permissions via the OAuth flow
| would be really nice.
| pabzu wrote:
| Another hyped/clickbait headline about a "new technology" that
| will "transform everything"
|
| written by a company that sells this "new technology".
| sylens wrote:
| I just saw some job postings asking for 8+ years experience in
| MCP
| barbazoo wrote:
| You need 10+ for senior though.
| olddustytrail wrote:
| I think you're joking but if not I'd love to see one!
| skeeter2020 wrote:
| >> >> Heck, even MCP itself isn't new--the spec was released
| by Anthropic in November
|
| woosh!
| saulpw wrote:
| 1 year for a human is like 10 in AI-years.
| layer8 wrote:
| Not a problem for the 15x programmer.
| kibwen wrote:
| 15x is a rookie multiplier, do you need me to explain how
| exponential curves work? Within mere months I'll need to
| start resorting to up-arrow notation to express my value as
| a developer. And someday I might even start making more
| money too!
| steve_adams_86 wrote:
| 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
| ypeterholmes wrote:
| How does it sell a basic protocol that anyone can use?
| ezekiel68 wrote:
| It's clearly a plot by Big MCP to sell us more MCP. /s
| rattray wrote:
| 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.
| furyofantares wrote:
| I have various scripts that I tell claude about in all my
| CLAUDE.md files and it is successful at using them.
|
| Am I missing out on something by not using an MCP? I guess I
| wouldn't have to paste it into every CLAUDE.md but is there any
| other noticeable advantage?
| ashwinsundar wrote:
| You don't need to aspire to use "MCP", but rather select some
| MCP servers that will be useful for you.
|
| MCP servers basically expose pieces of the web/data that your
| LLM client has not been trained on. Maybe some private APIs, or
| internal data that isn't part of training data sets. Real-time
| data is another good use case.
|
| This list has a lot of ideas:
|
| https://github.com/modelcontextprotocol/servers?tab=readme-o...
|
| I personally use the Kagi MCP server (allows an LLM client to
| execute searches against the Kagi search engine), and
| stochastic thinking/sequential thinking (some alternate thought
| patterns that help models escape the "valley of optimization"
| problem).
|
| You can't tell Claude.md to "use the Kagi search engine"...it
| doesn't have an API key to do that. The MCP server basically
| just exposes the API. You're right, it's a lot less exciting
| than people make it sound. The future possibilities are where
| the excitement is at imo.
|
| I'm excited about MCP more from a developer side, than from a
| user side. It really does feel like the first week of mobile
| apps still. Will it "revolutionize everything"? No, just like
| mobile apps didn't solve every problem (and made some worse).
| furyofantares wrote:
| I can see the value if I'm connecting to MCPs other people
| have written. Or sharing MCPs for a team.
|
| As a solo dev though, I don't know of any MCPs that are
| really valuable to me that aren't more valuable exposed as a
| commandline tool. I have an "imagine" tool that creates/edits
| images and audio with various services available to it and
| guidance on how to use it, I have a "think" command that
| allows claude or (scripts claude or I write) to use different
| LLMs for different things and with a library of prompts for
| specialized tasks, etc. I don't have a kagi command but tbh
| that sounds useful and I may write a little wrapper for it so
| I can have it from the terminal too, rather than use an MCP.
|
| (None of this is a complaint about MCP btw - just not sure if
| I'm missing anything that would make it also useful to me
| right now.)
|
| Something I am interested in, is if claude code would do
| better with access to a language server. I love how claude
| produces most of it's diffs by string replace, rather than
| producing a diff and using an "apply model" like cursor does;
| but it seems it would be better off if it could "go to
| definition", "find references", and "rename" rather than use
| grep etc.
|
| I do see one project in the list you linked to that seems
| like it's going for that. Although again I'm not sure if
| that's better than having a language server cli available.
| ashwinsundar wrote:
| I don't think you're missing anything. My day-to-day
| workflow hardly involves MCP, to be honest. I prefer custom
| tooling (and command-line tools) for most of my development
| work as well.
|
| The language server MCPs are interesting, but I am not sure
| how to incorporate them into my Neovim workflow yet.
| revskill wrote:
| So MCP is basically: - getTools - executeTool
|
| ?
| remram wrote:
| I tried using MCP to run some custom functions from ollama &
| openwebui. The experience was not great.
|
| Doing anything with LLM feels more like arguing than debugging,
| but this was really surreal: I can see the LLM calling the
| function with the parameters I requested, but then instead of
| giving me the returned value, the LLM always pretends it doesn't
| know the function and tries to guess what the result should be
| based on its name.
|
| The protocol itself is really weird, almost based on standards
| but not quite. It was made by one vendor to fix one problem. It
| has the benefit of existing, but I don't know if it is worthy of
| any praise?
| never_inline wrote:
| I mean, LLMs you can run on ollama are usually pretty bad ones.
| svachalek wrote:
| I don't know what model you're using through ollama but a lot
| of people pick up a 4b model and expect it to be ChatGPT when
| it's like 0.2% of the size. 4b models are mostly toys imo. The
| latest generation of 8b models are sometimes useful, but often
| still laughably stupid. 14b starts to have potential, 30b are
| pretty good.
|
| But remember, the hosted frontier models are still gigantic
| compared to these, and still make stupid mistakes all the time.
| csomar wrote:
| Unless you are running DeepSeek/OpenAI/Anthropic models, I
| suspect your LLM will struggle with the complexity. That being
| said, except for Puppeteer and usebrowser, every MCP I have
| tried was complete _sh+t_. As: doesn 't really work and will
| confuse the hell out of your LLM.
| luketheobscure wrote:
| It's interesting how quickly my brain developed an AI detector
| for written language (this blog post screams ChatGPT).
|
| I wonder if it will stay effective, or if LLMs figure out a way
| around it? Or maybe it's just that this is the new way that
| technical blog posts are written, sort of how nearly all press
| releases feel univocal.
| kitsune_ wrote:
| It's not.
| faxmeyourcode wrote:
| 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.
| zackify wrote:
| I've managed to do the same thing!
|
| It's actually surprising just how powerful 1-5 tools can be if
| you document it well and the llm knows how to pass arguments
| from other tool responses you had higher up in the thread
| faxmeyourcode wrote:
| 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.
| dkdcio wrote:
| 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.
| yjp20 wrote:
| 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.
| rcarmo wrote:
| 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.
| rattray wrote:
| 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)
| cpursley wrote:
| Ditto on the postgres MCPs vs the standard pg cli - seems
| to prefer the cli. Which is fine enough for me.
| potatolicious wrote:
| 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.
| what-the-grump wrote:
| xkcd 927, every single time
| kevindamm wrote:
| So familiar I didn't even have to look it up
|
| ..but while it's true we have too many standards, I'm
| also not drowning in micro-USB and mini-USB cables
| anymore. There are paths of reduction.
| rictic wrote:
| 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.
| chime wrote:
| 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.
| rattray wrote:
| 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.)
| zackify wrote:
| 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
| hadlock wrote:
| MCP is JDBC for LLM
| __MatrixMan__ wrote:
| 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.
| tptacek wrote:
| I'm doing the same thing now (with Slack as a medium of
| interaction with the agent) --- but not with MCP, just with
| straight up tool call APIs.
| rattray wrote:
| 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.
| tptacek wrote:
| Just 5 or 6. I'm just using the OpenAI tool call API for
| it; I own the agent (more people should!) so MCP doesn't do
| much for me.
| fb03 wrote:
| This. If you are running your agent loop, MCP does
| nothing.
|
| MCP is an inter-process (or inter-system) communication
| standard, and it's extremely successful at that. But some
| people try to shoehorn it into a single system where it
| makes for a cumbersome fit, like having your service talk
| to itself via MCP as a subprocess just for the sake of
| "hey, we have MCP".
|
| If you own your loop AND your business logic lives in the
| same codebase/process as your agent loop, you don't need
| MCP at all, period. Just use a good agent framework like
| PydanticAI, define your tools (and have your framework
| forward your docstrings/arguments into the context) and
| you're golden!
| ramesh31 wrote:
| I've found it to be amazing purely as a new form factor for
| software delivery. There's a middle ground so common in
| enterprise where there's a definite need for some kind of
| custom solution to something, but not enough scale or
| resourcing to justify building out a whole front end UI,
| setting up servers, domains, deploying, and maintaining it. Now
| you can just write a little MCP tool that does exactly what the
| non-technical end user needs and deliver it as a locally
| installed "plugin" to whatever agentic tooling they are using
| already (Claude Desktop, etc). And using Smithery, you don't
| even have to worry about the old updating concerns of desktop
| software either; users get the latest version of your tooling
| every time they start their host application.
| rcarmo wrote:
| As someone who does both, I have to say that the only reason I
| am writing MCP stuff is that all the user-side tools seem to
| support it.
|
| 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.
|
| Then again, I have run the whole gamut since the EDI and
| Enterprise JavaBeans era, XML-RPC, etc. - the works. Our
| industry loves creating new API surfaces and semantics without
| a) properly designing them from the start and b) aiming for a
| level of re-use that is neither pathological nor wasteful of
| developer time, so I'm used to people from "new fields of
| computing" ignoring established wisdom and rolling their own
| API "conventions".
|
| But, again, the instant something less contrived and more
| integratable comes along, I will gleefully rm -rf the entire
| thing and move over, and many people in the enterprise field
| feel exactly the same - we've spent decades builting API
| management solutions with proper controls, and MCP bodges all
| of that up.
| alfalfasprout wrote:
| > 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.
| ramoz wrote:
| 9 times out of 10 my Claude Code is using a bash script before I
| hook up an MCP to it.
|
| - less tokens required in context (CLAUDE.md vs CLAUDE.md + MCP
| bloat per request)
|
| - native agent tooling, relying on Bash(my-script params)
|
| - less black box (you & the coding agent can read the scripts)
|
| MCPs are often wrapping restful apis. Turns out agents can use
| those just fine.
| Karrot_Kream wrote:
| Yeah I wonder just how much MCP is needed when the models seem
| fine at making REST requests as is, especially if there's an
| OpenAPI or similar spec available.
| klabb3 wrote:
| I won't speak to the technical merits of MCP but I will say this:
| it doesn't matter for many use cases, in particular consumer
| tech.
|
| The entire digital consumer economy is built around ownership of
| the screen real estate, due to a simple reason: ads. Whoever owns
| the sidebar sets the rules, period. Web2.0 was all about APIs
| (usually Rest/json) and in hindsight we see a clear distinction
| on where they're used: in commercial B2B apps. Conversely, big
| B2C players shut down the little open they had - Facebook, Gmail
| removed their XMPP support, and these days Twitter etc even
| gatekeep content when you're not signed in or using the app, and
| aggressively fortify against even basic scraping. When you're
| using other clients, you are bypassing their sidebar, meaning
| their opportunity to deliver ads.
|
| So no, your iOS apps and Twitter are not gonna "open up" their
| APIs in any way, not through Rest and not through MCP, simply
| because it goes directly against their incentives. The exceptions
| are (1) temporary to ride a hype train, and (2) services you pay
| money for (but even that is wishful and hypothetical).
| kloud wrote:
| The reason for MCP is that you get better results with optimized
| prompts rather than using existing API docstrings. So everybody
| is going to end up adopting it in some shape or form.
|
| It is a general concept, MCP itself is nothing special, it is
| that just that Anthropic formalized the observation first.
|
| Tool call = API call + instructions for LLM
|
| So vendors who provide APIs are going to write prompts, add a
| thin wrapper and out goes MCP. Or you create your own
| instructions and wrap in MCP to optimize your own workflows.
| mooreds wrote:
| For pure OpenAPI APIs, why wouldn't you just update your API
| docstrings? Or maybe add a new attribute to the OpenAPI spec
| for LLM prompts?
|
| I definitely see the value if you have a non standard API or
| undocumented API you wanted to expose.
|
| And I see value in the resources and prompts parts of MCP,
| since they can offer clients more functionality that would be
| hard to put into an API spec.
| neuroelectron wrote:
| MCP, in its current form, functions as a fun and profit remote
| exploit vector, primarily because it exposes AI systems to a wide
| range of attacks through under-specified security controls, heavy
| reliance on natural language context, and the ability for
| untrusted servers to manipulate model behavior. While MCP aims to
| standardize and simplify tool integration for AI, its half-
| implemented security features and architectural choices have made
| it a high-risk protocol, especially when deployed without
| additional safeguards.
|
| A treasure trove of possibilities: OAuth tokens, almost
| impossible to build alarms for outside of transmission rates
| (what are you running your own LLM? How about a meta MCP for
| twice the API calls?) , assumed trusted input, the server can
| inject malicious instructions via tool descriptions, leading to
| prompt injection, data exfiltration, or even remote code
| execution, sometimes without any explicit tool use by the user.
| mkagenius wrote:
| Unfortunately, the "protocol" doesn't have any emphasis on
| security so far, its all a repeat of HTTP -> HTTPS.
|
| However I feel the tooling built around MCP has been a lot and
| makes your work easier.
|
| The perfect use today would be using a locally running MCP
| servers for execution of code[1], manipulation of local files
| etc.
|
| 1. CodeRunner - Generate and run LLM code locally on Apple
| containers (https://github.com/BandarLabs/coderunner) (I am one
| of the authors)
| ezekiel68 wrote:
| Okay. I guess someone could have said the same thing at the
| dawn of the microcomputer era, too. Get back to us when the
| world melts down.
| neuroelectron wrote:
| I think "if you're not doing anything wrong you have nothing
| to hide" doesn't apply to B2B services.
| Animats wrote:
| > At Stainless, we're betting it's here to stay.
|
| By a seller of MCP.
|
| The trouble with MCP is that it requires a trip through an LLM
| for every transaction. It's not like the ends negotiate a simple
| protocol so that later queries are cheap. That's a huge cost
| increase as traffic increases.
| rattray wrote:
| I'm not sure I understand what you mean by "it requires a trip
| through an LLM for every transaction"?
|
| In a normal case of "production software", yeah, you would not
| want to add an LLM in the middle to make an API call. That's
| silly - just write the code to make the API call if you can do
| it deterministically.
|
| If you're talking to an LLM in a chat experience, and you want
| that LLM to go interact with some foreign system (i.e., hit an
| API), you need _some way_ of teaching the LLM how to make that
| API call. MCP is one such way, and it's probably the easiest at
| this point.
|
| Doing it through MCP does introduce some latency due to a proxy
| server, but it doesn't introduce an additional LLM "in the
| middle".
|
| (Disclaimer: I work at Stainless. Note that we actually sell
| SDKs at Stainless; our MCP generator is free.)
| taberiand wrote:
| There is no reason you couldn't design the system to hand off
| to a simple protocol through an MCP call, it's entirely up to
| what works in the specific situation. There is nothing in the
| design that mandates a path through the LLM for every request
| or transaction.
| nzach wrote:
| > Heck, even MCP itself isn't new--the spec was released by
| Anthropic in November, but it suddenly blew up in February, 3
| months later.
|
| Maybe it was because OpenAI announced they would start to support
| MCP in their tools ? [0]
|
| Perhaps I'm being too harsh with the author, but this article
| definitely gives me vibes of "AI slop".
|
| [0] - https://techcrunch.com/2025/03/26/openai-adopts-rival-
| anthro...
| yjp20 wrote:
| > Maybe it was because OpenAI announced they would start to
| support MCP in their tools ? [0]
|
| Author here, I assumed this would be the reason too, but the
| timelines don't really match up. Momentum was already strong by
| the time that OpenAI adopted it. And it's an educated guess on
| my part, but that's also probably why they adopted it in the
| first place.
|
| Some sources point to the MCP talk at AI Engineer being the
| turning point (and the timelines match up), but like with all
| viral studies the answer is pretty complicated and multi-
| faceted, rather than having a single cause.
|
| > Perhaps I'm being too harsh with the author, but this article
| definitely gives me vibes of "AI slop".
|
| I think it's fine to be harsh! I don't like AI slop either but
| unfortunately this article was mostly handwritten, so it's just
| a skill-issue on my part. I'll try to do better next time
| nilslice wrote:
| should kill off sdk generators too
| neya wrote:
| Obligatory note - if you're a backend developer, you do not need
| MCP. MCP is just tool/function calling. It has been around for a
| lot longer now. MCP is only needed if you need something to
| integrate with the frontend chat applications. If you need to
| automate something with LLMs, you do not _need_ MCP. Right now,
| it 's just the new cool buzzword to throw around.
| ezekiel68 wrote:
| AI coding tools have been improving/updating like craze over
| the past six months.
|
| Honest question: what are some of the AI Dev tools (I prefer
| command line) that have leapt ahead recently, with good
| tool/function calling? Do you (or others) have a clear
| preference for Claude Code vs aider vs some other alternative?
| Or is the meta shifting toward the orchestrators like
| Taskmaster and Puppeteer?
| neya wrote:
| I meant to say that MCP is just a wrapper around good old
| function/tool calling, it's not a new superpower by itself.
| So, if you're designing a Saas, you don't need to use MCP
| yourself, you can just use good old function/tool calling.
|
| To answer your specific queries, I use the autocomplete in VS
| Code and I directly chat with ChatGPT-o3 for advanced
| problems because my background is in Elixir and most models
| that are hyped up fail badly with Elixir. I'm always a huge
| fan of o3 as it can solve the most complex problems I throw
| at it..
| atonse wrote:
| Yes, but if I'm implementing "good old function/tool
| calling" today, why would I not implement it as MCP? I
| suppose it complicates things? MCP, in addition to being
| tooling endpoints, would also open up my software to a
| rapidly growing ecosystem that requires minimal additional
| work.
|
| AND I can still use those same endpoints as tools. What
| would be the argument for "you don't need MCP when
| implementing new stuff"?
| knowaveragejoe wrote:
| This is a really nifty CLI tool that lets you fit an LLM into
| a shell environment. Check out examples like piping context
| into and out of the `llm` command.
|
| https://github.com/simonw/llm
| hadlock wrote:
| You don't need to use RESTful JSON to get two computers to
| communicate with eachother, either. You can just implement your
| own thing, and if someone wants to interface with it, they can
| write their own adapter! Who needs decades of battle tested
| tooling? This can be a Not Invented Here safe-space. Why not.
| ezekiel68 wrote:
| I'm inclined to agree with the conclusions of the article. A lot
| of people make good points here about manual tooling (and I
| personally prefer this myself) but: Worse Is Better.
|
| The MCP way of accessing extra functionality and context will be
| more accessible to more people, with "recipes" they can easily
| set up once (or rarely) and thereafter continue to reap the
| benefits of enhanced LLM operation. There's already a huge arms
| race in the "orchestrator" space for tools to support MCP plus
| model routers plus Ollama local plus focused context RAG. I'm
| pretty sure we will look back at 2025 as a Great Leap Forward
| (yes, including the casualties implied in that reference) for LLM
| effectiveness.
|
| It's going to be a whole new Eternal September[0] except for LLM
| usage this time. And a good number of the new "normies" this time
| are going to be Pointy-Haired Bosses.
|
| [0] https://en.wikipedia.org/wiki/Eternal_September
| DonHopkins wrote:
| >Instead of serving 200 standalone tools, we serve three meta-
| tools and let the LLM discover endpoints at run-time.
|
| >list_api_endpoints lets the model search the catalog ("what can
| I do with counterparties?")
|
| >get_api_endpoint_schema pulls the JSON-schema for any route it
| finds
|
| >invoke_api_endpoint executes that route with user-supplied
| params
|
| >This approach allows the LLM to dynamically discover, learn
| about, and invoke endpoints as needed, without requiring the
| entire API schema to be loaded into its context window at once.
| The LLM will use these tools together to search for, look up, and
| call endpoints on demand.
|
| Congratulation, you have reinvented Microsoft COM, IUnknown, OLE,
| IDispatch, and ActiveX for LLMS!
|
| I'm not being sarcastic or criticizing, it's actually a good
| idea! Just not new.
|
| https://news.ycombinator.com/item?id=12975257
|
| https://news.ycombinator.com/item?id=20266627
|
| https://news.ycombinator.com/item?id=29593432
|
| https://news.ycombinator.com/item?id=19837817
|
| I'm also not saying there aren't better approaches, like "NeLLM":
| taking the NeWS approach to LLMs, where MCP is more like "X-LLM":
| taking the X-Windows approach to LLMs.
|
| Sending JSON data back and forth between a Node based
| orchestrator and an LLM is one thing, all well and find and
| traditional, but why not send and evaluate JavaScript code
| itself? Both Node (or even a secure Node isolate) and the LLM can
| generate and evaluate JavaScript quite well thank you, and it's a
| hell of a lot more powerful and concise and extensible that a
| fixed JSON protocol, for the exact same reason that NeWS is a
| hell of a lot more powerful and concise and extensible than the
| fixed X-Windows protocol.
|
| https://news.ycombinator.com/item?id=43952748
|
| >I agree they should learn from DLLs, gRPC, SOAP, IDL, dCOM, etc.
|
| >But they should also learn from how NeWS was better than
| X-Windows because instead of a fixed protocol, it allowed you to
| send executable PostScript code that runs locally next to the
| graphics hardware and input devices, interprets efficient custom
| network protocols, responds to local input events instantly,
| implements a responsive user interface while minimizing network
| traffic.
|
| >For the same reason the client-side Google Maps via AJAX of 20
| years ago was better than the server-side Xerox PARC Map Viewer
| via http of 32 years ago.
|
| >I felt compelled to write "The X-Windows Disaster" comparing
| X-Windows and NeWS, and I would hate if 37 years from now, when
| MCP is as old as X11, I had to write about "The MCP-Token-Windows
| Disaster", comparing it to a more efficient, elegant, underdog
| solution that got out worse-is-bettered. It doesn't have to be
| that way!
|
| >The X-Windows Disaster:
|
| https://donhopkins.medium.com/the-x-windows-disaster-128d398...
|
| >It would be "The World's Second Fully Modular Software Disaster"
| if we were stuck with MCP for the next 37 years, like we still
| are to this day with X-Windows.
| m3kw9 wrote:
| Not when prompt injection and other fairly trivial security
| issues hasn't been solved
| jlowin wrote:
| FastMCP author here -- (maybe surprisingly) I agree with many of
| the observations here.
|
| FastMCP exists because I found the original spec and SDK
| confusing and complicated. It continues to exist because it turns
| out there's great utility in curating an agent-native API,
| especially when so many great dev tools have adopted this client
| interface.
|
| But the spec is still so young and at such risk of being co-opted
| by hype (positive and negative). I would invite everyone to
| participate constructively in improving it.
|
| Lastly: this article is plainly AI generated, as `from mcp import
| tool` is completely hallucinated. Just some food for thought for
| the "AI should be able to figure out my complex REST API" crowd
| that seems well represented here.
| ashwinsundar wrote:
| I would invite everyone to participate constructively in
| improving it.
|
| How do you recommend that I participate? I've written a few MCP
| servers (based on FastMCP - great work!), and contributed one
| to Anthropic's list. How do I actually participate in
| maintaining or improving the core MCP spec? I was under the
| impression that it was being driven by Anthropic.
| yjp20 wrote:
| (author here)
|
| You're right, that snippet was ai-generated and I forgot to
| action one of my todos to fix that snippet. This was negligent
| on my part, and I hope you'll forgive me.
|
| We're fixing that right now, thank you for the correction!
| prats226 wrote:
| The advice anthropic gives in building agents is to ditch the
| abstractions like agent frameworks etc and just code it yourself.
| I believe its also applicable to MCP to same degree?
| matt3210 wrote:
| With MCP I can call tools with my own software too without having
| to use an LLM
| prats226 wrote:
| One of the major miss right now seems to be in tool calling
| specs, you specify function names, description, inputs but not
| outputs. I believe with reasoning models planning things, it
| would be important to understand output format, descriptions as
| well?
| gregorym wrote:
| Today almost every public MCP server targets B2B workflows like
| GitHub, Jira, Linear, Slack, and similar developer or workplace
| tools.
|
| In a recent talk, Andrej Karpathy argued that "LLMs are the new
| operating system." If that analogy holds, the only "apps" we've
| built so far live in the enterprise quadrant of that OS.
|
| I expect consumer facing MCP experiences to follow soon. I'm not
| yet sure what they'll look like, perhaps games or other
| interactive content but the infrastructure is falling into place:
| OpenAI has said ChatGPT will support custom MCP connectors,
| ElevenLabs' 11AI already ships with MCP integration, and Claude
| has added remote MCP support. As those channels reach mainstream
| users, everyday LLM users will start asking for richer experience
| and MCP is how developers will deliver them.
___________________________________________________________________
(page generated 2025-06-24 23:01 UTC)