Looking for richer real-world use cases & patterns for MCP resources

[MadanMaram]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

Hi everyone,

I have a working demo MCP server (using FastMCP) where I expose a greeting resource and a simple add(a, b) tool. In Claude Desktop, asking “2 + 3” triggers the tool call and returns the computed sum. But I feel I’m not fully leveraging the resources side of MCP — it seems too trivial.

What I’m seeking:

Realistic, non-toy use cases where resources (read-only data) play an essential, non-trivial role (beyond greeting or static values).

Patterns or architecture suggestions for combining resources + tools so resources offer real value (e.g. document retrieval, configuration, logs, snapshots).

Code examples or reference MCP projects showing rich resource templates (e.g. doc://{id}, metrics://{service}, user://{id} with deeper context).

Advice / pitfalls: when resources are overused, or when things that should be tools are mistakenly implemented as resources.

My current understanding / constraints:

Resources are read-only, no side-effects.

Resources must be deterministic in the same context.

Tools are used when actions, updates, or logic must run.

Could someone share some sample MCP server code or architectural ideas showing resource + tool coordination in a real workflow (e.g. document QA, internal app agents, config + logs, database snapshots)?

[yannj-fr]

Just have a look to MCP-UI and OpenAI sdk, resources are used to convert html to render with a tool

[isheng-eqi]

You are asking the right question — resources are the most underutilized part of MCP, and most examples stop at "hello world" templates. Here are concrete, non-trivial patterns I have seen work in production MCP servers.

The mental model

Before diving into patterns, let us sharpen the intuition:

• Resource = "here is something you can read" (read-only, deterministic, no side effects)
• Tool = "here is something you can do" (may have side effects, may be non-deterministic)

A good litmus test: if calling it twice with the same URI returns different data, it should probably be a tool, not a resource. If it is data that simply exists and the LLM benefits from reading it — that is a resource.

---

Pattern 1: Configuration & Context resources

What: Expose runtime configuration, environment details, feature flags as resources.

Real example: The GitHub MCP server could expose config://repo/{owner}/{repo}/settings as a resource — branch protection rules, required reviewers, CI status. The LLM reads this before suggesting PR workflows, rather than guessing.

Why it matters: LLMs hallucinate configuration. A resource grounds them in reality before they act.

Resource URI: config://environment
Returns: { "region": "us-east-1", "tier": "production", "features": {...} }

Tool coordination: A deploy tool reads config://environment first to validate the target before pushing.

---

Pattern 2: Schema & Metadata resources

What: Database schemas, API specifications, data dictionaries as resources.

Real example: A database MCP server exposing schema://{database}/{table} resources. Before the LLM writes a SQL query via a tool, it reads the schema resource to understand column types and relationships. No more hallucinated column names.

Why it matters: This is the single most impactful pattern. LLM + schema hallucination = broken queries. LLM + schema resource = correct queries.

Resource URI: schema://prod/users
Returns: { "columns": [{"name": "id", "type": "uuid"}, {"name": "email", "type": "varchar(255)", "unique": true}], "indexes": [...] }

Tool coordination: query tool reads schema://{db}/{table} as a pre-flight step, embeds the schema in the prompt, then generates SQL.

---

Pattern 3: Snapshot & State resources

What: System health checks, deployment status, recent error logs as read-only resources.

Real example: A Kubernetes MCP server exposing state://deployment/{name} and logs://pod/{name}?tail=100. The LLM reads deployment status as a resource, then only invokes the restart or scale tool if needed.

Why it matters: Separating observation (resource) from action (tool) is the cleanest architecture. The LLM observes first, then acts.

Resource + Tool coordination:

1. Read state://deployment/api-server (resource) → "3/5 pods healthy"
2. Read logs://pod/api-server-4?tail=50 (resource) → "OOMKilled"
3. Call scale_deployment(name="api-server", replicas=5, memory="2Gi") (tool)

---

Pattern 4: Document & Knowledge resources

What: Documentation, knowledge base articles, codebase search results as resources.

Real example: The Filesystem MCP server already demonstrates this — files are resources. But extend it: docs://api/v2/authentication could read your internal API docs, and codebase://search?q=handleError could return relevant code snippets.

Why it matters: The resource/tool split maps perfectly to the RAG pattern. Resources = retrieval. Tools = generation/action.

---

When NOT to use resources

Common mistakes to avoid:

• Data that changes on every read: stock prices, current time, random numbers. These are tools, not resources — they are non-deterministic by nature.
• Data that triggers side effects: reading a "resource" that increments a counter or logs an audit trail. Resources must be pure reads.
• Large binary data: use resource templates with pagination (e.g., logs://{pod}?offset={n}&limit={m}) rather than dumping 100MB of logs into context.

---

A concrete architecture: the "observe-then-act" loop

The most effective pattern I have seen across MCP implementations:

1. RESOURCE: Read the current state      → LLM understands context
2. RESOURCE: Read relevant schemas/docs  → LLM plans correctly  
3. TOOL:    Execute the action           → LLM acts
4. RESOURCE: Verify the result           → LLM confirms

This maps to how a human engineer works: check the dashboard, read the docs, make the change, verify it took effect. Resources are not optional decoration — they are how the LLM builds an accurate mental model before acting.

---

Reference MCP servers worth studying

• Filesystem MCP server (modelcontextprotocol/servers): the canonical resource-as-file pattern — every file and directory is a resource URI
• GitHub MCP server (github/github-mcp-server): issues, PRs, and code search could all be modeled as resources (currently mostly tools, but the boundary is rich)
• Postgres MCP server: schema introspection as resources, query execution as tools — a clean separation

The gap you are feeling — that resources seem trivial in toy examples — is real because resources only shine in multi-step workflows where the LLM alternates between reading state and performing actions. Build a server that exposes both, and the value becomes obvious.