But to save you the click & read: it's OpenAPI for LLMs

I like this succinct explanation.

You write a wrapper ("MCP server") over your docs/apis/databases/sites/scripts that exposes certain commands ("tools"), and you can instruct models to query your wrapper with these commands ("calling/invoking tools") and expect responses in a certain format that they can then use.

That is it.

Why vibe-coded? Because instead of bi-directional websockets the protocol uses unidirectional server-side events, so you need to send requests to a separate endpoint and then listen to the SSE hoping for an answer. There's also non-existent authentication.

Conversely, it allows many different LLMs to get context via many different Applications using a standard prodocol.

It addresses an m*n problem.

that's the missing piece in most of these description.

You send off a description of the tools, the model decides if it wants to use one, then you run it with the args, send it back to the context and loop.

As you yourself say, the context is the text that is fed as input at runtime to an LLM. This text could just always come from the user as a prompt, but that's a pretty lousy interface to try to cram everything that you might want the model to know about, and it puts the onus entirely on the user to figure out what might be relevant context. The premise of the Model Context Protocol (MCP) is overall sound: how do we give the "Model" access to load arbitrary details into "Context" from many different sources?

This is a real problem worth solving and it has everything to do with the technical meaning of the word "context" in this context. I'm not sure why you dismiss it so abruptly.

[0] https://news.ycombinator.com/item?id=43949503

Agent LLMs are able to retrieve additional context and MCP servers give them specific, targeted tools to do so.