It's a read/write protocol for making external data/services available to a LLM. You can write a tool/endpoint to the MCP protocol and plug it into Claude Desktop, for example. Claude Desktop has MCP support built-in and automatically queries your MCP endpoint to discover its functionality, and makes those functions available to Claude by including their descriptions in the prompt. Claude can then instruct Claude Desktop to call those functions as it sees fit. Claude Desktop will call the functions and then include the results in the prompt, allowing Claude to generate with relevant data in context.

Since Claude Desktop has MCP support built-in, you can just plug off the shelf MCP endpoints into it. Like you could plug your Gmail account, and your Discord, and your Reddit into Claude Desktop provided that MCP integrations exist for those services. So you can tell Claude "look up my recent activity on reddit and send a summary email to my friend Bob about it" or whatever, and Claude will accomplish that task using the available MCPs. There's like a proliferation of MCP tools and marketplaces being built.

If you know JSON-RPC: it's a JSON-RPC wrapper exposed for AI use and discovery.

If you know REST / http request:

it's single endpoint-only, partitioned / routed by single "type" or "method" parameter, with some different specification, for AI.

Wasn't the point of REST supposed to be runtime discoverability though? Of course REST in practice just seems to be json-rpc without the easy discoverability which seems to have been bolted on with Swagger or whatnot. But what does MCP do that (properly implemented) REST can't?

> Of course REST in practice just seems to be json-rpc

That's so wrong. REST in practice is more like HTTP with JSON payloads. If you find anything similar to json-rpc calling itself REST just please ask them politely to stop doing that.

Half the point of MCP is just making it easy for an LLM to use some language in a standard way to talk to some other tool. I mean MCP is partly a standard schema for tools to interact and discover each other, and part of it is just allowing non-webserver based communication (like stdio piping, especially useful since initial the use case is running local scripts

In a nutshell: RPC with builtin discoverability for LLMs.

old dev language is deterministic, llm in the loop now so the language is stochastic.

it is amazing we used to prize determinism, but now it's like determinism is slowing me down. I mean how do you even write test cases for LLM agents. Do you have another LLM judge the results as close enough, or not close enough?

Yes, and you have to do it in a loop on every request. Not joking. It’s called “LLM as judge.”

What an amazing business to convince people to use. Making people pay to use LLMs to supervise the LLMs they pay for in order to get decent results is diabolically genius.

At the risk of offending some folks it feels like the genius of the Mormon church making its "customers" pay the church AND work for it for free AND market it for free in person AND shame anyone who wants to leave. Why have cost centers if you don't have to!

It's a business model I wasn't smart or audacious enough to even come up with.

It's a bit like paying more for AWS logging services than for the AWS services that provide the services your customers actually consume.

A RPC standard that plays nicely with LLMs?

self documenting API