MCP Tools vs MCP Resources: What's the Difference?

If you've read the MCP spec, you've seen two primitives for exposing data to agents: Tools and Resources. Both let an agent read content from your server. Both return text. So what's the difference — and when should you use each?

The short answer: Tools are for actions and dynamic queries. Resources are for static, addressable content. The distinction matters because agents treat them differently in their reasoning loops.

Tools: callable, dynamic, action-oriented

A Tool is a function the agent can call with arguments. The agent decides when to call it, what arguments to pass, and what to do with the result. Tools are the primary MCP primitive — most MCP servers today expose only tools.

// Agent calls this when it needs to query something
{
  "method": "tools/call",
  "params": {
    "name": "search_docs",
    "arguments": { "query": "rate limits", "limit": 5 }
  }
}

Tools are the right choice when:

• The content is dynamic — the result depends on the arguments
• Computation is involved — search, filtering, aggregation
• The agent needs to take an action — sending a message, creating a record, triggering a workflow
• You want the agent to decide when to fetch the data based on the conversation

Resources: addressable, static, context-oriented

A Resource is a piece of content with a stable URI. Instead of calling a function, the agent (or the MCP client) fetches the resource by address. Resources are designed to be loaded into the agent's context window — think of them as files or documents the agent can read.

// List available resources
{ "method": "resources/list" }

// Read a specific resource by URI
{
  "method": "resources/read",
  "params": { "uri": "docs://getting-started/quickstart" }
}

Resources are the right choice when:

• The content is stable and addressable — a doc page, a schema, a config file
• You want the MCP client (not the agent) to control what gets loaded
• The content should persist in context across multiple turns — like a system document
• You're exposing file-like content: markdown docs, JSON schemas, code files

Side by side

A concrete example

Say you're building an MCP server for a documentation site. Here's how you'd split the functionality:

Use Tools for:

• search_docs(query, limit) — semantic search across all content
• get_changelog(since_date) — filtered changelog entries
• list_endpoints(tag) — filtered API endpoint listing

Use Resources for:

• docs://quickstart — the getting started guide
• schema://api/v2 — the full OpenAPI schema
• docs://authentication — the auth reference page

The search tool is dynamic — the agent passes a query and gets relevant results back. The quickstart resource is stable — the client loads it into context at session start so the agent always has it available.

The client support caveat

Tools have near-universal client support — every MCP client that connects to your server can call tools. Resources have patchier support. Some clients (Claude Desktop, some Cursor versions) support reading resources; others only support tools. If you're not sure what your users' clients support, implement tools first and add resources as a progressive enhancement.

The MCP 2026 RC doesn't fundamentally change this split, but the new Tasks extension adds a third primitive for long-running async work — which is distinct from both tools and resources.

Which does AgentReady use?

AgentReady exposes only Tools — list_sites, ask_site, submit_site, refresh_site. The content is dynamic (query results depend on what you ask), computed (RAG over indexed chunks), and action-oriented (submitting and refreshing sites). There's no stable URI for "the answer to your question about Stripe's rate limits" — so tools are the right fit.

If AgentReady exposed pre-indexed full-text dumps of each site, those would be natural candidates for Resources — addressable, stable, loadable into context. But for a live Q&A interface, tools win.