MCP Tools, Resources, and Prompts

Summary

🧭 What this page covers

MCP Architecture explained how hosts and servers communicate. This page focuses on the three core primitives an MCP server exposes: tools, resources, and prompts.

These three primitives represent different kinds of value. Tools do something. Resources expose something. Prompts frame something. Modelling them correctly is what makes an MCP server easy for hosts to discover and safe for models to use.

Primitive	Main verb	Typical shape	Example
Tool	Execute	Input schema + result	`searchTickets`, `runKqlQuery`
Resource	Read	URI-like handle + content	`kb://hr/leave-policy`, `repo://src/appsettings.json`
Prompt	Template	Named reusable instruction pattern	`incident-triage`, `release-checklist`

Tools are for actions and computation

Use a tool when the host needs the server to execute logic, fetch live data, run a query, or trigger a side effect. Tools should have explicit schemas, clear validation, and observable execution boundaries.

Resources are for content access

Use a resource when the host needs read-oriented content: documents, files, reference data, schemas, or curated knowledge. If nothing is being executed and the value is primarily content, it is probably a resource.

Prompts are reusable task frames

Use prompts when you want reusable, discoverable instruction templates that a host can present or apply dynamically. Prompts are especially useful for repeatable workflows with strong formatting or compliance expectations.

Why This Matters

⚠️

Wrong primitive leads to bad ergonomics

Teams overuse tools for content that should be resources

If every document fetch becomes a tool invocation, hosts lose simple browsing patterns and models get an unnecessarily large action surface. Read-only content belongs in resources whenever possible.

🔒

Action surfaces need tighter controls

Tools carry more operational risk than resources

Tools may query live systems or trigger changes. Resources usually expose read-only content. Separating them cleanly makes it easier to apply approvals, rate limits, and authorization rules where they matter most.

📐

Prompt reuse improves consistency

Prompt libraries should be discoverable, not copied across apps

Many teams duplicate the same triage prompt, report-writing instructions, or compliance framing text across several apps. MCP prompts turn those into central reusable assets that hosts can discover at runtime.

Core Concepts

Tool example

{
  "name": "search_tickets",
  "description": "Search IT support tickets by keyword and status",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "status": { "type": "string", "enum": ["open", "closed", "all"] }
    },
    "required": ["query"]
  }
}

Resource example

{
  "uri": "kb://security/password-reset-policy",
  "name": "Password Reset Policy",
  "description": "Current corporate password reset procedure",
  "mimeType": "text/markdown"
}

Prompt example

{
  "name": "incident-triage",
  "description": "Guide the model through a security incident triage workflow",
  "arguments": [
    { "name": "severity", "required": true },
    { "name": "system", "required": true }
  ]
}

Decision guide

Realistic Example

Scenario

An operations MCP server for an internal SRE assistant exposes:

Tool: run_kql_query
Tool: get_active_alerts
Resource: runbook://payment-api/high-cpu
Resource: schema://orders-db/tables
Prompt: post-incident-summary

When the user asks, "Summarise the high CPU incident on the payment API and include current alert state," the host can:

Load the runbook resource.
Call get_active_alerts.
Apply the post-incident-summary prompt template.
Let the model produce the report.

That is materially cleaner than representing everything as an undifferentiated tool call.

Senior Tech vs Dev Conversation

Senior Tech: Could a resource just be a tool called get_document?

Dev: Technically yes, architecturally no. A get_document tool hides content behind an action interface. Resources communicate intent better: this is browseable, read-only content. Hosts can optimise around that distinction, and policy decisions become clearer.

Senior Tech: When do prompts help beyond normal system prompts?

Dev: When the prompt itself is a reusable product asset. If multiple hosts need the same incident workflow, audit checklist, or report template, it should be discoverable as a prompt primitive rather than copied into five different codebases.

Common Pitfalls

Pitfall	What goes wrong	Prevention
Making every capability a tool	Large and unsafe action surface	Model content as resources where possible
Returning unstructured tool output	Hard for hosts and models to interpret	Use explicit schemas and predictable fields
Treating prompts as hidden implementation text	Prompt reuse becomes fragmented	Expose shared prompt templates as named MCP prompts
Mixing side effects into read-oriented tools	Hard to reason about safety	Keep read and write operations clearly separated

References and Next Steps

Next: MCP with .NET →
Previous: MCP Architecture →
Specification: modelcontextprotocol.io/specification

Summary​

Why This Matters​

Core Concepts​

Tool example​

Resource example​

Prompt example​

Decision guide​

Realistic Example​

Scenario​

Senior Tech vs Dev Conversation​

Common Pitfalls​

References and Next Steps​