Part 5 of 6 · 4 min read
Exercises
Easy
Easy 1: Run and read (20 minutes)
In code/mini-input, run pytest and python demo.py. For the large-expense case, write down the two requests: which fields differ between them, and which are identical.
Done when: you note that the id changes, that inputResponses and requestState appear only on the second, that the arguments are identical, and that the second carries the same state the first returned.
Hint
compare the two request bodies line by line; the state is the opaque string.
Easy 2: Which answer is it? (20 minutes)
For each, say what the tool should do. (1) The person closes the dialog. (2) The person clicks "No". (3) The person ticks "confirm" but leaves the note empty. (4) The client sends the retry with no inputResponses. (5) The client never declared elicitation.
Done when: you give five answers, distinguishing cancel (ask again later is fine) from decline (do not ask again for the same thing), accepting an empty optional field, asking again for a missing answer, and returning a model-facing message for the missing capability.
Hint
the three actions are accept, decline and cancel; a missing answer means the server should ask again.
Easy 3: Spot the side effect (20 minutes)
Read the tools in servers.py. List every line that happens before a ctx.need(...) in each tool, and mark any that are not safe to repeat.
Done when: you identify the log line in charge_bad as the only unsafe one, explain why quoting a price in buy_ticket is safe to repeat, and say what you would change in charge_bad.
Hint
anything that appends to a list or writes to a store is a side effect; computing a number is not.
Medium
Medium 1: Make a tool safe to retry (60 minutes)
Change charge_bad so the charge happens before the question but cannot repeat: derive an idempotency key from the request and record it.
Done when: a test shows exactly one side effect after a confirmed call, still one after the person declines (explain whether that is acceptable), and one after a retry with the same state; and you say why asking first is still better.
Hint
derive the key from the method, arguments and principal, not from the round.
Medium 2: A form validator that agrees with the spec (90 minutes)
Extend forms.py so it supports multi-select with minItems and maxItems, a default value, and date and date-time formats. Add tests for each, including bad inputs.
Done when: valid and invalid cases are tested for each new type, nested objects are still refused, and the host re-asks on a bad answer.
Hint
follow the allowed-subset rules in section 7; write the failing test first.
Medium 3: State that keeps a secret (90 minutes)
The example's state is readable. Change state.py to encrypt the payload (use a well-known library's authenticated encryption) and show that a client cannot read the price.
Done when: the old tamper tests still pass, a new test shows the plaintext is absent from the token, and you write two sentences on when you would store the state on the server instead.
Hint
with authenticated encryption, a changed token fails to open, so the signature check can go, but the principal and expiry checks stay.
Hard
Hard 1: Try it against a real client (150 minutes)
Expose the expense server over HTTP and call it from a real MCP client or SDK that supports the new revision. Record the exact messages for a confirmation. (I did not run this, so your results are the ground truth.)
Done when: you give a table of differences between your capture and this example's messages, say which revision the client speaks, and report what the client did with requestState.
Hint
capture the first request from the client; the era shows in what it sends.
Hard 2: Break the URL flow properly (150 minutes)
Build a URL elicitation against a real OAuth sandbox you control. Complete it as the wrong user, with and without your identity check. (I did not run this.)
Done when: you show the wrong account being connected without the check and refused with it, record which identifier you compared (and why not an email address typed by the client), and explain what happens when the same person completes it from a different browser.
Hint
compare the subject of the web session and the user in the request, not a field the client can set.
Hard 3: Cost of a greedy server (150 minutes)
Using a real model through a host you control, build a sampling request that a server can repeat, and measure what it costs when the host has no caps and when it has the controls in section 9. (I did not run this.)
Done when: you report tokens and calls with and without each control, say which control mattered most, and say what your plan is for when sampling is removed from the protocol.
Hint
log tokens per call on the host side; do not trust the server's own count.