[HN Gopher] MCP is the coming of Web 2.0 2.0
___________________________________________________________________
MCP is the coming of Web 2.0 2.0
Author : freediver
Score : 166 points
Date : 2025-05-23 15:33 UTC (7 hours ago)
(HTM) web link (www.anildash.com)
(TXT) w3m dump (www.anildash.com)
| lxgr wrote:
| Turns out the "Semantic Web" was a syntactic web all along, and
| maybe this is the real deal?
| jaredcwhite wrote:
| MCP is not an open standard.
|
| People routinely mistake "protocol specification uploaded to
| GitHub, PRs welcome" as open standards. They are not. Calling
| them "open protocols" because they are _open source_ , not _open
| standards_ (no standards body was involved in the making of this
| protocol!) is essentially a form of openwashing.
|
| This has been happening way too frequently lately (see also:
| ATProto), and it really needs to be called out.
| Toritori12 wrote:
| I guess it is a first step... a lot of current "open" protocols
| started as proprietary.
| croes wrote:
| The first step should include more security.
| nicoburns wrote:
| > no standards body was involved in the making of this
| protocol!
|
| Is a standards body being involved relevant? Many standards
| ratified by standards bodies are "pay to access" and seem much
| less open than many de facto standards where no standards body
| was involved.
| isodev wrote:
| > Is a standards body being involved relevant?
|
| I believe it is. Taking the example of ATproto, it boils down
| to a managed platform as a service but they seem to do a
| #BuildInPublic thing where we can experience early developer
| previews. That's not really open and it isn't a standard.
| philosophty wrote:
| How are these not "open" if they're GitHub projects and
| entirely open source and open to outside contribution?
|
| The organizations that create "standards" are much less
| open than this, requiring in person lobbying, schmoozing,
| travel, and company affiliations.
| 98codes wrote:
| Open standard or not, how is it a standard at all? I spent a
| while trying to find what the current version number of the
| spec is, and I could not find one. Theer were SDKs, and the
| SDKs have versions, but the protocol itself seems to be on
| v0.0.0.
| maxwellg wrote:
| MCP uses a date based system for versioning. The most recent
| specification is 2025-03-26 -
| https://modelcontextprotocol.io/specification/2025-03-26
| underbluewaters wrote:
| Successful standards usually start out scrappy, are embraced by
| a community, and then are blessed by standards bodies. What
| comes out of working groups of standards bodies rarely gains
| traction. See xhtml vs "html5".
| croes wrote:
| Does MCP still have the security issues?
|
| A big mistake in the first place to start it without proper
| security.
|
| That not Web 2.0 2.0, that's Web 1.0
| doug_durham wrote:
| It's a mistake to not start at all because of an issue that
| may not be important for many important use cases.
| croes wrote:
| It's a mistake to start and to think security is a non
| important issue.
|
| Anything that's connected to the web has to consider
| security at step one.
|
| How often are we repeating the same mistakes over and
| over again?
| troupo wrote:
| It's a mistake to invent your own terminology, skip all
| existing forms/standards/protocols of communication and
| chose the objectively worst-fitting one, and skip
| implementing one of the most fundamental part required by
| nearly anything
| jedisct1 wrote:
| MCP Servers are usually installed locally and can do
| whatever they want on the local machine.
|
| But this is solved by sandboxes such as mcp.run .
| croes wrote:
| Sandboxes aren't a solution just a workaround for a
| bigger problem
| sali0 wrote:
| Partially agree. But I can't help thinking this is the natural
| lifecycle of protocols. They first start as open projects,
| proliferate as such, and evolve into standards with governance
| once they catch on.
|
| What would you call these projects? Open protocols?
| dangoor wrote:
| It has become a de facto standard. There are many
| implementations of MCP. We'll have to see if it fizzles out or
| if some reasonable stewardship/governance come about, but it is
| very much possible for something to be a standard even without
| a standards body.
| anildash wrote:
| I was using the phrase in the vernacular sense; I've worked on
| genuine open standards and know the difference. I don't think
| it matters that much to use the phrase in this way in an
| obviously casual piece on my personal blog, as opposed to a
| more formal assessment of a technology.
| bad_haircut72 wrote:
| "The rise of MCP gives hope that the popularity of AI amongst
| coders might pry open all these other platforms to make them
| programmable for any purpose, not just so that LLMs can control
| them."
|
| I think the opposite, MCP is destined to fail for the exact same
| reason the semantic web failed, nobody makes money when things
| aren't locked down.
|
| It makes me wonder how much functionality of things like AI
| searching the web for us (sorry, doing "deep-research") might
| have been solved in better ways. We could have had restaurants
| publish their menus in a metadata format and anyone could write a
| python script to say find the cheapest tacos in Texas, but no,
| the left hand locks down data behind artificial barriers and then
| the right hand builds AI (datacenters and all) to get around it.
| On a macro level its just plain stupid.
| fidotron wrote:
| > I think the opposite, MCP is destined to fail for the exact
| same reason the semantic web failed, nobody makes money when
| things aren't locked down.
|
| I think this is right. MCP resembles robots.txt evolved into
| some higher lifeform, but it's still very much "describe your
| resources for us to exploit them".
|
| The reason the previous agent wave died (it was a Java thing in
| the 90s) was eventually everyone realized they couldn't trust
| their code once it was running on a machine it's supposed to be
| negotiating with. Fundamentally there is an information
| assymetry problem between interacting agents, entirely by
| design. Take that away and huge swathes of society will stop
| functioning.
| arbuge wrote:
| "describe your resources for us to exploit them"
|
| What you want to do is offer resources that make you money
| when they're "exploited".
| fidotron wrote:
| I would agree with that if there were no distinction
| between clients and servers. i.e. agents and LLMs are
| resources that should be discovered and exploited in the
| same exact way as anything else, and switchable in the same
| ways.
|
| The whole thing reminds me of stuff like Alan Kay's
| legendary OOPSLA talk in 1997 (
| https://www.youtube.com/watch?v=oKg1hTOQXoY ) "Every object
| should have an IP" (Also "Arrogance in computer science is
| measured in nano Dijkstras").
| renatovico wrote:
| i think the problem is in business process, it's created
| for no work automatic, the people need be on control OR
| need have block because well if all people try cancel your
| subscription and can go in one step with a simple prompt,
| this is a huge revenue loss.
|
| look how all companies have super system for crm/sales but
| when you go to backoffice all run in sheets and sometimes
| in real paper.
| isodev wrote:
| I think MCP's popularity is a side effect of the hype bubble
| driving AI atm - one of the fancy things one can do with AI.
|
| If there was any "easy" value in making one's data available in
| a standard form, we would've seen a lot more adoption of
| interoperable endpoints (e.g. using schema.org or generally
| common ontologies as opposed to custom formats that always need
| a special magic SDK).
| doug_durham wrote:
| There is an easy way to make your data available. It's
| existed for several hundred years, it's called plain text. We
| now have tools that allow computers to work with plain text.
| Outside of specific niches ontologies are vanity projects.
| pphysch wrote:
| xAI is a concrete example of this. During the initial LLM
| explosion, X locked down its previously public APIs and data
| sources. Simultaneously, xAI is investing massively in building
| its private data hoard and compute infrastructure. Probably a
| similar case with Meta.
|
| "Data for me but not for thee"
|
| MCP is only getting the light of day, arguably, because of LLM
| "one trick ponies" like OpenAI and Anthropic, who do benefit
| from MCP amplifying their value proposition. As that business
| model continues to fizzle out and lose/subordinate to the AI
| integrators (Google, Microsoft, xAI?), MCP will probably fizzle
| out as well.
| klabb3 wrote:
| > "Data for me but not for thee"
|
| Exactly. Consumer tech has been locking down APIs and
| actively working against interop since the advertising
| business model became dominant. Web 2.0 is the most obvious
| example, but there are plenty more.
|
| Look, you don't even own your own contacts on social media
| sites. If you access Google from an atypical browser you will
| get fingerprinted, captchad and rejected. Anti-scraping, anti
| fraud, paywalls, even lawsuits because you're using "our"
| APIs (see oracle).
|
| It's not the tech, it's the business model. It's adversarial,
| it's a Mexican standoff. Doesn't matter how good the MCP spec
| is, it's not gonna go anywhere with consumer apps. As long as
| the economy is based on ads, your B2C company needs a sidebar
| to show ads (or in rare cases, subscriptions). You're not
| gonna make money from providing a free API.
| throwaway7783 wrote:
| MCP is basically APIs V2 as far as I can see. It probably will
| evolve in its concrete specs, but useful and not niche,
| especially when they can be composed fairly trivially.
|
| In that sense, it is probably the building block for the next
| user interface, which is conversational.
|
| Maybe the mention of web 2.0 is triggering all negative
| responses here, but on it's own, it is useful and could disrupt
| (not MCP itself, but the overall field) how we interact with
| software and systems
| throwaway13337 wrote:
| It's reasonable to be cynical, but the future hasn't been
| written yet. If we choose only to see a negative future, we
| will ensure that it can only exist.
|
| In the negative vein, I see a lot of VCs and business leaders
| talking about making AI for companies that directly interface
| with customers.
|
| Those agents will be used to manipulate and make painful
| existings services exactly like today. Enshitified
| transactional websites engineered for maximum pain.
|
| A different direction can happen if we choose instead to use
| our ai agents to interact with business services. This is
| actually what's currently happening.
|
| I use gemini/chatgpt to find things on the web for me without
| being manipulated and marketed at. Maybe one day soon, I can
| buy airline tickets without the minefield of dark patterns
| employed to maximize A/B tested revenue.
|
| The only thing that needs to happen to keep us on this path is
| to bite the heels of the major companies with great agent
| systems that put the user at the center and not a brand. That
| means selling AI agents as a SaaS or open source projects - not
| ad-supported models.
|
| This community is probably the group that has, collectively,
| the most say in where this future goes. Let's choose optimism.
| jahewson wrote:
| The thing is, if AI agents become a significant part of web
| traffic then the content of the web will simply shift to
| manipulate the agent instead of the human.
|
| And don't forget when you use an AI agent today to buy
| something it's using "marketing" information to make its
| decisions. It's influenced by SEO in its search results,
| indeed there's no shortage of marketers busy working out how
| to do this.
|
| I do agree there's much to be optimistic about but the
| fundamental dynamics of the consumer market won't change.
| throwaway13337 wrote:
| It's absolutely true that in that future vision, the agents
| will then be marketed at.
|
| And that's great.
|
| In that world, those agents will sift through the noise.
| And the one that does that the best will win.
|
| The end user experience then becomes uniform and pleasant.
|
| It's the difference between talking to a personal secretary
| and a customer service representative. No one should have
| to endure the latter.
| kibwen wrote:
| _> In that world, those agents will sift through the
| noise. And the one that does that the best will win._
|
| The existence of agents capable of learning to cut
| through the enshittification also implies the existence
| of agents capable of learning to enshittify all the more
| effectively. It's an arms race, and there's no reason to
| suspect that the pro-consumer side will win over the pro-
| exploitation side.
| gz5 wrote:
| >nobody makes money when things aren't locked down
|
| i would rephrase as "incumbents don't usually make more money
| if things are opened up".
|
| if consumer gets materially better value, then challenger
| ecosystem around MCP will evolve. it will be open at first -
| great for startups and challengers, innovator's dilemma for
| market leaders.
|
| and then it will close as the new wave establishes their moats.
| but, similar to web, even though the current web leaders are
| now much more closed than we would like, the overall ecosystem
| is more open than it was.
| ljm wrote:
| HATEOAS was the dream in the early 2010s and that basically
| went nowhere beyond generating swagger yaml, despite the fact
| it intended to make API consumption trivial.
|
| Whoever coined it as HATEOAS basically set it up to fail
| though.
| badgersnake wrote:
| MCP is just that again, but less well thought out. Everything
| new is old.
| johnmaguire wrote:
| > Whoever coined it as HATEOAS basically set it up to fail
| though.
|
| I could never understand making the term "hate" so prominent.
| dragonwriter wrote:
| > HATEOAS was the dream in the early 2010s and that basically
| went nowhere
|
| I dunno, HTTP/1.1, the motivating use case for REST and
| HATEOAS, seems to have been moderately successful.
| Joker_vD wrote:
| The reason the semantic web failed is not only because "nobody
| makes money when things aren't locked down". It's also because
| nobody ain't got no time for generating infinite amount of
| metadata when full-text search and indexing, with a judicious
| pinch of fuzzy matching, is both faster and more reliable. And
| LLMs, as much as I dislike the technological/societal
| consequences of their existence, are effectively further
| development of the latter, so they won't go away.
|
| Manual or even semi-automated cataloguing of websites (and
| further curating) of websites wasn't the answer to "how do I
| find stuff on the web" -- Google was. Having standardized
| metadata format for menus is undoubtedly nice -- but good luck
| making people to use it. You just can't. It really is both
| cheaper and easier for everyone involved to have website with
| arbitrary information layout scraped and fed into an LLM to
| extract relevant data: because what is "relevant" is different
| for everyone. You can't pre-ordain the full list of possible
| relevant metadata, and, again, good luck forcing everyone to
| fill out those 500 items-long forms. Ain't nobody got time for
| that.
| jauntywundrkind wrote:
| I tend to agree one of the top semantic web problems was:
|
| > _It 's also because nobody ain't got no time for generating
| infinite amount of metadata_
|
| There's also a lot of tooling problems too, that the semantic
| web doesn't integrate gracefully with POJO of the programming
| worlds.)
|
| The tooling distance between users/devs and semantic web
| remains. But all that metadata? There being an interesting
| rich world of information, associated & well described &
| meticulous? Uh we actually seem like we just invented a
| really powerful tool at doing all this immense catalogization
| (LLM's).
| doug_durham wrote:
| Plain human readable text is not an "artificial barrier". It
| the nature of our our world. Requiring that a restaurant
| publish menus in a metadata format is an artificial barrier.
| That the beauty of these new NLP tools. I don't need to have a
| restaurant owner learn JSON, or buy a software package that
| generates JSON. We can use data as it is. The cost of building
| useful tools goes to near zero. It will be imprecise, but
| that's what human language is.
| Y_Y wrote:
| Plain text menus would have been fine
| a1j9o94 wrote:
| How do you do things like compare prices in plain text?
| pests wrote:
| You look at one price then look at a different one and
| then you make your comparison
| lucideer wrote:
| > _It the nature of our our world._
|
| It's the nature of capitalism.
|
| Some forms of capitalism may have roots in the natural world
| - natural selection as both a destructive & wasteful
| competitive process certainly has a lot of parallels in
| idealised markets - but there's nothing inherent about your
| menu example when it comes to the modern human world, beyond
| restrictions placed upon us by capitalism.
|
| > _Requiring that a restaurant publish menus in a metadata
| format is an artificial barrier_
|
| This is oddly phrased as noone would need to _require_ anyone
| to do anything - it 's obviously beneficial to a restaurant
| to publish their menus in formats that are as broadly usable
| as they can. The only barrier to them doing that is access to
| tools.
|
| The various hurdles you're describing ("buying" software, the
| "cost" of building tools) are not _natural_ phenomena.
| philosophty wrote:
| I haven't paid close attention. Why can't people make money
| with MCP-based APIs? Why can't providers require API keys /
| payment to call their functions?
| olalonde wrote:
| Sure they can - they're just another API interface tailored
| for LLMs. I think parent and OP are in fact ranting about
| that (many APIs being locked behind signups or paywalls). Not
| sure I agree with the criticism though. In my view, web 2.0
| was a huge success: we went from a world with almost no APIs
| to one where nearly every major website or app offers one.
| That's real progress, even if we didn't turn every business
| into an open data non-profit.
| jsnell wrote:
| It's not just that nobody makes money providing a free and open
| API. It's that to operate such an API you'll basically need
| unlimited resources. No matter how many resources you throw at
| the problem, somebody will still figure out a way of exhausting
| those resources for marginal gains. MCP will just make the
| problem worse as AI agents descend on any open MCP servers like
| locusts.
|
| The only stable option, I think, is going to be pay-per-call
| RPC pricing. It's at least more viable to do then it was for
| Web 2.0 APIs, since at least the entity operating the model /
| agent will act as a clearinghouse for all the payments. (And I
| guess their most likely billing model is to fold these costs
| into their subscription plans? That seems like the best way to
| align incentives.)
| alberth wrote:
| Sure - not many companies made money on "HTTP", but lots of
| people/companies made gobs of money by adopting it.
| drusepth wrote:
| > I think the opposite, MCP is destined to fail for the exact
| same reason the semantic web failed, nobody makes money when
| things aren't locked down.
|
| Is there a way to handle "locking down" things with MCP? It
| seems like a potential opportunity for freemium services if
| they have a mechanism for authentication and telling the MCP
| caller "this user has access to these tools, but not _these_
| yet".
| seanhunter wrote:
| Yes. MCP allows (and uses) exactly the same authentication
| mechanisms that any other rest or similar api allows. So if
| you have a service you want to expose (or not) via MCP you
| can do that in exactly the same way as you currently could do
| that for a rest API.
|
| The difference for the user is instead of them having to make
| (or use) a special-purpose client to call your rest api, the
| llm (or llm powered application) can just call the api for
| them, meaning your rest service can be integrated into other
| llm-powered workflows.
| jjfoooo4 wrote:
| MCP is described as a means to make the web open, but it's
| actually it's a means to make demos of neat things you _could
| do_ if the web were actually open.
| testplzignore wrote:
| > On a macro level its just plain stupid.
|
| You've described most white-collar jobs :)
| FuriouslyAdrift wrote:
| Oh SGML... what could have been
| AlienRobot wrote:
| I still don't know who uses this semantic web. Like you have
| all these semantics marked up... for whom? What are actual
| applications using this?
|
| Google has a small subset of schema.org it supports, but rather
| than "semantic web" it feels more like "here's my API." Its own
| schema tester often complains about things that should be valid
| schemas, simply because it doesn't conform to its API. How
| would any web developer mark up (and test the validity of said
| mark up) for applications that don't even exist?
| tagfowufe wrote:
| While I understand where the author is coming from, and I get his
| sentiment(s), I don't think what he proposes is actually
| possible: his vision relies on faux open tools and protocols and
| having access to walled gardens. The means of computation for
| these kinds of things are owned by a tiny minority. Nearly
| everything is a SaaS or is based, one way or the other, on rent
| extraction. We're essentially subject to the whims of someone who
| is letting us do something for as long as we play nice.
|
| >There is a chance, though, that younger developers, and those
| who weren't around to build back during that last era a
| generation ago, are going to get inspired by MCP to push for the
| web to go back towards its natural architecture. It was never
| meant to be proprietary.
|
| Alas, the reason APIs started closing and being metered is
| because, after all, there's someone owning and paying for the
| hardware upon which you are making calls and requests.
|
| As long as there's no way to agree upon how to have a bunch of
| servers providing computation for anyone and at the same time
| ensuring their upkeep without the need for a central authority, I
| don't think such vision is sustainable long term. The current
| state of the Internet is proof of it.
| CSMastermind wrote:
| I really wish we'd learn from Web 2.0.
|
| All the mistakes of "hey everything has an API now" that we
| learned from we're back to repeating.
|
| I feel like that meme from Watchmen with the blue guy sitting on
| Mars.
| anildash wrote:
| Definitely having that feeling a lot these days watching the
| cycles repeat. I am tired of earth. These people. Their APIs.
| olalonde wrote:
| What mistakes are we repeating?
| thuanao wrote:
| Not understanding that businesses don't want open data or
| open protocols. Internet businesses want to monopolize
| information and charge rent for it. Capitalists don't want to
| commodify software, as that means lower profits and
| competition. They want to monopolize it. That's the whole
| game, except for companies selling physical goods over the
| Internet.
| olalonde wrote:
| So, is the idea that MCP might benefit from more built-in
| support for things like paid APIs to incentivize
| businesses?
| thuanao wrote:
| I think so. Though the premise of MCP betrays that AI
| isn't human-level intelligent. If it was there would be
| no need for a standard interface. It would be able to
| read API docs, navigate UIs to generate the proper keys,
| enter in billing info, and use all of that to make API
| requests by trial and error. That's what humans do.
| riwsky wrote:
| _software_ capitalists don't want to commodify software.
| But their complements do: I could totally see Apple pushing
| for something like this to make the iPhone more valuable
| and integrated.
| quotemstr wrote:
| People said the same thing about "APIs" 10-15 years ago when they
| were a craze. Everything had to be an API! Doesn't matter whether
| it made sense to not. It's going to change the world! We're going
| to have San Francisco events with microbrews for APIs! Everyone's
| going to publish API frameworks! Let me make api-blog-
| blog.blogger.blog!
|
| Blah. Bay Area Tech regularly goes through these bursts of
| baseless enthusiasm for rehashes of existing technology. Is MCP
| useful? Yeah, probably. Is the current froth based on anything
| but SF-scene self-licking-ice-cream-code social cred? No.
| almog wrote:
| Every bubble and its WSDL moment...
| rglover wrote:
| > Bay Area Tech regularly goes through these bursts of baseless
| enthusiasm for rehashes of existing technology. Is MCP useful?
| Yeah, probably. Is the current froth based on anything but SF-
| scene self-licking-ice-cream-code social cred? No.
|
| Thank you. You said what I was going to say. Another goose
| chase for something that's valuable, certainly, but being
| frothed up into some mythical sword in the stone.
|
| It's ultimately just a way to say "hey, here's some extra
| context including some functions we have defined on our server
| that you can ask us to call."
| daemonk wrote:
| At a higher level, MCP seems wants to enforce a standard where no
| standard exists. I get that the low level technical
| implementation allows AI to utilize these tools.
|
| But there doesn't seem to be any standardization or method in how
| to describe the tool to the AI so that it can utilize it well.
| And I guess part of the power of AI is that you shouldn't need to
| standardize that? But shouldn't there at least be some way to
| describe the tool's functionality in natural language or give
| some context to the tool?
| awestroke wrote:
| Each prompt, tool or resource fetched from an MCP server
| includes a name, description and a schema. What more do you
| want?
|
| https://modelcontextprotocol.io/specification/2025-03-26/ser...
| quantadev wrote:
| We can now build the Semantic Web. All we have to do is create a
| tiny protocol (as an optional extension to MCP) for how
| organizations can share their SQL Table Create DDL as a static
| file that MCP apps can read, to understand data, and then, using
| the already-existing tools for AI/LLM function calling to SQL,
| that would become a Semantic Web.
|
| That would fill the missing link that always held back the
| Semantic Web which was the lack of any incentive for companies to
| bother to use a standard "Data Type" rather than all proprietary
| data types. Once we have an MCPQ (MCP with Queries), suddenly
| there's an incentive for organizations to collaborate at the data
| structure layer.
| vivzkestrel wrote:
| Everything seems to be susceptible to enshittification and so far
| I see no evidence that MCP is any exception. First the value will
| go to users, then the users ll cut short to drive value to
| shareholders and then it will turn to an absolute pile of garbage
| as businesses make every attempt to somehow cash in on this
| yupitsme123 wrote:
| It's a protocol. The new version of the web that gets built
| with it may get shitty, but like HTTP or TCP, the protocol
| stands on its own merits and can be used freely to build cool
| stuff outside of that shitty ecosystem.
| RansomStark wrote:
| MCP could have cracked the web opeb. The terrible standard was
| all about clients and local servers all on the same host.
|
| Imagine it, everything is open, servers are as simple as a pip
| install ... You have full control of what servers you install.
| What functions you turn on, what access you allow.
|
| Now everyone and their blog is sticking MCPs on their servers and
| locking them down behind subscriptions and paywalls.
|
| What a wasted opportunity.
| freeone3000 wrote:
| And what pays for the resources used serving your (hundreds of)
| requests against a "local" server? For computer control, sure,
| but actual remote services have actual remote costs.
| zoogeny wrote:
| > Compared to the olden days, when specs were written by pedantic
| old Unix dudes
|
| I think that is one of the reasons (among many others) that the
| semantic web failed (which doesn't contradict the author, whose
| point is literally the worse-is-better mantra).
|
| People really leaned into the eXtensible part of XML and I think
| a certain amount of fatigue set it. XSL, XHTML, XSD, WSDL, XSLT,
| RDF, RSS, et al. just became a bit too much. It was architecture
| astronautics for data formats when what the world at the time
| needed was simple interchange formats (and JSON fit the bill).
|
| But I actually believe XML's time has come. I've noticed that XML
| appears a lot in leaked system prompts from places like
| Anthropic. LLMs appear to work very well with structured text
| formats (Markdown and XML specifically).
|
| I believe that MCP is the wrong model, though. I believe we
| should be "pushing" context to the models rather than giving them
| directions on how to "pull" the context themselves.
| MrBuddyCasino wrote:
| Two years ago he would have written ,,pedantic white old Unix
| dudes".
| M4rkJW wrote:
| True, though "dudes who were never in danger of being
| gruntled" made it pretty clear who he was targeting.
| mdaniel wrote:
| > I believe we should be "pushing" context to the models rather
| than giving them directions on how to "pull" the context
| themselves.
|
| How could that possibly work for the cases that people want the
| intern to solve for them? If they knew the information ahead of
| time, presumably they'd just solve the problem by themselves
|
| I get the impression that the value folks get from MCP is "run
| some query for me, don't make me learn how to glue together 15
| sources"
| zoogeny wrote:
| I'm not sure I understand your objection. You seem to imply
| that knowing the context is the same as knowing the solution
| to the problem the context provides?
|
| Let me think of an example here. Context needed to determine
| if there is cancer in a radiology scan would be the contents
| of the scan. So there are two modes here, one I say "LLM
| please tell me if there is cancer in this patients scan" and
| the LLM makes an MCP call to load the patients report. The
| second mode is I say "LLM, here is the patients radiology
| scan, can you tell me if it has signs of cancer".
|
| The first example is what I was calling a "pull" model and
| the second example is what I am calling a "push" model.
| goncalo-r wrote:
| For a lot of office jobs, knowing the context is almost the
| same as knowing the solution to the problem at hand.
| zoogeny wrote:
| I'd be interested in examples of this. I've worked in
| offices for all of my adult life and I don't have any
| examples that come to mind.
|
| I think of logic puzzles I used to do as a kid. The whole
| idea of the puzzle is that all of the information you
| need is provided, the fun is in solving using deduction.
| Sudoku scratches the same itch.
|
| At the least, I would argue there are _many_ problems
| that don 't fit the mold you are suggesting and MCP is
| not the correct method for addressing them.
| mdaniel wrote:
| > I'd be interested in examples of this. I've worked in
| offices for all of my adult life and I don't have any
| examples that come to mind.
|
| Wow, you must have worked in some really mature shops
| then if you knew instantly which of [Google Drive,
| Confluence, Airtable, GitHub wiki, ${that one deprecated
| thing that Alice was using}, ...] contained the reference
| to Project Frazlebaz mentioned in Slack last.. day? week?
| Maybe it was today but time is a blur?
| zoogeny wrote:
| I don't know how that is solved by MCP? How would the LLM
| possibly know where to search? Just making an API (or
| series of APIs) to slack/jira/airtable available doesn't
| magically surface the context, or the right search
| incantation to reveal it. The LLM still has to figure out
| which tool to search within, what search terms/tools are
| the right ones to choose, etc. If there are a million
| documents in your set of data providers and only 1000 fit
| into the context of the LLM, that filter happens
| _somewhere_.
|
| This idea that if you don't know where the data is,
| magically the LLM will, is very confusing to me.
| ryeguy wrote:
| MCP is just function calls with parameters. Whether or not
| it's push or pull can be decided by the author. A push
| model takes the scan as an input to the mcp call. A pull
| model does the pulling within the mcp call. Neither is
| right or wrong, it's situational.
| hirsin wrote:
| The point above about enterprise glue is why this is a pull
| model.
|
| In your push model, the onus is on you to go find the scan
| from one of five backends, traverse whatever hoops of
| access are needed, and actually handle the files manually.
|
| In the pull model, each backend implements the server once,
| the LLM gets connected to each one once, and you have one
| single flow to interact with all of them.
| zoogeny wrote:
| It is interesting that the model I am proposing inverts
| many peoples expectation of how LLMs will benefit us. In
| one vision, we give a data-lake of information to LLMs,
| they tease out the relevant context and then make
| deductions.
|
| In my view, we hand craft the context and then the LLM
| makes the deductions.
|
| I guess it will come down to how important crafting the
| relevant context is for making useful deductions. In my
| experience with writing code using LLMs, the
| effectiveness increases when I very carefully select the
| context and the effectiveness goes down when I let the
| agent framework (e.g. Cursor) figure out the context. The
| ideal case is the entire project fits in the context
| window obviously, but that won't always be possible.
|
| What I've found is that LLMs struggle to ask the right
| questions. I will often ask the LLM "what other
| information can I provide you to help solve this problem"
| and I rarely get a good answer. However, if I know the
| information that will help it solve the problem and I
| provide it to the agent then it often does a good job.
| kiitos wrote:
| > In my view, we hand craft the context and then the LLM
| makes the deductions.
|
| We (as in users) provide the source material and our
| questions, the LLM provides the answers. The entire
| concept of a context is incidental complexity resulting
| from technical constraints, it's not anything that users
| should need to care about, and certainly not something
| they should need to craft themselves.
| wongarsu wrote:
| XML tags work well for LLMs. But notably the vast majority are
| just xml tags. Nobody(tm) is feeding LLMs well-formed XML with
| an xml declaration (the <?xml version="1.0" encoding="UTF-8"?>
| at the start) and we aren't using namespaces, XSLT, XML Schemas
| etc. It's just some ad-hoc collection of sgml-style tags
| zoogeny wrote:
| I've noticed that as well, but I doubt those additional
| tokens _hurt_.
|
| You can make an unholy mess with namespaces and all of the
| bells-and-whistles that XML provides, or you can not. But
| even if you just structure using <tag></tag> without any of
| the fancy stuff, you still can create pipelines that operate
| on that structured format in ways that are more powerful than
| plain text.
| jazzyjackson wrote:
| still its a format that allows for lossy transmission which I
| think meshes well with the fuzzy ingestion of llms, the
| closing tags' redundancy is a feature that helps the llm stay
| focused
| this_user wrote:
| I think the main reason that "Semantic Web" has failed is that
| basically no one can even explain what the "Semantic Web" is or
| what it's good for. It's all just a bunch of generic sounding
| buzzwords about exchanging data in some way.
| blitzar wrote:
| > the semantic web failed
|
| It failed because they couldn't figure out how to stuff ads in.
| kiitos wrote:
| > I believe we should be "pushing" context to the models rather
| than giving them directions on how to "pull" the context
| themselves.
|
| Models have very very very limited capacity for context, it's
| one of their primary bottlenecks, therefore it's important to
| optimize (minimize) that information as much as possible,
| allowing the model to pull what it decides it needs makes that
| constraint much easier to satisfy.
| zoogeny wrote:
| >what it decides it needs
|
| This is what I am suggesting: relying on the model to decide
| what it needs is maybe not the best use of the available
| context. It might be better for us to give it the information
| we are certain it will need.
| jazzyjackson wrote:
| Interesting observation. I've been kinda hyped about XML/XSLT
| lately because I was working on a JSON macro expansion language
| (just four different macro tags that replace themselves with
| the macro's expansion, #= #& #? #! assignment, substitution,
| conditional branch like cond, and call for custom functions)
| and realised I was re-inventing XSLT, but what I really wanted
| was xpath, a way to describe traversal over graphs, back and
| forth along different axes, it's actually an amazing spec. Then
| I found basex [0] which pulls arbitrary XML documents into a
| queryable database that can be have queries described in XPATH
| or XQUERY.
|
| In my mind the best way to create a reliable natural language
| interface to a dataset without hallucination would be to hand
| over XML schemas to the system prompt and have it write the
| queries to retrieve the data.
|
| [0] https://basex.org/
| th0ma5 wrote:
| The Semantic Web has yet to fully fail. Most companies have
| implemented a closed world limited version of it internally. It
| has already been proposed as a solution to correct LLM outputs
| by many people.
| nimish wrote:
| Rent seeking is the name of the game for much of b2b SaaS.
|
| MCP is an attempt to make that easy, but the issue here is that a
| lot of the companies offering integration could be
| disintermediated entirely by LLMs. Hard to say what that means.
| jacob019 wrote:
| Fun writing, and something to think about. To me, Web 2.0 is kind
| of a joke; jQuery, REST, AJAX, CSS2, RSS, single page apps were
| going to change everything overnight, it was THE buzzword, and
| then... incremental improvements. In retrospect, everything did
| change, but that loose collection of technologies was just links
| in the chain of incremental progress. So yeah, Web 2.0 2.0 makes
| sense.
|
| I've seen a lot of talk around here, and everywhere, about MCP. A
| lot of enthusiasm and a lot of criticism. I've written a few MCP
| servers and plan to write some more. It isn't how I would design
| a protocol, but it works, and everyone is using it, so hooray for
| interoperability.
|
| I think the hype represents the wider enthusiasm that people have
| about this moment in time, and the transformative power of these
| new tools. It's easy to look at MCP and say there it is, now it's
| easy to connect these tools to the things that I care about, it
| feels accessible, and there's community.
|
| MCP is NOT the new TCP for AI. It is, essentially, an RPC layer
| for chat. And while it could be extended to a wider variety of
| use cases, I expect that it will remain primarily a method for
| wiring up tool calls for user-facing use cases. We recognize the
| power of these tools and anticipate deep changes to workflows and
| systems, but we don't know how that will shake out. If I am
| writing a classifier for a backend system, I am not going to use
| MCP, even if I could. Because it's inefficient. Every additional
| tool we offer the model consumes tokens and increases latency. I
| expect that the primary user of LLMs is going to be business
| automation of all kinds, and I don't expect them to reach for MCP
| to wire things up. Yeah, it's really cool to hook tools up to the
| chat, for that to feel accessible, to know how to do things in an
| idiomatic and standards-compliant way, that feels good! And yeah,
| the hype is overblown.
| riwsky wrote:
| Don't forget tags! Tags very 2.0, none of this straitjacketed
| directory-hierarchy-only mentality.
| 1oooqooq wrote:
| I pitty the fools thinking they will have access to anything
| because there's a MCP.
|
| those things will be hidden behind a dozen layers of payment
| validation and authentication. And whitelisted IPs (v4, of
| course).
|
| ERR 402; is all that will be visible to yall.
| timwis wrote:
| Isn't conformance to a standard API arguably less necessary now
| that LLMs can read API docs and adapt? For me, the win is the
| expectation that sites _have_ an API, whether it conforms to the
| MCP spec or not.
| bilbo0s wrote:
| -API documentation may have been poorly written.
|
| -Even with good documentation, the LLM may generate incorrect
| code to interact with API. (If you fix the generated code and
| just have the LLM call that code to interact with the API, then
| you're on your way to an intermediary in any case. You're
| basically building an "MCP-like" server.)
|
| -Security or resource allocation issues when giving LLMs direct
| access to APIs. (LLM has limited knowledge of when API was last
| called. It could call too often and, if each call is expensive,
| generate surprise infrastructure bills.)
|
| -So on and so forth. Lots of other potential pain points solved
| by having _some_ thing intermediate.
|
| Should that "something" be MCP? Reasonable people can disagree
| on that. Works well enough right now to get done what people
| need done I suppose.
| no_wizard wrote:
| My hot take: MCP's value for the foreseeable future will be with
| automated testing
| foobarian wrote:
| > when specs were written by pedantic old Unix dudes
|
| I'm tickled pink that this generation imagines "old Unix dudes"
| as pedantic, when Unix was the ultimate "move fast and break
| things" rebellion against the MIT school. Some things never
| change :-)
| phillipcarter wrote:
| The thing that a lot of people miss with MCP is that it's the
| right fit for enterprise software. LLMs, being universal
| translators, are the ideal glue between many disconnected systems
| that are extremely hard to connect without some fuzzy layer in
| between. And so that's why you see so much of the B2B SaaS world
| rolling out MCP servers, and internally at these companies,
| they're talking about how to re-jigger their APIs and
| restrictions for those APIs given different usage patterns.
|
| Yes, the _protocol_ is not necessarily "enterprise ready" by
| various definitions, but as the author points out, this is not
| terribly important, and the history of standards shows us that
| even messy and "bad" things get widespread adoption because they
| hit the right notes at the right time for the right people.
| Flemlo wrote:
| We have rest and openapi.
|
| That allows already for self discovery etc.
|
| Everyone who will offer mcp offers a good API anyway.
| hirsin wrote:
| We don't need SDKs, they publish API docs.
|
| We don't need packages or functions, we can just write the
| code ourselves, every time it's needed.
|
| We don't need compilers, the computer understands assembly
| already.
|
| It's a mismatch of use - MCP isn't about telling the LLM
| about the APIs. It's also about encapsulating and simplifying
| them so the LLM isn't manually figuring them out every single
| time from scratch.
| 9dev wrote:
| OpenAPI specs provide everything the LLM needs to
| understand an API. And if it can be simplified for the LLM
| while retaining functionality, why not simplify the API
| altogether, instead of implementing yet another entry point
| into the application? Just so nobody has to sit down for
| longer than the duration of a TikTok and design their API
| properly?
| Animats wrote:
| It's a great money maker. Each data request involves a paid
| trip through an LLM. It's not like the endpoints negotiate a
| schema they can use to make cheap queries in future.
| Karrot_Kream wrote:
| MCP is just RPC over a long-lived connection, most cases being
| a Websocket. IMO RPC is easier to setup because:
|
| 1. There's less bikeshedding for the authors about whether
| modifying a field in a user object should be a PUT or a POST
| replacing the original user object. I've spent a non-trivial
| amount of time bikeshedding over REST verbs.
|
| 2. LLMs don't need to understand the REST semantics of the API.
| It can just look at available RPC methods and make the RPC call
| it thinks will work.
|
| I think that's really it.
| broost3r wrote:
| completely agree. huge enterprises are full of engineers who
| want to do amazing things from 9-5 and then sign off and forget
| about work until the next day. what kind of business wouldn't
| want to make sure they're getting the most out of their
| employees during business hours?
| vasusen wrote:
| What worries me most about MCP isn't that the protocol is so
| poorly created, but that fixing/improving it is only at the mercy
| of internal teams at Anthropic and OpenAI. It doesn't seem like
| the folks who are coming up with the protocol are actual
| engineers trying to implement it as well.
|
| Vaguely seems like a Visa-Mastercard duopoly.
| TOMDM wrote:
| Microsoft has joined the steering committee as well
|
| https://techcrunch.com/2025/05/19/github-microsoft-embrace-a...
___________________________________________________________________
(page generated 2025-05-23 23:01 UTC)