MCP Primitives: Tools, Resources, and Prompts

What MCP Is

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems -- described as "a USB-C port for AI." An **MCP Server exposes capabilities that any MCP-compatible client (Claude Desktop, Claude Code, a custom app) can connect to, so a capability is built once and reused everywhere**, maintained independently of any single application.

Three Core Primitives

An MCP Server is not limited to exposing actions -- it can also surface readable content and ready-made prompt templates, which is a distinct capability from a plain custom tool.

Resources: Direct vs. Templated

Within the resources primitive, there's a further distinction worth knowing: a direct resource has a fixed address with no parameters -- a specific file, a fixed database record, a static list of available documents. A templated resource has a parameterized address -- a URI template that takes an argument, such as a document identifier or a date range, so the same resource *shape* can address many different underlying records. Reach for a resource (of either kind) when you want known data sitting in context from the start of a turn, because pulling it in directly is cheaper and more predictable than making the model issue a tool call to go fetch it.

One caveat worth flagging: resource-injection support varies by client. Not every MCP Client automatically pulls a resource directly into context without an explicit tool call -- verify that the specific client you're targeting actually supports resource injection before designing around the assumption that it does.

Client vs. Server Roles

The client sits inside the AI application and connects to one or more servers; each server advertises its tools/resources/prompts and handles the calls made to it.

When to Build One

Build an MCP Server when a capability (e.g., an internal REST service) should be reusable across multiple Claude applications and maintained independently of any one of them. That reuse-plus-independent-maintenance combination is the canonical MCP use case.

Common exam traps

• "MCP only exposes tools." False -- MCP exposes tools, resources, and prompts as three distinct primitives.
• "Which of these is an MCP primitive?" style questions that list a plausible-sounding fourth option (e.g., model weights) -- only tools, resources, and prompts are core MCP Primitives.
• Assuming every resource is a fixed, parameterless address. A templated resource takes a parameter in its address (e.g., a document ID) -- direct and templated resources are both valid resource shapes, distinguished by whether the address itself takes an argument.
• Assuming every MCP Client supports pulling a resource directly into context without a tool call. Resource-injection support varies by client -- verify rather than assume.
• Hard-coding integration logic into each app's system prompt instead of building a shared MCP Server -- that approach is neither reusable across apps nor independently maintainable.