MCP defines three core primitives that a server can expose, and each serves a different purpose in how a client and model interact with external data. Tools are functions the model can actively decide to invoke, each with a name, description and JSON Schema for its arguments, covering actions like searching a database, creating a ticket or calling an internal API, and they are the primitive most people mean when they talk about MCP integrations. Resources are addressable pieces of content, such as a file, a database record or a web page, that a client can read directly into the model's context without necessarily requiring the model to decide to call anything, which suits static or semi-static reference material a user or application wants available up front. Prompts are reusable, parameterized prompt templates that a server can publish so a client can offer them as pre-built starting points for common tasks, keeping prompt engineering for a specific workflow on the server side rather than scattered across every client that needs it. Understanding which primitive fits a given integration keeps a server's design cleaner than treating everything as a tool by default. Nanobase AI, an NVIDIA Inception Program member, designs MCP servers using all three primitives where each one fits best rather than defaulting only to tools.
Why the three-primitive model exists
It would be simpler, at first glance, to model every MCP capability as a tool: a function the model can decide to call. But collapsing everything into tools loses a distinction that matters in practice, between content a client wants available up front and actions a model decides to take mid-conversation. The three-primitive model exists because "the model actively decides to call this" and "this content should already be available" are genuinely different needs, and conflating them either forces static reference material through an unnecessary function call or forces a genuinely dynamic action to masquerade as passive content.
Tools, resources, and prompts at a glance
| Primitive | Who initiates | Typical use | Example |
|---|---|---|---|
| Tool | The model, deciding mid-conversation | Actions and dynamic lookups | create_ticket, search_orders |
| Resource | The client, often before or alongside the conversation | Static or semi-static reference content | A policy document, a specific file, a database record |
| Prompt | The client, offering it as a starting point to the user | Reusable, parameterized workflow templates | A "summarize-incident" template with arguments |
Matching the primitive to the interaction pattern, not defaulting to whichever one is easiest to implement, is what keeps a server's design legible to the clients using it.
Choosing between a resource and a tool for the same data
The same underlying document can reasonably be exposed either way, and the right choice depends on how it's used. If a client wants to load a specific, known document into context up front, for example a company's current expense policy that should always be available to an HR assistant, exposing it as a resource fits better, since the client can fetch it directly without requiring the model to decide to search for it. If the same document needs to be found among many others based on a dynamic query, "find the policy covering international travel," a search tool fits better, since that requires the kind of parameterized, on-demand lookup a resource by itself doesn't support. Ask whether the client already knows exactly what it wants, a resource, or needs the model to figure out what to fetch, a tool.
Where prompts pay off
Prompts solve a different problem: keeping prompt engineering for a specific, repeated workflow on the server side instead of scattered across every client application that wants to offer it. A server exposing a well-tuned "draft-incident-summary" prompt, with defined arguments for severity and affected systems, means any client connecting to that server can offer the same polished starting point to its users, rather than each client's developers separately reverse-engineering a good prompt for the same task. This centralizes prompt quality at the source of the domain expertise, the server owner who best understands the workflow, rather than at each individual client integration.
Frequently asked questions
Do all MCP servers need to implement all three primitives?
No. Many servers implement only tools, since that's the primitive most current clients support most consistently and the one that covers the widest range of use cases. Resources and prompts are worth adding when they genuinely fit the use case and the target clients support them.
Can a resource be dynamically generated rather than static?
Yes, a resource's content can be computed at request time rather than being a literal static file, as long as the client can address and retrieve it without the model needing to supply search parameters the way a tool call would require. The distinction from a tool is more about the interaction pattern than about whether the underlying content is static.
Is treating everything as a tool a mistake, or just a simplification?
It's a reasonable simplification for a server that only has actions to expose, and it's currently the safest choice for maximizing compatibility across clients. It becomes a real design mistake once a server has genuinely static reference content or a repeated workflow template that would clearly fit resources or prompts better.
How Nanobase AI helps
Nanobase AI designs MCP servers using all three primitives where each one genuinely fits, rather than defaulting only to tools out of habit. This design judgment connects to how we think about which MCP clients support which primitives and to the underlying mechanics covered in how an MCP server works, and it's grounded in the broader MCP server-building primer we maintain.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.