Homework Solutions — Lesson 01

Solution to Task 1 — Explore another official server

Let's walk through mcp-server-fetch as the canonical example. It is the easiest of the three options to demo because it needs no database file and no extra setup beyond a URL.

Open claude_desktop_config.json and add a second entry under mcpServers, alongside the filesystem server you configured in the lab. Your file should now look like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp/mcp-demo"]
    },
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch"]
    }
  }
}

Notice that fetch is a Python-distributed server invoked through uvx, whereas filesystem is a JavaScript-distributed server invoked through npx. Both are equally valid — the command field just differs because the underlying runtimes do. Claude Desktop does not care which language the server is written in; it only speaks MCP over stdio.

Fully quit and restart Claude Desktop so the new server is picked up. Then ask a question that requires the new capability, for example:

"Fetch https://example.com and summarize it."

What you should see in the UI:

1. Claude announces a tool call to the fetch server — the URL appears in the call's arguments.
2. The tool result block contains the page contents (HTML or extracted text).
3. Claude's reply summarizes what was fetched, not what it remembers from training.

Solution to Task 2 — Peer-friendly MCP intro

Here is a model ~200-word answer. Yours does not have to read identically; it just needs to hit the same key concepts (client, server, protocol, and at least one of tools, resources, prompts) and stay grounded in concrete examples instead of jargon.

The Model Context Protocol (MCP) is a wire protocol between LLM-using apps (clients) and tool-providing programs (servers). Without it, every client that wants to expose a custom capability — say, querying your team's Slack — has to ship its own integration. With it, anyone who writes an MCP server gets that capability into every MCP-aware client for free.

Servers expose three primitives. Tools are functions the LLM can call (with structured arguments and structured results). Resources are read-only data identified by URI — files, database rows, anything the LLM might want to consult. Prompts are server-supplied prompt templates the user can invoke.

A realistic use case: a personal-knowledge-base server with tools to search and write notes, resources exposing each note as a URI, and a prompt that converts a topic name into a research-brief outline. Any MCP-aware client — Claude Desktop, Cursor, your own app — can use all three.

✓ Self-check applied: the answer above uses the words client, server, protocol, and all three of tools, resources, and prompts. A student answer that hits the same load-bearing concepts — even with different wording, examples, or emphasis — is fine.

Solution to Task 3 — M × N collapse

Worked example using two capabilities — Slack search and internal wiki search — and two clients — Claude Desktop and Cursor.

Without MCP, each (client, capability) pair needs its own bespoke adapter, because each client has its own tool-use API surface and each capability has its own backend API. That gives 2 × 2 = 4 separate integrations. With MCP, each capability is implemented once as a server; every MCP-aware client consumes it directly.

without MCP                          with MCP
Claude Desktop ─→ Slack-Claude shim   Claude Desktop ─┐
Claude Desktop ─→ Wiki-Claude shim                    ├→ MCP → Slack server
Cursor         ─→ Slack-Cursor shim   Cursor         ─┘         + Wiki server
Cursor         ─→ Wiki-Cursor shim

Four integrations on the left, two servers on the right — and if you add a third client (say, your own custom agent), the left side grows to six but the right side stays at two. That is the M × N collapse: integrations go from O(M × N) to O(M + N).

Honest edges where the simplification has limits:

• Auth — each user still needs credentials for Slack, the wiki, etc. MCP servers typically read those from environment variables or config files; the protocol does not solve secret distribution.
• Deployment — someone has to run the server. For stdio servers (lesson 01), that's the client itself, which is easy. For remote servers (later lessons), you need hosting, TLS, and access control.
• Versioning — clients and servers can drift. MCP has version negotiation, but a buggy server still breaks every client that depends on it.