Homework 02 — Protocol, lifecycle, transports

Task 1 — Lifecycle phase mapping

Recall the four phases of an MCP session: Connect, Initialize, Operate, Close. For each phase, list every JSON-RPC method or notification you actually saw on the wire during the L02 lab (from the Inspector message log). Use the format below — one bullet per method, with a one-line note on which side sent it (client or server).

Connect
  - (no JSON-RPC; this is transport setup — describe what happens here)

Initialize
  - method/name (sent by client|server) — what it does

Operate
  - method/name (sent by client|server) — what it does
  - ...

Close
  - method/name (sent by client|server) — what it does

Self-check criteria:

• At least one entry under each of the four phases.
• The notifications/initialized notification belongs to Initialize, not Operate — it is the handshake-completion signal sent by the client right after the initialize response, and only after it does the operate phase begin.
• Notifications (no id field) are labelled as notifications, not requests.
• Each operate-phase method you list should be one you actually triggered from Inspector (e.g. resources/list, resources/read, tools/list, tools/call).

Task 2 — Hand-craft three requests

Without running them yet, write out the exact JSON-RPC 2.0 request bodies you would send for the three calls below. Pick your own id values (any non-null string/number). Then send them through Inspector against the filesystem server from Lab 02 and compare the responses.

1. resources/list with empty params.
2. resources/read for the URI file:///tmp/mcp-demo/hello.txt.
3. prompts/list with empty params.

Skeleton for reference:

{
  "jsonrpc": "2.0",
  "id": <your-id>,
  "method": "<method-name>",
  "params": { ... }
}

Self-check criteria. One of the following must hold:

• Either all three requests produce non-error responses (a result field, no error field), or
• You correctly identify that prompts/list comes back with a JSON-RPC error such as "Method not found" (code -32601) because the filesystem server did not advertise the prompts capability during the initialize handshake. That is also a passing answer — in fact it is the correct observation about how capability negotiation gates which methods are valid.

Either outcome is acceptable as long as your written explanation matches what Inspector actually shows. The point is to read the server's capabilities object from the initialize response and predict whether a method is supported before you call it.

Task 3 — Pick a transport for each scenario

For each scenario below, choose stdio or Streamable HTTP and give a one-sentence justification grounded in the trade-offs from the theory reading (locality, auth, multi-client, deployment).

1. A dev tool that lets the user pick a folder on their own laptop and exposes its contents to Cursor running on the same laptop.
2. A team-shared "search Slack" MCP server hosted at mcp.acme.internal that every engineer's Claude Desktop should be able to use.

Self-check criteria:

• Scenario 1 → stdio. Single user, single machine, no network surface, no auth needed — exactly what stdio is for.
• Scenario 2 → Streamable HTTP. Multiple clients, central deployment, reachable over the network, needs proper authentication (e.g. OAuth / bearer token) — exactly what stdio cannot do.
• Your one-sentence justifications mention the deciding factor (locality vs. multi-client / network reach), not just the answer.