Tool calling interview questions
8 questions across 2 sections, in the order you would learn them. Every answer here is one that works — but an answer you have read is not an answer you can give, so use Test yourself and say it out loud first.
How tool calling works
Read the section that teaches thisIf this comes up in an interview
Walk me through what happens when a model calls a tool.
You send messages plus tool definitions. The model responds with a structured request naming a tool and arguments rather than a final answer. Your code executes that function, appends both the request and the result to the history, and calls the model again. The model then answers using the result. It never executes anything itself.
Then they push further
Where does the tool actually run?
In your application. The model only produces a structured request naming a tool and its arguments. Your code validates it, decides whether to run it, runs it, and sends the result back in the next request.
What do you check before running it?
That the tool exists and is allowed for this user, that the arguments pass the schema, and that the values make sense, such as an order id that belongs to this customer. The model's request is untrusted input.
What if the model asks for a tool that does not exist?
Return an error result that says so and lists what is available, and let it try again. If it keeps happening, the tool names or descriptions are probably confusing.
What gets marked up. Marked up for treating the model's tool request as untrusted input that must be validated and authorised. Weak answers imply the model runs the tool itself.
What makes a good tool description?
It says when to use the tool, not only what it does, and it says what the tool returns. The model uses the description to choose between tools, so vague or overlapping descriptions cause it to pick wrongly.
How many API calls does one tool-using question take?
At least two. One where the model requests the tool, one where it sees the result and answers. More if it chains several tools. This is why agents are slower and more expensive than a single completion.
Why use an enum in a parameter schema?
It constrains the argument to valid values at generation time, so an invalid status or category cannot be produced. It also removes a whole class of validation code from your handler.
Failures, parallel calls and keeping results small
Read the section that teaches thisIf this comes up in an interview
A tool throws an exception. What should happen?
In most cases return the error to the model as the tool result, so it can recover, retry with different arguments or explain the problem. Terminal failures such as authentication errors should stop the run instead, because retrying cannot help.
How do you handle a model requesting several tools in one turn?
Execute them concurrently since they are usually network-bound, then return all results together in a single message. Splitting them across messages trains the model out of making parallel calls.
Why does the size of a tool result matter?
It enters the context and is resent on every subsequent turn, so a large result raises the cost of the whole remaining conversation. Return only what is needed and cap anything unbounded.
How do you stop an agent taking a destructive action?
Architecturally, not by instruction. Scope the tool's permissions, require an explicit confirmation argument, add a human approval gate, and make the operation idempotent so a repeat is harmless. Prompt instructions alone are not a security boundary.
Then they push further
Would you rely on the system prompt saying never delete anything?
No. Instructions make it rarer but they are not a control. The control is in code: do not give the agent a delete tool, or require human approval before one runs, and scope credentials so the action is impossible even if requested.
Which actions need a person in the loop?
Ones that are irreversible, costly, or visible to other people: payments and refunds above a threshold, deletions, messages sent to customers. Reads and reversible changes can usually run unattended.
What gets marked up. Strong answers put the control in permissions and code, not in the prompt, and reason about reversibility. Weak answers rely on instructions.
These are the questions for one topic. The whole question bank covers every topic on the site.