# Case Study: A Refund Assistant Across Teams — MCP & Agent-to-Agent Protocols

Source: https://www.geekswithgeeks.com/en/mcp-a2a/z-case

> Design an assistant that uses MCP tools and delegates to another team's agent.

## The design

Goal: support staff ask the assistant to handle refund requests. **Front-door agent** (support team): an MCP host with three servers, all vetted, pinned and sandboxed: `orders-mcp` (read-only `get_order_status`), `docs-mcp` (policies as resources) and `ticketing-mcp` (create note). Tool definitions are snapshot-tested. **Delegation**: for refund calculation it sends an **A2A task** to the **Billing agent** (owned by finance), found in the registry via its Agent Card (skill `propose-refund`), passing only the invoice id and reason. The billing agent may answer `input-required` ("which line is damaged?"), which the front door relays to the staff member. **Policy** (in host code): allow-listed tools, amount range check, **human approval** before anything is paid, tokens scoped and short-lived with the end user's identity delegated, never forwarded. **Safety**: all tool and agent outputs wrapped as data and scanned; no tool combines private data, untrusted content and outbound send. **Quality**: contract tests for servers, a stub Billing agent for routing and state tests, a 100-case evaluation (outcome, trajectory, safety), a trace id across hops, redacted audit logs, alerts on cost and approval backlog.

## Connected, governed, safe

Standard protocols, strict policy and good tests turn many agents and tools into one dependable system.

![Four habits: standardise, constrain, test, observe.](assets/figures/mcp-a2a/section-8-map.svg) — Figure 8.1 — Standardise, constrain, test and observe.

## The design on one page

Each line maps to a section of this course.

```text
Tools      orders-mcp (read-only), docs-mcp (resources), ticketing-mcp; vetted, pinned, sandboxed  (Sec 3, 5)
Delegate   A2A task to Billing agent found via registry + Agent Card skill "propose-refund"          (Sec 6)
Dialogue   input-required relayed to the staff member; terminal states final                         (Sec 6)
Policy     allow-list + amount range + human approval before payment; scoped short-lived tokens      (Sec 4, 5)
Safety     tool/agent output = untrusted data; no private+untrusted+outbound combination             (Sec 5)
Quality    contract tests, stub remote agent, 100-case eval, trace id, redacted audit logs            (Sec 3, 7)
Change     pinned SDK/protocol versions, adapter layer, deprecation policy                            (Sec 7)
```

**Quiz:** Why does the front door pass the Billing agent only the invoice id and reason?

- [ ] To avoid using tasks
- [ ] IDs are faster to type
- [ ] A2A forbids other fields
- [x] The remote agent is outside the trust boundary and should get minimum data

*Answer:* The remote agent is outside the trust boundary and should get minimum data. Data minimisation limits exposure if the remote side is compromised or misbehaves.