# Case Study: A Support Assistant — Agent Frameworks and MCP Basics

Source: https://www.geekswithgeeks.com/en/agent-frameworks-mcp/wrap-support-bot

> Design a support assistant that looks up orders through an MCP server and escalates risky actions.

## 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.

![Four parts: loop, server, safety, tests.](assets/figures/agent-frameworks-mcp/section-8-map.svg) — Figure 8.1 — Loop, server, safety 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.

```text
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)
```

**Quiz:** Why is `cancel_order` gated by human approval?

- [x] 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

*Answer:* It is a state-changing action that is hard to undo. Risky, hard-to-reverse actions deserve a human checkpoint even when the model is usually right.