Tool / Function Calling interview questions
Tool / Function Calling questions a AI engineer can be asked, from first job to senior. Open one to see the strongest answer and why it works.
When a model “calls” one of the tools you defined, what actually happens? Who runs the code?
The strongest answer: The model only produces a structured request — a tool name and arguments. My application decides whether to run it, runs it, and sends the result back in the next message for the model to use
Why it works: Exactly — the model proposes, your code disposes. That gap is where validation, permissions and logging live.
- The model proposes; your code executes.
- A tool call is structured output.
- Your code may validate or refuse.
- Return the result to the model.
What goes into a tool definition, and why does the description matter so much?
The strongest answer: A name, a description and a schema for the parameters. The description is the only documentation the model has, so it says what the tool does, when to use it and what each parameter means
Why it works: Exactly — write it as you would for a new colleague who cannot see the code: purpose, when to use it, when not to, and the meaning of each field.
- The description is the model’s documentation.
- Name, description, parameter schema.
- Say when to use it — and when not.
- Describe what every parameter means.
The model’s arguments for your tool match the JSON schema. Do you still validate them, and why?
The strongest answer: Yes — they are untrusted input. A schema match proves the shape, not that the order exists, belongs to this user or is within limits; I check those server-side and return a clear error
Why it works: Exactly — shape is not meaning. Treat the model like any other client of your API: validate, authorise, and answer with an error it can act on.
- Schema-valid is not the same as valid.
- Treat arguments as untrusted input.
- Check existence, ownership and limits.
- Return an error the model can use.
Your “get_invoice” tool is called with an id that does not exist, and on another run the billing service behind it times out.
In each case, what do you return to the model?
The strongest answer: A result flagged as an error, with a short message it can act on — “no invoice with that id; search by customer” — never a stack trace. Timeouts I retry in code first, then report as temporary
Why it works: Exactly — an error is an observation like any other. Say what failed and what to try, keep internals out, and handle transient faults below the model.
- Errors are observations — make them useful.
- Flag the result as an error.
- Say what failed and what to try.
- Retry transient faults in code.
An agent called your “create_payment” tool, the response timed out, the agent tried again, and the customer was charged twice.
How do you design the tool so that a retry cannot do this?
The strongest answer: Make it idempotent: a key tied to the order rather than the attempt, set by my code and not invented by the model per call, stored with the outcome so a repeat returns the first result
Why it works: Exactly — retries are normal in agent loops, so the tool must make them harmless. The key has to be stable across attempts, which is why the model should not mint it.
- Retries happen — make them harmless.
- One key per intended action.
- Your code sets the key.
- A repeat returns the first outcome.
Every team has added tools to the shared company agent. It now has around sixty, several of them overlapping, and it increasingly picks the wrong one.
What do you do about it?
The strongest answer: Shrink what the model sees: merge overlapping tools, make descriptions say when to use each, load only the subset relevant to the task, and gate new tools behind a tool-selection test set with a named owner
Why it works: Exactly — it is an interface-design and governance problem. Fewer, sharper tools per request, and a test that tells you when a new tool breaks the old ones.
- Tool sprawl is an interface problem.
- Merge overlaps; sharpen descriptions.
- Show only the relevant subset.
- Test selection before adding tools.
Your agent acts for logged-in users and reaches internal services through tools. Where does authorisation live?
The strongest answer: In the tool layer, never the prompt: each call carries the end user’s identity and scope rather than a shared super-user, so the service applies its usual rules to the model too
Why it works: Exactly — the model is a confused deputy waiting to happen. If every call runs as the user, the worst a manipulated model can do is what that user could already do.
- Enforce permissions in code, per user.
- Propagate the end user’s identity.
- No shared super-user for tools.
- Never rely on the prompt.