To really understand MCP you need to think about application design in a different way.

In traditional applications, you know at design-time which functionality will end up in the final product. For example, you might bundle AI tools into the application (e.g. by providing JSON schemas manually). Once you finish coding, you ship the application. Design-time is where most developers are operating in, and it's not where MCP excels. Yes, you can add tools via MCP servers at design-time, but you can also include them manually through JSON schemas and code (giving you more control because you're not restricted by the abstractions that MCP imposes).

MCP-native applications on the other hand can be shipped, and then the users can add tools to the application — at runtime. In other words, at design-time you don't know which tools your users will add (similar to how browser developers don't know which websites users will visit at runtime). This concept — combined with the fact that AI generalizes so well — makes designing this kind of application extremely fascinating, because you're constantly thinking about how users might end up enhancing your application as it runs.

As of today, the vast majority of developers aren't building applications of this kind, which is why there's confusion.

This a good characterisation of functionality MCP might enable. Thanks.

In your opinion, what percentage of apps might benefit from this model where end users bring their own MCP tools to extend the capabilities of your app. What are some good examples of this - e.g., a development tool like Cursor, WindSurf likely apply, but are there others, preferable with end users?

How is the user incentivized to upskill towards finding the right tool to "bring in", installing it and then using it to solve their problem.

How do we think about about the implications of bring your own tools, knowing that unlike plugin based systems (e.g,. Chrome/extensions), MCP servers can be unconstrained in behaviour - all running within your app

> In your opinion, what percentage of apps might benefit from this model where end users bring their own MCP tools to extend the capabilities of your app.

Long term close to 100%. Basically all long-running, user-facing applications. I'm looking through my dock right now and I can imagine using AI tools in almost all of them. The email client could access Slack and Google Drive before drafting a reply, Linear could access Git, Email and Slack in an intelligent manner and so on. For Spotify I'm struggling right now, but I'm sure there'll soon be some kind of Shazam MCP server you can hum some tunes into.

> How is the user incentivized to upskill towards finding the right tool to "bring in", installing it and then using it to solve their problem.

This will be done automatically. There will be registries that LLMs will be able to look through. You just ask the LLM nicely to add a tool, it then looks one up and asks you for confirmation. Running servers locally is an issue right now because local deployment is non-trivial, but this could be solved via something like WASM.

> How do we think about about the implications of bring your own tools, knowing that unlike plugin based systems (e.g,. Chrome/extensions), MCP servers can be unconstrained in behaviour - all running within your app

There are actually 3 different security issues here.

#1 is related to the code the MCP server is running, i.e. the tools themselves. When running MCP servers remotely this obviously won't be an issue, when running locally I hope WASM can solve this.

#2 is that MCP servers might be able to extract sensitive information via tool call arguments. Client applications should thus ask for confirmation for every tool call. This is the hardest to solve because in practice, people won't bother checking.

#3 is that client applications might be able to extract sensitive information from local servers via tool results (or resources). Since the user has to set up local servers themselves right now, this is not a huge issue now. Once LLMs set them up, they will need to ask for confirmation.

> local deployment is non-trivial, but this could be solved via something like WASM.

This is why I started working on hyper-mcp which use WASM for plugin development & OCI registry for hosting. You can write Dockerfile for plugin packaging

You develop plugins in any language you want as long as it supports WASM

https://github.com/tuananh/hyper-mcp

I can’t express how much I agree with your perspective. It’s a completely different/total shift in how we might deliver functionality and… composability to users.

Well said.

Oh, it’s the new HATEOAS? A pluggable framework for automatic discoverability of HTTP APIs is incredibly useful, and not just for AI :)

No, you can't understand it until you understand that the world isn't all webshit and not everything is best used via REST.

(Not even webshit is best used by REST, as evidenced by approximately every "REST" API out there, designed as RPC over HTTP pretending it's not.)

Nevertheless, MCP is a “webshit” protocol (even in stdio mode), so if web protocols are unsuitable for your problem, MCP would be as well.

Unfortunately, MCP is not HATEOAS. It doesn't need to be, because it's not web-like. I wish it were.

HATEOAS is great for web-like structures because in each response it not only includes the content, but also all actions the client can take (usually via links). This is critical for architectures without built-in structure — unlike Gopher which has menus and FTP and Telnet which have stateful connections — because otherwise a client arriving at some random place has no indication on what to do next. MCP tackles this by providing a stateful connection (similar to FTP) and is now moving toward static entry points similar to Gopher menus.

I specifically wrote about why pure HATEOAS should come back instead of MCP: https://www.ondr.sh/blog/ai-web

Isn't this just the same paradigm as plugins?

Similar, but one level higher.

Plugins have pre-defined APIs. You code your application against the plugin API and plugin developers do the same. Functionality is being consumed directly through this API — this is level 1.

MCP is a meta-protocol. Think of it as an API that lets arbitrary plugins announce their APIs to the application at runtime. MCP thus lives one level above the plugin's API level. MCP is just used to exchange information about the level 1 API so that the LLM can then call the plugin's level 1 API at runtime.

This only works because LLMs can understand and interpret arbitrary APIs. Traditionally, developers needed to understand an API at design-time, but now LLMs can understand an API at runtime. And because this can now happen at runtime, users (instead of developers) can add arbitrary functionality to applications.

I hate plugging my own blog again but I wrote about that exact thing before, maybe it helps you: https://www.ondr.sh/blog/thoughts-on-mcp

This sounds like a security nightmare.

As it currently stands, MCP is absolutely a security nightmare. Combine this with a general lack of appreciation for security culture amongst developers, and the emerging vibe coding paradigm where non-security-minded people automatically generate and fail to properly audit production-facing code, and it's a disaster waiting to happen.

Feels like we've slid back into the 90s in this regard. Great time to be a security researcher!

I tend to agree with this.

No, MCP's have NOT Won (Yet) https://newsletter.victordibia.com/p/no-mcps-have-not-won-ye...

It’s pretty astounding to me that this aspect of MCP is not mentioned more. You’re putting a LOT of trust in both the model and the system prompt when you start attaching MCPs that provide unfettered access to your file system, or connect up to your REST API’s POST endpoints.

(That being said, I have to admit I’ve been writing my own powerful but extremely dangerous tools as an experiment (e.g. run arbitrary Python code on my machine, unsandboxed) and I have to admit the results have been incredibly compelling.)

agreed. this sounds useless at the moment unless you’re sand boxing it in a throw-away VM lol. Scary!

> Feels like we've slid back into the 90s in this regard.

Thank $deity. 90s and early 2000s were the times software was designed to do useful work and empower users, as opposed to lock them into services and collect telemetry, both of which protected by the best of advancement in security :).

I'm only half-joking here. Security is always working against usefulness; MCP is designed to be useful first (like honest to $deity useful, not "exploit your customers" useful), so it looks like security nightmare. Some of that utility will need to go away, because complete lack of security is also bad for the users - but there's a tradeoff to be made, hopefully one that doesn't just go by modern security zeitgeist, because that is already deep into protecting profits by securing services against users.

> a general lack of appreciation for security culture amongst developers, and the emerging vibe coding paradigm where non-security-minded people automatically generate and fail to properly audit production-facing code

There is also a general lack of consideration of who is being protected from whom, and why in the security culture. MCP, vibe coding, and LLMs in general are briefly giving end-users back some agency, bringing back the whole idea of "bicycle for the mind" that was completely and intentionally destroyed when computing went mainstream. Let's not kill it so eagerly this time.

A non-exhaustive list of concerns:

- How does a consumer of a remote MCP server trust that it is not saving/modifying their data, or that it is doing something other than what it said it would?

- How does a consumer of a local MCP server trust that it won't wreck their machine or delete data?

- How do servers authorize and authenticate end users? How do we create servers which give different permissions to different users?

These are examples of things which must be done right, and sacrificing user security in order to achieve market dominance is ethically bankrupt. Pedestrians don't know exactly which regulations serve them when a bridge is built, so we don't expect pedestrians to be able to stop corruption and laziness in civil engineering. The same should be true for mass infrastructure; we have a duty as engineers to make the right call.

> MCP, vibe coding, and LLMs in general are briefly giving end-users back some agency, bringing back the whole idea of "bicycle for the mind"

I love what software might look like in 15 years. I don't plan to kill that. I want to protect it, and also protect everyone involved.

would love your thoughts on this: https://blog.cloudflare.com/remote-model-context-protocol-se...

I really enjoyed both your blog posts. You've clearly thought about this a lot and explained things well. I'd love to subscribe to be updated on your next post (even if it's not for months/years). Any chance you could add an RSS feed to your blog?

Thanks. Added RSS, but WC3 shows some errors. I'll move to plain markdown when I have more time, then this will be easier.

the blog is hosted on substack which supports feeds.

https://newsletter.victordibia.com/feed

> And because this can now happen at runtime, users (instead of developers) can add arbitrary functionality to applications.

I don't understand what you mean by this. Currently without MCP a server has an API that's documented and to interact with it(thus provide "arbitrary functionality") you call those APIs from your own application code(e.x. python script).

With MCP an LLM connected to your application code calls an API that's documented via MCP to provide "arbitrary functionality".

How are these different, and how does MCP allow me to do anything I couldn't before with API access and documentation? In both cases the application code needs to be modified to account for the new functionality, unless you're also using the LLM to handle the logic which will have very unpredictable results.

>In both cases the application code needs to be modified to account for the new functionality, unless you're also using the LLM to handle the logic which will have very unpredictable results.

In the case of MCP, no application code is modified. You first ship the application and then functionality is added. Using plain APIs, it's the other way around. That's the difference.

I don't understand this at all.

If my application performs some function dependant on data from an API(e.x. showing tax information, letting a user input tax information, and performing tax calculations and autocomplete), how do I extend that UI easier with MCP than with an HTTP REST API.

Even with MCP I need to update my application code to add UI elements(inputs, outputs) for a user to interact with this new functionality, no?

No, MCP does not include any concept of UI (yet). Tool results are usually text only, although there is also the abstraction of an Image (which can be displayed as clients as decide to, e.g. inline).

So no application code needs to be changed because no application code exists.

Isn't that like saying you don't need to modify application code with an REST API if your "application" is just a list of instructions on how to use wget/bash to accomplish the task?

I think this is a good explanation on the client side of MCP. But most developers are not building MCP clients (I think?). Only a few companies like OpenAI, Anthropic, Cursor and Goose are building MCP client.

Most developers are currently building MCP servers that wrap a 3rd party or wrap their own service. And in this case, they are still at deciding on the tools in design-time, not runtime.

Also I want to mention that both Cursor and Claude desktop don't support dynamic toggling on / off tools within a MCP server, which means users can't really pick which tools to expose to AI. It exposes all tools within a MCP server in current implementation.

The concept of design-time vs. runtime applies to both clients and servers.

I believe you're implying that server developers can focus less on this concept (or sometimes even ignore it) when building a server. This is true.

However, the fact that end-users can now run MCP servers directly — rather than having to wait for developers to bundle them into applications — is a significant paradigm shift that directly benefits MCP server authors.

I see what you mean. It is a paradigm shift indeed if you look from the user's perspective.

You might be able the say the user could "plug in" the new functionality. Or it allows them to "install" a new "application"?

So MCP to an application is like how a WebDriver interface is to a Web browser?

The full quote is better:

  > MCP is an open protocol that standardizes how applications provide context
  > to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C
  > provides a standardized way to connect your devices to various peripherals
  > and accessories, MCP provides a standardized way to connect AI models to
  > different data sources and tools.

No, it's actually a lot worse. "USB-C port for AI applications" sounds like something written by an insane person.

I want to know in which way is USB-C applicable here. The complicated plug that's actually 30 different protocol's that's difficult understand what capabiltiies a plug/cable actually has?

Yes. 99% of that complexity is on the side of implementers - where it should be - and for actual use, approximately everything works well with everything else; specifics matter mostly when you're trying to plug devices that exercise the limits of advanced capabilities. Which sucks, yes, but mostly because implementers/vendors made it this way (would it hurt y'all to label your cables and devices properly, correctly and visibly?!).

I thought this was a "your mom is compatible with everyone" joke

"You're mom is like USB-A, I have to turn her around 3 times before I can get it in the hole"

I don't know whether to laugh at the joke or be triggered that USB takes three turns to insert.

The closest software analogy I’ve heard is like passing around a callable/function with a standard interface. An LLM can call the callable and work with the returned data without needing to go back and forth between your application logic.

It's trying to say "you can plug lots of things into this in a standardized way."

https://norahsakal.com/blog/mcp-vs-api-model-context-protoco...

The weather data example in their documentation makes it really simple to grasp how it works as an interface for models:

https://modelcontextprotocol.io/quickstart/server

I don't think it's terribly difficult to drill down into their GitHub to see what's happening under the hood if you need that level of detail.

Well its directly from the documentation written by the SWEs that built the protocol...

https://modelcontextprotocol.io/introduction

Maybe they used an LLM to explain it. Gemini in particular is obsessed with these utterly useless analogies for everything, when I would prefer something closer to Wikipedia with more context. (Needless to say, I currently don't find LLMs useful for learning about things. That's a shame because that use case feels promising.)

I saw this ChatGPT-created analogy on a JS subreddit the other day:

> Imagine you have a robot in a room, and this robot can perform actions like turning on a light, opening a door, or picking up objects. Now, if you want to tell the robot to do something, you usually say something like, "Robot, pick up the pen!" or "Robot, open the door."

> In JavaScript, ‘this’ is like the "robot" in the room

Terrible.

LLMs are like an unlimited, poorly written encyclopedia. Often inaccurate or not entirely helpful, but will get you enough of an idea to find better sources. Sort of solving the "I don't know what I don't know" gap.

In this regard, they have been extraordinarily fruitful for my research and studies.

What's so hard for them to just say "it's a standard"? Why do we need to mention USB? Or USB-C at that, which just confuses the message even more?

Do modern developers not know what "standards" means? Is this marketing slop or did an engineer seriously write that for other engineers?

I prefer this interpretation:

MCP Isn’t the USB-C of AI — It’s Just a USB-C(laude) Dongle

https://dev.to/internationale/mcp-is-not-ai-usb-c-its-usb-cl...

The illustrations are on their official website.

I find it hard to respect a company that invented dongle and claims to have invented USB

> MCP, despite its open-source claim, heavily relies on proprietary interfaces from Anthropic's Claude model. Thus, the proclaimed openness is surface-level at best, creating subtle but significant barriers within the ecosystem.

This strikes me as fundamentally untrue, but I'd love to see an example of this in the source code or documentation.

What’s wrong with this analogy?

It’s a common set of APIs/protocols that includes a way to share data, capabilities, etc.

That’s pretty much exactly what USB is.

This is what we used to just call "standards", but apparently we need analogies now in order to explain standards to new developers.

Not only that, the P for "protocol" already gives that.

but it’s technically not a standard yet. Or not blessed as one by any neutral body or consortium etc.

It’s quickly becoming a de facto standard though, now that OpenAI has added it to their SDK.

It’s likely to be used to create a standard though (like with QUIC and HTTP3)

This is just an ontological issue. Is it a standard because it is designed to be one, or is it only a standard once it actually fulfills its role and is recognized as a standard? That's something we could debate all night. :)

MCP is very similar in protocol to LSP.

In LSP, you have editor (vscode, neovim), and language servers (rust, typescript, python).

In MCP, you have the client (chat window), and servers (providing context, tools, and prompts).

they probably mean it’s going to be difficult early on to find standards compliant implementations. and then always very annoying to make sure all involved components support the correct feature set.

A good analogy I think for those in Trading might be FIX or FpML. Those protocols and standards have revolutionized electronic trading.

That's the same analogy anthropic uses to describe it.

Because everyone knows the usb-c protocol

Do they? Like actually, know it cover-to-cover, or do they just know of it? Because the first thing to point out is that USB-C isn't a protocol, it's a connector standard.

Honestly I’m now even more confused

It's got an open socket at the bottom, that accepts many different plugs.

I don't know if GP understands that his phrasing might not be so flattering for his mother ))

You spend time with some weirdly technical moms.

Thinking in terms of MCP, will change your thought process to design your application in different way.

I see it as service discovery for AI applications

It's a beautiful and deep analogy, and works for both software engineer and their mom.

Mom-level: ChatGPT ("or that other ChatGPT with a human name, Klaus I think? No, it was Claude.") can use software that says it supports MCP. If it says "MCP", I can use it with my AI.

Software dev level: MCP servers and MCP clients should just work, like USB. I don't really have to care about this, I expect them to connect just fine. Like with USB, there's a crap ton of complexity dumped on implementers of the spec to make it work reliably and cheaply - as it should be. That's literally their job: to take all the "secret sauce" that makes their product "special" and hide it behind a standard, because they're not special and nobody cares.

As another software engineer: if it ain't USB, I ain't buying, because I'm too old to deal with the proprietary per-device unique connectors bullshit. The standard exists so I don't have to think about it.