Building an MCP server · Surface and auth

Read-only or read-write

Decide which of three proposed writes on the support desk server the model runs, which a person approves, and which stay off, from time saved against error cost.

casemediumExercise · 4 min · 52 of 75

On this page

Four weeks of a read-mostly server have gone well, and the team lead wants it to do more. Each new write is a separate decision, priced by what it saves and by what one wrong call costs.

The situation

Your support desk server, the online retailer's from a worked server: the support desk and not the agency's, has run for four weeks with reads, notes and drafts only: 12 agents, 2,100 tickets a day. A team lead asks for three writes:

close_ticket(ticket_id). Agents close 1,400 tickets a day at about 10 seconds each. A ticket closed too early reopens when the customer replies, and costs an agent about 2 minutes.
issue_credit(ticket_id, amount), capped at the $20 agents may credit by hand. There are 180 credits a day, averaging $12, each taking 90 seconds in billing.
merge_tickets(keep_id, merge_id). There are 40 merges a day at 2 minutes each, and the help desk cannot undo a merge.

On a 200-ticket sample, the model's suggested actions were: 133 closes, 3 of them premature; 17 credits, 2 of them not due under policy; 4 merges, 1 joining two different customers who share a surname. Assume $30 an hour for an agent.

The question

For each of the three, decide whether it becomes a write the model runs, a proposal a person approves, or stays off the surface, and name the evidence that would change it.

A strong answer · Rubric · Where answers go wrong

Write your answer first, then open

A strong answer

close_ticket: a write. It saves 1,400 × 10 s = 3.9 hours a day, about $117. The premature rate is 3 / 133 ≈ 2.3%, about 32 reopens a day at 2 minutes, about $32, and the customer's reply undoes it. Give it its own scope, desk:close, as in auth and identity, and allow it only once a reply has been sent. The reversing evidence is a premature rate above about 8%, counted on every live close by its reopens, where reopens cost what closes save.

issue_credit: a proposal. Auto-issuing saves 180 × 90 s = 4.5 hours, about $135 a day. But 2 / 17 ≈ 12% are not due, so about 21 credits a day × $12 ≈ $254 a day leaves the company, more than the time saved. As propose_credit, which the agent approves in one click of about 10 seconds, it saves 180 × 80 s = 4 hours, about $120 a day, and the agent catches the wrong ones. Auto-issue would pay only once the last 10 seconds, about $15 a day, beat 180 × r × $12 at error rate r: r under about 0.7%, measured on far more than 17 cases.

merge_tickets: off the surface. It saves 40 × 2 minutes = 80 minutes, about $40 a day. One wrong merge in four puts one customer's thread in front of another, cannot be undone, and is a privacy incident. No saving covers that. The evidence that would change it is an undo in the help desk plus a schema that refuses a merge unless both tickets share a customer id.

Rubric

Prices each write's time saving with the arithmetic shown, at $30 an hour.
Converts each sampled error rate into a daily cost and compares it with the saving.
Uses reversibility to decide: close is undone by a reply, a credit is money out, a merge cannot be undone.
Chooses a proposal with one-click approval for credits and shows it keeps most of the saving.
Keeps the merge off the surface on irreversibility and privacy, not on time.
Names a reversing condition for each, with any rate it rests on measured over enough cases to trust, not 17.

Where answers go wrong

"All three: the cap is $20 and agents do these by hand." The by-hand test, from designing the tool surface, keeps a tool off when a caller cannot do it. Passing that test does not make the model as accurate as the agent. At 12% wrong, auto-credits cost more than they save.

"None: a model should never write." That gives up about $117 a day on closes, which reverse themselves at a cost of about $32, and about $120 a day on proposed credits that a person still approves.

"Merge with a confirmation dialog." An agent approving 40 merges a day stops reading them. The fault is irreversibility, so the fix belongs in the help desk and the schema, not in a click.