Every application used to define its tools in its own way, so nothing was reusable.
MCP is an open protocol that describes tools, data sources and prompts in one agreed format.
A server exposes capabilities, a client connects to it, and any compliant model can then use them.
Write a connector for your database once and every MCP-aware application can use it.
It standardises the plumbing, not the judgement, so tool selection remains the model's problem.
Function calling gave models the ability to use tools, and every product then built that plumbing again.
Each application invented its own way to declare a tool, authenticate to it, and return its results.
A connector written for one assistant was useless in another, so the same integrations kept being rewritten.
The Model Context Protocol is an open standard published to end that duplication.
It defines how a client and a server describe and exchange capabilities over a simple transport.
A server offers three kinds of thing, and the distinction is worth remembering.
Tools are actions the model may invoke, such as running a query or filing a ticket.
Resources are data the client can read, addressed by URI, such as a file or a database row.
Prompts are reusable templates the server exposes for common tasks against its domain.
The client, which is the application hosting the model, connects to servers and mediates every call.
That mediation matters for security, since the client is where approval and permission checks belong.
The practical payoff is composition: connect a filesystem server and a ticketing server and the agent has both.
Servers run locally over standard input and output, or remotely over HTTP for shared deployments.
What the protocol does not do is decide anything, and this is a common misreading.
Choosing which tool to call, with what arguments, remains entirely the model's job.
One question on this card. Every option explains itself once you pick, right or wrong.
17 concepts in this module, then a graded test with every answer explained.