How it works
A server advertises three primitive types: tools the model may call, resources it may read, and prompt templates it may use. The client negotiates capabilities on connection, lists what is available, and forwards calls. Because discovery happens at runtime, the tool catalogue can change without redeploying the application.
Authorisation is the part teams underestimate. The protocol carries a call; it does not decide whether this user may make it. That check belongs in the server and in the host's policy layer, and a tool catalogue that grows at runtime makes it easier to grant more reach than intended.
Example
An MCP server in front of a ticketing system might expose search, read and comment as tools and a set of saved views as resources. Any MCP-capable client — a desktop assistant, an IDE, an agent runtime — can then use it without a purpose-built plugin, which is the entire point of the standard.
Why it matters
MCP is the closest thing the agent ecosystem has to a common integration interface, and it has been adopted well beyond its original author. It also concentrates risk: a single widely installed server sits inside many agents' trust boundaries, which makes server provenance and permission scoping a supply-chain question.