Case Study: A Support Assistant

Design choices

A small orders MCP server exposes get_order (read-only) and cancel_order (write). Its database user is limited to those tables. A simple agent loop (with a step cap) handles chats. Reads run automatically; cancellations require human approval. Every call is logged with redacted arguments, and an eval of twenty realistic requests runs before each release.

From idea to shipped tool

A complete project combines a loop, an MCP server, safe permissions and tests.

The design on one page

Each line maps to a section of this course. If you can explain every line, you have the main ideas.

Loop        raw API loop, max 10 steps             (Section 1)
Framework   none yet; tools kept framework-independent (Section 2)
Server      FastMCP, stdio, get_order + cancel_order   (Sections 3-4)
Host        registered with absolute paths             (Section 5)
Safety      read-only DB user, approval for cancel     (Section 6)
Quality     unit tests, 20-case eval, redacted logs    (Section 7)

Quick check: Why is `cancel_order` gated by human approval?

• It is a state-changing action that is hard to undo
• Reads are never safe
• MCP demands it for all tools
• Approval makes the model faster