I bombed my first agent-tool design round: my checklist

A quick note first. The candidate in this story is an illustrative composite, not a real person, and the interview is not a report of any real company's process or result. It is a realistic pattern, told in first person so the mistakes are easy to spot in your own prep.

The prompt sounded friendly. Design the tools for an assistant that helps a support team look up orders, issue refunds, and update tickets. I had built agents before, so I started listing tools right away: get order, refund order, update ticket, search tickets, send email. Five tools in two minutes. The interviewer nodded and then asked the question that unraveled the rest of the round. What happens when the model calls refund order twice?

Mistake one was designing tools as if a careful human would call them. I had written each tool the way I would write an internal API for another engineer. But the caller here is a model that can retry, misread a result, or call the wrong tool with confident arguments. What I would do now is start every tool design with its worst caller in mind. For anything that changes state, ask what a duplicate call does, and make it safe with an idempotency key or a check of current state before acting.

Mistake two was vague names and loose inputs. My refund tool took an order id and an amount as free text. The interviewer asked how the model would know the amount format, the currency, or whether partial refunds were allowed. I had no answer. What I would do now is give each tool one clear job, a name that says exactly what it does, a typed input schema with required fields, and a description that tells the model when to use it and when not to.

Mistake three was ignoring what comes back. My tools returned whatever the backend returned, including long payloads and raw error messages. The interviewer asked what the model sees when the order service times out. The honest answer was a stack trace. What I would do now is design the output as carefully as the input: short, structured results, and errors that say what went wrong and what the model can do next, such as retry, ask the user, or stop.

Mistake four was treating permissions as somebody else's problem. Any user could ask the assistant to refund any order, because the tool never checked who was asking. The interviewer asked how I would stop that. What I would do now is enforce authorization inside the tool, using the caller's identity, never trusting the model's arguments to carry it, and require a confirmation step for actions that move money or cannot be undone. The guide on MCP tools and server failure modes at /blog/mcp-tools-servers-failure-modes-interview walks through these failure paths in more depth.

Mistake five was having no stopping rule. With five tools and no limits, the agent could loop between searching and updating for as long as it liked. What I would do now is cap steps, log the state at every step, and give the agent a clear hand-off to a human when it is stuck. The LangGraph agent system design guide at /blog/langgraph-agent-system-design-interview-guide shows how to put that state and those branches on a whiteboard.

Mistake six was not saying how I would test any of it. The interviewer asked how I would know the tools worked. I said I would try some conversations. What I would do now is build a small set of tasks with the expected end state for each, then check the records the agent actually changed, not just what it said. The LLM evaluation guide at /blog/llm-evaluation-interview-guide covers how to frame that answer.

Here is the checklist I would carry into the next round. One job per tool, with a precise name. Typed inputs with required fields and clear descriptions. Short, structured outputs and errors the model can act on. Idempotency for anything that changes state. Authorization checked inside the tool, plus confirmation for risky actions. Step limits, logged state, and a human hand-off. And a test set that checks end state, not reply text. If you want a structured six-week path to build these habits, the roadmap at /blog/backend-to-agent-engineer-6-week-roadmap is a good place to start.