MCP Primitives: Tools, Resources and Prompts — Tool Use, Function Calling & MCP

MCP defines exactly three server-side primitives — tools, resources, and prompts — and nearly every design mistake in a new MCP server comes from collapsing them into one: modeling everything as a tool. That instinct is understandable, because a tool is the primitive most teams meet first, and it is genuinely the most general one. But generality is not the same as fitness, and a server that exposes 'get_document', 'get_release_notes', and 'get_onboarding_guide' as three tools has paid a real cost for no benefit: three schema definitions, three descriptions the model has to read and distinguish, and three turns spent deciding to call something that needed no decision at all.

The three primitives differ along exactly one axis that matters more than any other: who controls when they get used. A tool is invoked by the model — it appears in the list the model sees, and the model decides, turn by turn, whether calling it is worth the effort. A resource is read by the host — the application code, not the model, decides what to fetch and puts the result directly into context. A prompt is offered by the server and selected by a human or the host — the server never gets to force it onto anyone; it just sits available, like a saved query.

This lesson gives you a concrete test for choosing between tools and resources, shows why resources exist at all when a tool could technically do the same job, explains why prompts are the primitive almost nobody uses and what they're actually for, and connects tool annotations — readOnlyHint, destructiveHint, idempotentHint, openWorldHint — to the authorization-as-forcing-function idea from lesson 07. By the end, 'which primitive' should be a five-second decision, not a design meeting.

Analogy🏏Cricket

🏏 Think of it like cricket: A cricket team on the field has three completely different kinds of actors, and mixing up who does what loses matches. The bowler, Jasprit Bumrah, acts on his own judgment — he chooses the yorker at the death over slower balls because he reads the batter and decides in the moment; that decision-making agent is the model, and the delivery he executes is a tool call. The giant scoreboard at the Chinnaswamy is different — nobody decides to consult it, the broadcast director simply pulls the required-run-rate data onto the screen whenever the situation calls for it, without asking the scoreboard's permission or spending an over on the decision; that's a resource, read by whoever controls context, not invoked by the player. Then there's the team's pre-match plan sheet the analyst hands to Rohit Sharma before the toss — a template for how to play left-arm pace at this ground, offered to the captain to pick up and use if he judges it relevant, never forced onto the field; that's a prompt. Bumrah doesn't consult the scoreboard to decide his yorker, and the analyst's plan sheet doesn't bowl deliveries. The insight: three actors, three different directions of control, and a team that made the bowler responsible for updating the scoreboard would be organized all wrong.