MCP Tools, Resources, and Prompts Explained

Every MCP server is built from three primitives: tools act, resources supply data, prompts offer templates. Knowing mcp tools resources prompts tells you what a server can do and how to design your own. The official documentation frames MCP as an open standard linking AI applications to data sources, tools and workflows. Below: what each primitive is, real examples, how servers combine them, and common mistakes.

What are the three MCP primitives in one sentence each?

The official Model Context Protocol documentation describes MCP as an open-source standard for connecting AI applications to external systems. It names three kinds of things an application can reach: data sources such as local files and databases, tools such as search engines and calculators, and workflows such as specialized prompts. Those three map directly onto the primitives a server exposes.

• Tools: actions the agent can trigger, such as opening an issue or searching.
• Resources: data the agent can read, such as a file or a database record.
• Prompts: reusable templates the server offers for a specific workflow.

The documentation compares MCP to a USB-C port for AI applications: one standard connector instead of a custom cable per system. As of September 2026 the documentation site lists version 2026-07-28 as the latest, so check the specification for exact field names, since this article stays at the conceptual level.

What are MCP tools?

Tools are the primitive most people meet first. A tool is a named action with typed inputs that the agent can call and get a result back from. The official GitHub server is a good concrete case: its documentation lists 9 tools, including get_repository, list_issues, create_issue, list_pull_requests, create_pull_request, get_file_contents and create_or_update_file.

Each tool declares its inputs. For example, create_issue requires an owner, a repo and a title, and accepts an optional body. That schema is what lets an agent in Claude Code, Cursor or VS Code know how to call the action without guessing. You can install the server with mcpizy install github or run it directly with npx -y @modelcontextprotocol/server-github. See the GitHub server page for the full tool list.

Tools are also where risk lives, because some of them change things. The GitHub server's own notes recommend a fine-grained token with the smallest scope, read-only repo and issues for safety, and write access only with a human approving in the loop. For a deeper look at this, read MCP Server Permissions and Scopes Explained.

What are MCP resources?

Resources are data the agent can read rather than actions it performs. The MCP documentation lists local files and databases as examples of the data sources an application can connect to. Think of a resource as something with an address that a client can fetch and hand to the model as context, without a function call that does work on the server's behalf.

The distinction matters because reading and acting are different risk classes. Even in tool-only servers you can see the read side: the GitHub server's get_file_contents reads a file from a repo at a given ref, and list_issues reads issues with filters. Those are implemented as tools, so the agent must decide to call them. A resource-style design instead lets the client or user attach known data up front.

Context7 is a useful example of the kind of data people want in context. Its listing describes it as live documentation for any library or framework, and the CheckMCP audit of upstash/context7 gives it 100/100 (grade A) as of September 2026. Check the server's own documentation to see which primitives it actually implements, rather than assuming.

What are MCP prompts?

Prompts are reusable templates that a server publishes, so a user or client can start a well-formed workflow instead of writing instructions from scratch. The MCP documentation describes workflows as specialized prompts, which is the clearest one-line definition. A prompt packages the wording, and often the arguments, for a task the server is good at.

A concrete idea: a server built around pull requests could offer a review template that asks for the repository and a pull request number, then tells the model to fetch the diff and comment on it. The GitHub server's documentation describes PR review automation as one place it shines, with the agent reading list_pull_requests, fetching the diff and leaving comments. A prompt would be the reusable entry point for that workflow. That is an illustration of the concept, not a claim about what any listed server ships.

Prompts are the least-used primitive in many setups, so do not be surprised if a server you install offers only tools. Client support can vary too, so consult your client's documentation to see how prompts surface in its interface.

How does one server combine the three in practice?

A well-shaped server uses each primitive for what it does best, and you can think of them as layers on the same domain. Using the GitHub server as the domain, here is one way the split could look:

1. Resources: repository files and issue text the user wants in context.
2. Tools: create_issue, create_pull_request and other actions that change state.
3. Prompts: a review or triage template that chains the two.

The official GitHub server documents its 9 tools, and the same pages note that a more aggressive community fork adds Actions, projects and packages support for deeper workflows. In other words, the tool surface is where servers tend to grow, and it is where you should look first when comparing options. The GitHub MCP guide for Claude Code walks through setup.

When you evaluate a server, list which primitives it exposes before you install. The audit guide covers what to check, including licence, maintenance and documentation, which are the same dimensions the CheckMCP audit scores.

Which design mistakes come up most often?

The GitHub server's own notes on pitfalls double as a checklist for tool design. First, direct writes: create_or_update_file commits through the API, so there is no GPG signing, no pre-commit hooks and no CI run on that commit unless branch protection allows it. The documentation advises pushing to a branch and opening a pull request for anything beyond small doc fixes, never committing directly to main.

Second, silent gaps. The same notes say search_code uses an eventually consistent index, that recently pushed code can take a while to appear and that some file types are not indexed. A tool that returns an empty result without explaining why misleads the agent. Design tools to say what they could not see, and give agents a fallback such as cloning and grepping when hits are few.

Third, oversized responses and over-wide scopes. The notes warn that reading a large file through get_file_contents is token-heavy, while short issue and PR reads are lean. Return only what the task needs. Also request the narrowest token scope: fine-grained tokens can behave in surprising ways, for instance private repositories are not covered by an all-repositories toggle by default.

FAQ

Do I need all three primitives in a server?

No. The GitHub server documents tools, and that is enough to be useful. Start with the primitive that matches the job: actions call for tools, readable context calls for resources, and a repeatable workflow calls for a prompt. Add the others only when a real use case needs them, and keep the specification as your source for exact behaviour.

How do I see what a server exposes before installing it?

Open the server's page and read its tool list, then follow the vendor's documentation for anything else. For the GitHub server, the documentation lists each tool with its required and optional inputs. Then run mcpizy install followed by the server slug, for example mcpizy install context7, once you are satisfied.

Is there a price for using these primitives?

The official pages used for this article do not state a price for MCP itself. Cost for a given server depends on the service behind it, so check that vendor's own pricing page. The MCP documentation describes the protocol as open source.