← Back to context

Comment by freedomben

1 day ago

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.

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.

  • Interesting thought.

    But maybe the companies would actually like to at least pipe the communication throught the cloud to get all the usage data. Here's one possible architecture:

    local chat client

      - talks to cloud LLM
      - talks to local MCP servers
    

    local MCP server provided by company

      - connects to company cloud (this lets the company collect usage data)
      - forwards tasks to the cloud
    

    local tool (for example photoshop)

      - connects to company cloud to get a users tasks
      - executes the tasks (this lets the company use the users hardware, saving cloud costs)

    • Hmm, in that example the MCP server is just a thin api wrapper though, so it wouldn't change anything by running locally, right? Like I could see where maybe a TikTok MCP server would benefit from running locally since that would allow it to expose a camera api, but I can't think of anything you could do with a local Airbnb MCP server that you couldn't do with a cloud one.

      Nefariously, I guess since these things would be running in the background continuously, that would provide another avenue for companies to spy on you, so that may be a reason companies create local mcps even if there's no other reason to.

      1 reply →

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).

  • They feel quite similar to Alexa skills, packaged in a standard form. The app store analogy allows them to be searched by the end user.

    TBH, it's quite surprising (and reassuring) that they have standardised as MCPs so soon. It normally takes a decade of walled gardens and proprietary formats before any open standards emerge.

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.

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.

  • 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.

    • Those oauth permission dialogs come to mind but they may need to improve significantly to become useful.

      I don't think most of those are granular enough.