[HN Gopher] The Future of MCPs
___________________________________________________________________
The Future of MCPs
Author : tylerg
Score : 78 points
Date : 2025-04-23 17:12 UTC (5 hours ago)
(HTM) web link (iamcharliegraham.substack.com)
(TXT) w3m dump (iamcharliegraham.substack.com)
| bravetraveler wrote:
| _MCP_ in this context means _" Model Context Protocol"_
|
| I thought it might be _" managed cloud providers"_, but perhaps
| I'm too optimistic for a change
| cantrecallmypwd wrote:
| Or: Master Control Program
| freedomben wrote:
| Interesting thoughts regarding MCPs being the future App
| Store/Platform. I don't know that I agree but I don't necessarily
| disagree either. Time will certainly tell.
|
| To me, MCP feels more like an implementation detail, not
| something that most people would ever use directly. I would
| expect that the future would be some app distributed through
| existing channels, which bundles the MCP client into it, then
| uses a server-side component (run by the vendor of course) to get
| the real work done. As much as I like the idea of people
| installing the servers locally, that future seems like a Linux
| nerd/self hosted type of activity. I just can't imagine a typical
| mac or windows non-power-user installing one directly. Just the
| idea that they would need to install "two apps" is enough to
| confuse them immensely. It's possible some might bundle the
| server too and run it locally as needed, but even in that case I
| think MCP is completely invisible to the user.
| grahac wrote:
| Agree that for mainstream use it needs to be and will be hidden
| from the user entirely.
|
| Will be much more like an app store where you can see a catalog
| of the "LLM Apps" and click to enable the "Gmail" plugin or
| "Shopping.com" plugin. The MCP protocol makes this easier and
| lets the servers write it once to appear in multiple clients
| (with some caveats I'm sure).
| dist-epoch wrote:
| MCP's will be run by the service providers, and you'll have the
| ability to "link" them, just like today you can link a Google
| account to give access to Calendar, GDrive, ... in the future
| you'll be able to give a model access to the Google MCP for
| your account.
| lgiordano_notte wrote:
| i wonder how granular the permissions will get though. giving
| model-level access to something like Gmail sounds powerful,
| but also like a privacy minefield if not done carefully.
| curious to see how trust and isolation get handled.
| masterj wrote:
| MCP has a remote protocol. You don't need to install anything
| to add an MCP server, or rather, you won't once client support
| catches up to the spec. It will be a single click in whatever
| chat interface you use.
| daxfohl wrote:
| I'd expect "local MCP servers" will be generally installed as
| part of something else. Photoshop, or Outlook, or whatever
| could come with a local MCP server to allow chat clients to
| automate them. Maybe printer drivers or other hardware would do
| similar. I don't think there's much reason to install a cloud
| service MCP server to run locally; you'd just use the one
| provided in the cloud.
| mirekrusin wrote:
| More like npm, not app store.
| brap wrote:
| My prediction: there will be no standard protocol, clients will
| do whatever works for them, and devs will do whatever it takes to
| be installable on those clients. Just like mobile.
| guideamigo_com1 wrote:
| MCP might be one of the few technology pieces where more articles
| have been written about it than the actual use-cases being built.
|
| It is like the ERC20 era all over again.
| atonse wrote:
| I don't feel that way. Maybe the first examples have all been
| related to what software people do, but I think an MCP for a
| travel site would be a game changer.
|
| There are so many things I want to tell a travel site that just
| doesn't fit into filters, so then end up spending more time
| searching all kinds of permutations.
|
| These could be done with an MCP-augmented agent.
| esafak wrote:
| There is no saying that they will expose more functionality
| through the MCP API than their web site. I imagine the API
| will be more limited.
| atonse wrote:
| No, but let me be more specific.
|
| For example, when I search for flights, there might be
| situational things (like, "can you please find me a flight
| that has at least a 2 hour layover at <X> airport because
| last time i had a hard time finding the new terminal" etc.
|
| Or an agent that will actually even READ that information
| from the airport website to see notices like "expect long
| delays in the next 3 months as we renovate Terminal 3"
|
| Right?
|
| The agent could have this information, and then actually
| look at the flight arrival/departure times and actually
| filter them through.
|
| Other things like, "I can do a tuesday if cheaper, or, look
| through my calendar to see if i have any important meetings
| that day and then decide if i can pick that day to save
| $400"
|
| These are all things that synthesize multiple pieces of
| data to ultimately arrive at something as simple as a date
| filter.
| troupo wrote:
| So, Yahoo! Pipes, but with magic and wishful thinking
| leo-notte wrote:
| that kind of synthesis is where current search interfaces
| fall short. the pieces exist in isolation like flight
| data, personal calendars, and airport notices, but
| nothing ties them together in a way that's actually
| useful. an agent using MCP could help connect those dots
| if the APIs are deep enough and the UX avoids feeling
| like a black box. the real challenge might not be the
| tech but getting providers to share enough useful data
| and trust whatever sits between them and the user.
| dkersten wrote:
| People said similar things about smart contracts, yet here we
| are, with them being rather niche. I do agree that once the
| Alexa's and Siri's are LLM powered with MCP (or similar)
| support, these kinds of use cases will become more valuable
| and I do feel it will happen, and gain widespread use
| eventually. I just wonder how much other software it will
| actually replace in reality vs how much of it is hype.
| 3np wrote:
| ERC20 stood the test of time and is ubiquitous today.
|
| Who knows what MCP looks like in a decade?
| __loam wrote:
| It's very funny to see people talking about an extremely thin
| protocol like this.
| soulofmischief wrote:
| It's a matter of organizing developer effort around a set of
| standards. Good architecture makes it easy to contribute to
| the ecosystem, and currently agentic tooling is the wild
| west, with little in terms of standardization. Now we are
| seeing more developer momentum around making our everyday
| tools accessible to agents.
| spudlyo wrote:
| Remember "push technology"?
| helsinki wrote:
| Are there any open-source MCP 'app stores' currently available? I
| am considering building one for my employer. A place to host
| internally built MCPs. It would be useful to know if there is
| something already out there.
| sirius87 wrote:
| This is a registry I know of: https://smithery.ai but it's just
| a listing
|
| But any self-hosted npm registry backend (e.g. github npm
| registry) should serve as a private MCP Server registry?
| fullstackchris wrote:
| seen a lot with uvx as well (apparently a package manager for
| python, but i try to stay as far away as possible from
| python)
| gadders wrote:
| >>MCP Affiliate Shopping Engines
|
| As someone else once said, I want a Grocery Shopping Engine.
| "Here's my shopping list, taking into consideration delivery
| times and costs, please buy this for the lowest cost from any
| combination of supermarkets and deliver by day after tomorrow at
| the latest."
|
| If MCPs gave the LLMs a window into all the major supermarkets
| home shopping sites that looks like it's a step closer.
| troupo wrote:
| > If MCPs gave the LLMs a window into all the major
| supermarkets home shopping sites that looks like it's a step
| closer.
|
| And how exactly will they do that?
| fullstackchris wrote:
| Not OP but perhaps the following mcp tools: google maps api,
| nearest supermarkets, puppeteer their product listing pages?
|
| Though to be honest not sure why you would need so much info
| - if I need lettuce or tomatoes for example, I know theyre
| gonna be at essentially every supermarket in my area....
| 3np wrote:
| > Think of MCPs as standardized APIs--connectors between external
| data sources or applications and large language models (LLMs)
| like ChatGPT or Claude.
|
| This is incorrect.
|
| MCP is Model Context Protocol.
|
| You didn't "build an MCP", you implemented an MCP server.
| Lighttpd is not "an HTTP", it's an HTTP server. wget is also not
| "an HTTP", it's an HTTP client. Lighttpd and wget are different
| enough that it's useful to make that distinction clear when
| labeling them.
|
| dnsmasq is not "a DHCP", it's a DHCP server.
|
| This distinction also matters because it is certain that we will
| see further protocol iterations so we will indeed have multiple
| different MCPs that may or may not be compatible.
| helloooooooo wrote:
| I'd just like to interject for a moment. What you're refering
| to as Linux, is in fact, GNU/Linux, or as I've recently taken
| to calling it, GNU plus Linux. Linux is not an operating system
| unto itself, but rather another free component of a fully
| functioning GNU system made useful by the GNU corelibs, shell
| utilities and vital system components comprising a full OS as
| defined by POSIX.
|
| Many computer users run a modified version of the GNU system
| every day, without realizing it. Through a peculiar turn of
| events, the version of GNU which is widely used today is often
| called Linux, and many of its users are not aware that it is
| basically the GNU system, developed by the GNU Project.
|
| There really is a Linux, and these people are using it, but it
| is just a part of the system they use. Linux is the kernel: the
| program in the system that allocates the machine's resources to
| the other programs that you run. The kernel is an essential
| part of an operating system, but useless by itself; it can only
| function in the context of a complete operating system. Linux
| is normally used in combination with the GNU operating system:
| the whole system is basically GNU with Linux added, or
| GNU/Linux. All the so-called Linux distributions are really
| distributions of GNU/Linux!
| esseph wrote:
| Hey look I found the individual willing to die on the "ATM
| Machine" / "NIC card" hill!
| hinkley wrote:
| "The map is not the territory."
| happyopossum wrote:
| > You didn't "build an MCP"
|
| The author explicitly states he built 2 MCP _servers_ , not 2
| MCPs, so I don't know where your beef is coming from
| nilslice wrote:
| we've been building most of what OP has written about with
| https://mcp.run
|
| We started doing this the day Anthropic released MCP in November
| last year. Our company has always been devoted to secure plug-in
| system technology having built Extism, a WebAssembly plugin
| framework.
|
| We immediately saw MCP as the plugin system for AI and knew it
| would be significant, but were concerned about the security
| implications of running MCP servers from untrusted parties and
| using the STDIO transport which makes user systems vulnerable in
| ways we weren't ok with.
|
| So we built mcp.run which is a secure implementation of the
| protocol, running servers in fully isolated & portable wasm
| modules. They must be allow-listed to access files & network
| hosts, and cannot access any part of your system without your
| explicit permission.
|
| They also run everywhere. Each server (we call them servlets) on
| mcp.run is automatically available via SSE (soon HTTP streaming)
| as well as STDIO, but can also be embedded directly into your AI
| apps, no transport needed, and can run natively on mobile!
|
| We are excited about MCP and glad so many are too - but we really
| need more security-oriented implementations before it's too late
| and someone suffers a seriously bad exploit - which could tarnish
| the ecosystem for everyone.
| pbronez wrote:
| Cool platform. I got some errors while exploring your website.
| Searching for tools to use works on mobile but not on desktop
| for some reason.
| nilslice wrote:
| we just had a minor outage -- sorry about that. It should be
| fully back online.
| kaycebasques wrote:
| If you're sold on MCP, what was your "wow" moment? I've read the
| docs and tinkered a bit but it was a decidedly "meh" experience
| personally. It seems very similar to ChatGPT Plugins, and that
| was a flop. I don't really like the fuzzy nature of the
| architecture, where I never know what server will be invoked. And
| I have to manually opt-in to each server I want to use? To be
| unexpectedly useful, it seems like I would have to opt-in to tens
| or hundreds of servers. Yet I've heard that clients start to
| struggle once you have more than 20 servers plugged in...? Please
| excuse any fundamental errors I've repeated here, if any...
| jaapbadlands wrote:
| The first use case I found relevant and useful was the Supabase
| MCP server, allowing Cursor's agent to query my Supabase
| project. It meant no longer describing my database to Cursor,
| it could simply go and get the information it needed, as
| needed.
| bluedevil2k wrote:
| Writing an internal MCP server to link our API layer to
| Augment/VSCode so that our Frontend developers can ask in
| plaintalk about API details. With over 1000 endpoints, it lets
| the devs find the endpoint, and more importantly the GQL
| fields, quickly. After some dogfooding we plan to open it up to
| our clients as well.
| mwigdahl wrote:
| My "wow" moment was when I wrote an internal MCP server so that
| Claude Code could access our test databases. It was a tiny
| amount of code, simple to connect up, and immediately gave
| Claude Code a way to directly validate queries. It's been
| useful in numerous scenarios since then and got me thinking
| about additional MCP-based tools it might be nice to have.
| grahac wrote:
| Yep. It is currently a Meh experience as said in the OP because
| the UX sucks. The idea is take a step back and imagine what
| could it become if those are fixed.
|
| Btw, one of my favorite MCPs is a Whois MCP so I can ask Claude
| Desktop to brainstorm domain names and then immediately check
| if they are available :).
|
| It's clunky but I am still using it :)
| cruffle_duffle wrote:
| Wrote an MCP to hook into my logging so I could get Claude +
| Cursor to quickly answer "hey, why did request 20394 from
| yesterday evening fuck up?". It goes into the logs and finds
| the exception, hunts down the line and then tells me whats up.
| Of course, left unchecked it tries to fix the problem too but
| I've spent countless lines of prompt engineering to have it
| never attempt to "just start writing code".
| fullstackchris wrote:
| For me it was implementing a simple `execute_terminal_command`
| tool along with hooking up to my company's jira and gitlab
| (dont worry security gurus, for the command line, I have a
| hardcoded list of allowed read-only commands that the LLM can
| execute, and both jira and gitlab servers likewise have
| readonly options.)
|
| What I will say is I agree there should be an option to get rid
| of the chat confirmations of every single new tool call in a
| chat - as well as building a set of "profiles" of different
| tools depending what I'm working on. Also strongly agree there
| needs to be an internal prompt possibility to explicitely tell
| the LLM what tool(s) to favor and how to use them (even in
| addition to the descriptions / schemas of the tools themselves)
| I opened an issue on the anthropic repo exactly about this:
| https://github.com/modelcontextprotocol/typescript-sdk/issue...
| kristjank wrote:
| MCPs tries too hard to signal XHR for AI, but nobody wants to
| earnestly deal with the consequences of AI interfacing in a wider
| context of mis-/disinformation, hallucination and generally
| letting _it_ talk to stuff in a semi-unprompted manner.
| ehtai wrote:
| It doesn't look like the user came across FastMCP. This library
| sped up my development of MCP servers substantially. The
| OpenAPI2MCP pattern looks extremely promising
| https://gofastmcp.com/patterns/openapi
___________________________________________________________________
(page generated 2025-04-23 23:00 UTC)