[HN Gopher] MCP: An (Accidentally) Universal Plugin System
___________________________________________________________________
MCP: An (Accidentally) Universal Plugin System
Author : azhenley
Score : 150 points
Date : 2025-08-10 12:53 UTC (10 hours ago)
(HTM) web link (worksonmymachine.ai)
(TXT) w3m dump (worksonmymachine.ai)
| cranberryturkey wrote:
| checkout my MCP server platform:
| https://github.com/profullstack/mcp-server
|
| I built it and have added several modules, but I'm always looking
| for people to add more modules. See ./mcp_modules in the root
| folder.
| fxwin wrote:
| I'll be honest i read your repository's README.md and still
| have no idea what this is supposed to be. The tagline sounds
| like it's for implementing MCP servers, but the endpoints
| specified further down aren't part of MCP but something more
| specific (to MCPs serving a language model? Why would we serve
| them like that?)
|
| Also doesn't really seem to relate to the OP beside the term
| 'MCP' in the title
| cranberryturkey wrote:
| It's a framework for building mcp servers.
| fxwin wrote:
| Then the "Examples" section should include a "How to build
| a simple MCP server using this framework" section. Instead,
| it contains an example for an "MCP client" (however the
| implementation has little to do with what the MCP spec says
| a client does), and an "example of a custom module for the
| MCP server" (which MCP server? we haven't built one yet),
| which (after checking implementation) does not conform to
| the MCP spec for tools (see https://modelcontextprotocol.io
| /specification/2025-06-18/ser...).
|
| Unless I'm missing something, this has very little to
| nothing to do with MCP.
| cranberryturkey wrote:
| I implemented some changes, it works now. you can test it
| out at https://mcp.profullstack.com
| eitland wrote:
| How long before companies start closing this "loophole"?
|
| And with the cynicism out of the way, what an insightful and
| refreshing article!
| ecocentrik wrote:
| If MPC develops as an open standard and this "loophole" gains
| enough popularity, then companies can only really limit access
| to their services. This seems like a generally good thing that
| will enhance automation. In some cases it doesn't really matter
| if the automation comes from agents, hard coded software or a
| combination of the two.
| cube00 wrote:
| I wouldn't call it cynicism.
|
| Web services started as the same open utopia. Once everyone was
| in they jacked up the prices so high it killed the initial
| consumer apps (eg. Google Maps and Reddit)
|
| Nobody is giving access to their walled garden for the good of
| open-anything. It's what the VCs and stockholders demand and
| they're the ones putting up the cash to keep this AI hype
| funded in spite of it running at a loss.
|
| Given they haven't put security into MCP yet, I guess they'll
| need to do that first before they move on reinventing API keys
| so they can charge for access and hailing that as the next
| reason the line will go up.
| dragonwriter wrote:
| Some remote MCPs will get locked down to know client endpoints,
| same as any other HTTP service, so if companies are really
| concerned about them being AI-use-only and don't mind cutting
| off some AI use to preserve that exclusivity, they'll lock it
| down to the big known hosted AI frontends (assuming those end
| up supporting MCP; the only one I know of that does currently
| is ChatGPT Deep Research, and only for very limited shapes of
| servers.)
|
| OTOH, that only effects those services, it won't stop people
| from leveraging MCP as, say, a generic local plugin model for
| non-AI apps.
| shredprez wrote:
| Has anyone tried Basement's typed xmcp framework [1]? I rolled my
| own mcp server implementation earlier this summer and it works
| but it's very basic.
|
| I'm considering migrating, but time is limited and I'd love to
| avoid a dead-end if I can :p
|
| [1] https://github.com/basementstudio/xmcp
| behnamoh wrote:
| Is it just me who absolutely hates this much hype around AI while
| still getting value from AI models? I get it, MCP is useful, but
| it's neither new nor safe and well thought-out. It feels like
| everyone now has to write a mandatory MCP article...
| cube00 wrote:
| > It feels like everyone now has to write a mandatory MCP
| article...
|
| Like this one you can bet every blogspam article is also trying
| to push something...
|
| > The Part Where I Tell You I'm Building Something
| 827a wrote:
| > MCP thinks it's for giving context to AI models. But really?
| It's just a really good protocol for making things talk to other
| things.
|
| MCP has very little utility outside of LLMs. The article begins
| by saying "but what if we remove the AI", then goes back on that
| thesis by saying "but if there was an AI between these things,
| then it becomes a universal plugin system". Which is true, but
| its missing the critical bit: The AI itself is the universal
| plugin system, not MCP. And, beyond that, its not even the AI:
| Its natural language. Language is the universal plugin system.
|
| Its not unbelievable that there exists an alternate reality where
| the Anthropic researchers that invented MCP instead simply
| leveraged a slightly extended form of OpenAPI specs. The only
| functional difference is that MCP was a stdin/stdout format
| first, and added HTTPS later, but sister problems in this domain
| like LSP just skipped stdin/stdout and went straight to locally-
| hosted HTTPS anyway. What matters isn't MCP, OpenAPI, or anything
| like that; what matters is the LLM itself, its tool calling
| capability, and the tool calling harness. The catalogue of
| available tools can be in any format; and, truly, the LLM does
| not care what format its in.
| ethan_smith wrote:
| MCP's key innovation isn't the format but its unidirectional,
| stateless design pattern that makes it fundamentally easier to
| implement than bidirectional protocols like OpenAPI, which is
| why it's gaining traction as a universal connector beyond just
| LLM contexts.
| 827a wrote:
| I really don't know where you're coming from with that
| statement.
|
| 1. No one asserted that MCP's key innovation was its format.
| In fact, what I strongly, almost explicitly implied with my
| previous comment is that MCP has made no key innovations
| beyond its marketing system (which does matter and has forced
| a lot of companies who would never have operated in this
| space to make an MCP system, and that is good. I like MCP.).
|
| 2. MCP is fundamentally bidirectional, not unidirectional.
| Its a schematized request-response protocol that defines a
| ton of the same primitives that OpenAPI defines, like
| available RPC methods, authorization, request parameters, and
| response schemas [1]. Of course, OpenAPI goes beyond that
| into HTTP-specific characteristics like status codes, and MCP
| goes beyond that into LLM-specific characteristics like a
| prompt catalogue.
|
| 3. I'm not aware of any problem domain outside of LLMs that
| is adopting MCP. In fact, its adoption even within the world
| of LLMs has been lackluster at best [2].
|
| [1] https://modelcontextprotocol.io/docs/learn/architecture#d
| ata...
|
| [2] https://modelcontextprotocol.io/clients
| radixdiaboli wrote:
| > but if there was an AI between these things, then it becomes
| a universal plugin system
|
| I've reread the article a couple times and I can't see where it
| says that you need to use an LLM to make it universal. I'm
| going to go so far as to say that it _doesn 't_ say that.
| 827a wrote:
| I agree, the article does explicitly say that; the thesis of
| the article and the information it presents to support that
| thesis are entirely at odds. That's what I'd argue this is a
| poor article, just an advertisement for the world's eighty-
| sixth todo app; yet it keeps getting re-posted here.
| moduspol wrote:
| And even then: the key value of MCP is that it's "simplified."
| Few servers are implementing anything you couldn't already do
| for years with their REST APIs.
|
| And why? Because it dumbs it down to the point that the LLM can
| understand it (often, in part, by removing security concerns).
| But these are LLMs! They're supposed to be smart! Isn't it a
| supposedly temporary failure that I can't just point the LLM at
| an OpenAPI spec (or use HATEOAS) and be good to go?
|
| Will this be doable in the next few months with better models?
| If so, why bother with MCP? If this won't be doable in the next
| few months / years, then how smart do we really expect these
| LLMs to be?
| 827a wrote:
| I think that's an extreme characterization. Existing AIs are
| intelligent enough to be able to form immediately executable
| API requests based on the content of an OpenAPI schema.
| OpenAPI defines everything they need; endpoint names, human
| descriptions, arguments, authorization, etc. With proper
| prompting and a well designed harness, which MCP also needs,
| it would have solved the problem. Conversely: MCP doesn't
| really have much over OpenAPI in the domain of helping LLMs
| identify which tools to call; it has tool names, tool
| descriptions, input parameters, and that's basically it.
| OpenAPI has all that.
|
| The reason why MCP was invented is hard to reverse-engineer,
| but from what I've seen I suspect its mostly: it was
| stdio/stdout first, and there isn't really a great standard
| like OpenAPI in the local-first stdio/stdout world.
| Interesting, LSP (Microsoft) took the opposite approach;
| despite having far less reason to be hosted on the web, LSP
| is just localhost http calls. MCP could have done that, but
| they didn't, without good reason, which leads me to the
| second reason why I suspect it was invented: they didn't
| know, and thus couldn't learn from prior art that they didn't
| know. Most of these AI labs are not rigorous engineering
| shops, they're better characterized as: a bunch of kids with
| infinite money trying to reignite the spirit of the early
| internet startup boom. Many believe that what they're
| building will replace everything, so why even try to build on
| what already exists?
|
| But why it was invented doesn't matter, because anyone can
| invent anything. The reason why MCP has gotten _popular_ is
| because its AI. That 's it. Its a marketing and SEO system
| that enables companies who are otherwise struggling to find a
| way to prioritize AI use-cases for their apps to say "look,
| we're AI now". You don't get the same market impact if all
| you need is that boring old OpenAPI schema you already have.
|
| And again: I like MCP. What I stated sounds pessimistic, but
| its only intended to be realistic. There is almost zero
| technical reason for MCP to exist beyond that.
| dragonwriter wrote:
| > then goes back on that thesis by saying "but if there was an
| AI between these things, then it becomes a universal plugin
| system".
|
| This is neither an accurate quote of the article, nor an
| accurate paraphrase of something the article says, nor an
| accurate description of something subtly implied by the article
| without directly being said.
|
| The article, in fact, gives an example without AI in the
| middle.
| do_anh_tu wrote:
| I think MCP is awesome, mainly because it forces devs to design
| the simplest possible tools/APIs/functions so even an average-
| performance LLM can use them correctly to get things done.
|
| As developers, we often want everything to be rich, verbose, and
| customizable -- but the reality is that for most users (and now
| for AIs acting on their behalf), simplicity wins every time. It's
| like designing a great UI: the fewer ways you can get lost, the
| more people (or models) can actually use it productively.
|
| If MCP ends up nudging the ecosystem toward small, well-defined,
| composable capabilities, that's a win far beyond just "AI
| integration."
| nlawalker wrote:
| Totally agree - the true source of all of the value here is the
| new incentive to write very simple services with very simple
| documentation and to make that documentation easily
| discoverable.
|
| It fills a gap that exists in most service documentation: an
| easily discoverable page for developers (specifically, those
| who already know how to use their ecosystem of choice's HTTP
| APIs) that has a very short list of the service's most
| fundamental functionality with a simplified specification _so
| they can go and play around with it_.
| brookst wrote:
| I don't like MCP because it relies on good faith from the
| plugin provider. It works great in closed, trusted environments
| but it cannot scale across trust boundaries.
|
| It just begs for spam and fraud, with badly-behaving services
| advertising lowest-cost, highest-quality, totally amazing
| services. It feels like the web circa 1995... lots of implicit
| trust that isn't sustainable.
| croes wrote:
| Too bad that the S in MCP stands for security
| giantrobot wrote:
| I love that MCP servers are rediscovering the old idea of public
| web APIs mash-ups from the early days of Web 2.0. Of course we
| don't need any icky XML with its namespace and schemas. Just some
| vibe-heavy JSON.
|
| Snark aside it's, autonomous agents were one of the more
| interesting justifications for web APIs back in the day. I don't
| think people necessarily envisioned LLMs but _some_ sort of agent
| you could send off to grab data or book flights or whatever.
| Specs like WSDL do what MCP does today letting the autonomous
| system figure out how to use a service.
|
| Oh well, schemas and the ability to do browser-native style
| transforms were lame! Lets transition to YAML so no one can say
| "no" to Norway.
| turlockmike wrote:
| MCP is just JSON rpc with one useful command (list-tools). Turns
| out that's probably all we ever needed.
| derwiki wrote:
| WSDL has entered the chat
| crazygringo wrote:
| Previous discussion (43 days ago, 355 comments):
|
| https://news.ycombinator.com/item?id=44404905
| _pdp_ wrote:
| The way the function is described to the LLM matter. Even when
| the parameters are the same and the effect is the same the title
| and description can fundamentally influence how the task is
| performed.
|
| The other issue is that you cannot think of MCP servers as
| universal pluggable systems that can fit into every use-case with
| minimal wrapping. Real world scenarios require pulling a lot of
| tricks. Caching can be done at higher or lower level depending on
| the use-case. Communication of different information from the MCP
| server also is different depending on the use-case (should we
| replace these long IDs for shorter IDs that are automatically
| translated to longer ones). Should we automatically tinyurl all
| the links to reduce hallucination? Which operations can be
| effectively solved with pure algorithms (compress 2-3 operations
| into one) because doing this with LLMs is not only error-prone
| but also not optimal (imagine using LLM to grep for strings in
| many files one by one using tool calls rather than using grep to
| search for strings - not the same)
|
| There are so many things to consider. MCP is nice abstraction but
| it is not a silver bullet.
|
| Speaking from experience with actual customers and real use-case.
| pjmlp wrote:
| Everyone keeps rediscovering OS IPC extensions via RPC.
|
| Not only that, apparently we finally got Jini and Agent Tcl back!
|
| https://www.usenix.org/conference/fourth-annual-usenix-tcltk...
|
| https://www.eetimes.com/jini-basics-interrelating-with-java/
| gtirloni wrote:
| Relevant: https://news.ycombinator.com/item?id=44846871
| nnnnico wrote:
| how does this hypeblog spam keep getting to the top?
| th0ma5 wrote:
| This community has no ability to separate researched
| information from conjecture, and especially on this topic since
| neural nets are a black box where we can never know if any
| behavior is fully intentional or not.
| arrowsmith wrote:
| People don't read the article, they just comment based on the
| title. In that respect HN is no different from Reddit.
| sexyman48 wrote:
| _I 'm a well-designed hole. Put something here._
|
| You asked for it.
| cowmix wrote:
| I'm just getting into MCP (building my own server and trying some
| canned ones), and one thing I've noticed -- some servers seem to
| devour your context window before you've even typed a single
| token / question.
|
| My favorite example is the public Atlassian one --
| https://www.atlassian.com/blog/announcements/remote-mcp-serv...
|
| Even with Claude or Gemini CLI (both with generous limits), I run
| out of context and resources fast.
|
| With local LLMs via LM Studio? Forget it -- almost any model will
| tap out before I can get even a simple question in.
| jjani wrote:
| Love how the MCPs mimic the company they represent in that
| sense.
| cowmix wrote:
| Heh.. this comment made my day.
| catlifeonmars wrote:
| Conway's law in action?
| markerz wrote:
| MCPs are the most basic solution possible. Shoving the tool
| definitions into a vector store and having a subagent search
| for relevant tools, then another subagent to run the tools
| would greatly reduce impact on context. I think it'd work in
| theory, but it's so annoying to have to do something like this.
| We're still in a world where we have some building blocks
| rather than full fledged toolboxes.
| dragonwriter wrote:
| > MCPs are the most basic solution possible. Shoving the tool
| definitions into a vector store and having a subagent search
| for relevant tools, then another subagent to run the tools
| would greatly reduce impact on context.
|
| That's a toolchain design approach that is independent of
| MCPs. A toolchain using MCP could do that and there would be
| no need for any special support in the protocol.
| dragonwriter wrote:
| Most UIs currently are unsophisticated and let you turn on or
| off the tools on server-by-server basis. For some large servers
| (especially if they act as aggrgeators) this approach isn't
| going to be desirable and you are going to want to select
| individual tools to activate, not servers. But that's a UI
| issue more than a protocol issue.
| jngiam1 wrote:
| We've been thinking that an intermediate (virtual) server
| layer might be helpful here. Actively working on something to
| solve that now and looking for feedback, please reach out if
| interested.
| jameshart wrote:
| There's very little actual engineering going in to designing
| MCP interfaces to actually efficiently work with the way LLM
| workflows actually operate. Many MCPs offer tools that allow an
| LLM to retrieve a list of 'things that exist' with the
| expectation the LLM will then pick something out of that list
| for further action with a different tool. There's very little
| evidence that LLMs are actually good at using tools that work
| like that, and massive lists of 'things that exist' eat tokens
| and context.
|
| Many businesses are rushing to put out _something that fits the
| MCP standard_ but not taking the time to produce _something
| that lets an LLM achieve things with their tool_.
| whattheheckheck wrote:
| All new models are probably trained to understand the tool
| use paradigm
| jameshart wrote:
| They're trained in using tools that take actions (like
| sending an email) and tools that retrieve information (like
| pulling down a Wikipedia article), yes. The specific
| pattern I see in a lot of SaaS MCPs though is _tools for
| traversing a database_ which is not really either of those
| things.
| ncallaway wrote:
| > Many businesses are rushing to put out something that fits
| the MCP standard but not taking the time to produce something
| that lets an LLM achieve things with their tool
|
| I think they'll have a while where they can get away with
| this approach too. For a good while, most people will
| probably blame the AI or the model if it doesn't use
| Atlassian tools well. It'll probably be quite some time
| before people start to notice that Atlassian specifically
| doesn't work well, but the almost all their other tools do.
|
| (More technical users might notice sooner--obviously, given
| the context of this thread--but I mean enough of a broader
| user base noticing to have reputational impact)
| britannio wrote:
| I discovered the "Layered Tool Pattern" a few days ago which
| exposes three tools to discover and execute an arbitrary number
| of service endpoints. https://engineering.block.xyz/blog/build-
| mcp-tools-like-ogre...
| Alex_L_Wood wrote:
| The more I look into MCP, the less I understand the hype. It's an
| OK API that describes how to fetch list of tools and resources
| and retrieve them, somehow this is supposed to be the standard
| for AI and environment communication, and...that's it? Am I
| missing something vital there?
| baobun wrote:
| The emperor is indeed naked.
| belter wrote:
| MCP "universal plugin system" claims are oversold. It is really
| just a standardized tool calling for AI agents. If you are not
| building agents that need to dynamically discover and choose
| tools, traditional APIs are simpler and better.
|
| The "system integration" benefits only matter when you have an
| LLM in the loop making decisions about which tools to use.
| theusus wrote:
| MCP has barely given me satisfactory results. LLMs just keep
| fighting with it and fill up a lot of their context.
| dragonwriter wrote:
| > MCP has barely given me satisfactory results.
|
| It's done a good job for me with the tools I've written and
| connected to LM Studio. I suspect the issue with whether you
| get satisfactory results is less about MCP _qua_ MCP and more
| about particular servers and tools.
| ricardobeat wrote:
| Made a similar comment [1] a while back. Universal, open APIs
| might be one of the best things to come out of this AI wave.
|
| [1] https://news.ycombinator.com/item?id=44405187
| CobrastanJorji wrote:
| This is Web 2.0. You're in the process of rediscovering mashups.
| Before it was SOAP and REST/HTTP and now it's...well, it's still
| kind of REST/HTTP because MCP is JSON-RPC. There was this brief,
| beautiful period where every "learn to code" book ended with a
| couple of chapters of how to make your app do google searches and
| throw the results into a word graph or something before all the
| big tech companies locked that sort of access down.
|
| Weirdly, I'm a little optimistic that it might work this time. AI
| is hot, which means that suddenly we don't care about IP anymore,
| and if AIs are the ones that are mostly using this protocol,
| providers will perhaps be in less of a rush to block everybody
| from doing cool things.
| torginus wrote:
| _They_ don 't care about using _your_ IP rights, I doubt it
| also works the other way around.
| fmbb wrote:
| Web 2.0 was also hot.
| madrox wrote:
| You're totally right, and that's why I think this era will
| fail.
|
| Web 2.0 failed because eventually people realized to make money
| they needed to serve ads, and to do that they needed to own the
| UI. Making it easy to exfiltrate data meant switching cost was
| low, too. Can't have that when you're trying to squeeze value
| out of users. Look at the evolution of the twitter API over the
| 2.0 era. That was entirely motivated by Twitter's desperate
| need to make money through ads.
|
| Only way we avoid that future is if we figure out new business
| models, but I doubt that will happen. Ads are too lucrative and
| people too resistant to pay for things.
| calvinmorrison wrote:
| why cant i serve ads thru my mcp?
| vineyardmike wrote:
| Obviously it's possible. And just like the early internet
| ad networks...
|
| You can't guarantee they'll be shown and interpreted
| correct by the downstream LLM, you can't guarantee
| attribution later when a user makes a purchase, you can't
| collect (as much) data on users for targeting, etc
|
| The biggest ad networks today (Google, Meta) have strong
| first party data operations, strong first party attribution
| techniques, and strong targeting, either through intent
| (search) or profiles (meta).
|
| MCP originated ads really only threaten Google (via intent
| based ads), and they're quickly moving I to owning the UX
| of LLMs, securing their place in this value chain.
| jes5199 wrote:
| ads really aren't all that lucrative, though, they're just
| simple. I worked for a company that was trying to figure out
| an alternative to ad revenue (we failed) and our people did
| some research and the average internet user ends up being
| shown (if I remember correctly) like $60/month of ads, total.
| xp84 wrote:
| That's not surprising and is also so depressing. Imagine
| what the Internet would be like if there were zero ads and
| zero of the dark patterns that they essentially force every
| web site operator to engage in. And all for sixty measly
| bucks a month that we'd spend in microtransactions or
| subscriptions or whatever. :(
| eastbound wrote:
| It's an average, you can't just charge everyone in the
| world and have an ad-free worldwide internet. About 2
| billion of internet users are probably worth 0.60$ pm
| while 200m are worth 600$ of ads pm.
| im3w1l wrote:
| People are willing to pay for AI. Some of this money flow
| could be diverted to the MCP provider.
| jfim wrote:
| In practice it'll just mean that each MCP provider will
| have API tokens and it'll be even harder to lock down
| spending than AWS. Maybe companies will need to have a
| company wide system prompt to pretty please don't use the
| expensive APIs too much.
| 1659447091 wrote:
| Did you mean this is Web 3.0? (semantic web)
|
| Where the goal was to have a site's data as machine readable so
| that could be mashed up into something new? Instead of making
| it easier to gather the big sites locked the bulk of their data
| down so it never gained widespread adoption
|
| Web 2.0 is what we mostly have now -- social, user generated
| content and interaction
| xp84 wrote:
| I think 3.0 as a term was taken over by those weird crypto
| guys with their alternative dns roots and suffixes, that
| literally no one uses. "Own your domain forever!!*"
|
| * Disclaimer: domain not usable for any purposes except on
| computers where you have root to install their alternative
| resolver
| wnevets wrote:
| > I think 3.0 as a term was taken over by those weird
| crypto guys
|
| that is certainly what I think of when web 3 is mentioned.
| baobun wrote:
| Unfortunately (?) there are no real semantics in MCP so it
| falls short of Semantic Web.
| 1659447091 wrote:
| Yes, but not in intent. Semantic Web (which was web 3.0
| before it got meshed into web3 apparently) was meant to
| open up internet data for new/novel applications and uses.
| The article appears to be alluding to that very thing via
| MCP.
|
| While it does fall short of the implementation of the
| Semantic Web, in a way it makes it a possibility to fulfill
| its intent without the full buy-in of site owners. There
| still has to be some buy-in or allowance, otherwise it will
| be locked down in the near future as some comments are
| expecting.
| firasd wrote:
| I've been doing some really fun things with MCP
|
| First of all I think this kind of localhost/stdio MCP is kind of
| not 'The Way' besides for playing around. I've been working on
| SSE/remote/cloud-based MCP
|
| Here's a fun example:
| https://x.com/firasd/status/1945233853414826060
|
| ("my landing page is in a text editor with iframe preview. I ask
| Claude to edit it--the doc gets transcluded into the AI chat,
| gets surgically edited. I reload. (All on mobile!)")
|
| I'm working on a starter template like a DevTools MCP that people
| can deploy on Cloudflare and oAuth with their github account and
| it provides tools like url_fetch for people to use privately in
| their AI chats/tools. First I have to figure out the oAuth stuff
| myself but will make it a public repo after that and post on here
|
| PS. I also think tool use is really underrated and stuff like MCP
| unlocks a kind of agentic behavior 99% of AI users have never
| seen.
| stevenhuang wrote:
| Accidentally? Generic interoperability was the whole point of
| mcp, it was not an accident.
| revskill wrote:
| There's nothing about "model" in MCP at all, they're just json
| rpc ?
| Stwerner wrote:
| Yep, and the primary transport method is json rpc over stdio
| dragonwriter wrote:
| The "model context" in MCP refers to the motivating application
| domain (the resources, tool responses, and prompts it provides
| all, in that use case, are used to populate the model's
| context), not the content of the protocol.
| russellbeattie wrote:
| > _" Your car doesn't care if you're charging a phone or running
| a personal pizza oven. The hole is the same size. The power is
| there."_
|
| This is an inadvertently great and amusing analogy, because it
| shows how people can assume something about an API's capabilities
| without actually trying it.
|
| A 12V battery car battery can't power a pizza oven. It can barely
| boil water in a special rice cooker - very very slowly. And it
| risks depleting the battery and not being able to start your car.
|
| Like a new API, people get excited about what it can do, but the
| reality is very different.
|
| I have a portable fan with a power bank that charges over USB
| with a USB-micro plug. For some reason I can't fathom, it's an
| absolute power hog. I've killed my van's battery using it for
| just a few hours. (In theory it should be using at max 2.5W, but
| that's not the point).
|
| Again, that shows how trying to extend an APIs design can have
| unexpected side effects which tax the system in ways that are
| hard to predict.
|
| MCP has a lot of excitement around it now, but it will inevitably
| reach its limits. The lesson is to test your system under load
| before assuming anything.
___________________________________________________________________
(page generated 2025-08-10 23:01 UTC)