How does tool calling actually work under the hood, and what makes a tool definition good versus bad?
What they are really testing: Tool use is the foundation of everything agentic, and the mechanics, the model emits a structured request and your code executes it, reveal who has built one. Tool design quality is the difference between agents that work and agents that flail.
A real interview question
How does tool calling actually work under the hood, and what makes a tool definition good versus bad?
What most people say
drag me
“You give the model functions it can call and it calls them when needed, the framework handles the details.”
The framework hiding the loop from you is fine until the agent misbehaves, and then someone who does not know the model merely emits text-shaped requests, and that descriptions are the interface, cannot debug it.
The follow-ups they ask next
The model keeps picking the wrong tool of two similar ones. Fix?
The descriptions overlap. Sharpen when-to-use and when-not-to in both, or merge them into one tool with a mode parameter, then eval tool selection on real traces.
What belongs in a tool error message?
What failed, why, and what a valid retry looks like, written for the model: "customer_id not found, expected format C-12345" beats a stack trace.
What the interviewer is listening for
- Can walk the emit-execute-return loop without a framework
- Says descriptions are the interface and writes errors for the model
- Keeps tools single-purpose and validates arguments before executing
What sinks the answer
- Thinks the model executes code itself
- Cannot explain how the model chooses between tools
- Returns raw dumps and opaque errors, then blames the model
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“The model [emits a structured call, name plus JSON arguments], my code [validates, executes, returns the result], and the loop continues. Good tools have [one purpose, a when-to-use description, few named parameters], and [errors written so the model can self-correct]. The model chooses by reading descriptions, so [descriptions are the interface].”
Keep going with agents & tools
Mid
What actually is an agent, mechanically, and what stops one from looping forever or going off the rails?
Mid
What problem does MCP, the Model Context Protocol, solve, and what should you check before plugging a third-party MCP server into your assistant?
Senior
When do multi-agent architectures actually earn their complexity over one well-tooled agent, and what fails in them?
Junior
How do you decide how to chunk documents for a RAG system, and what goes wrong with naive chunking?
Junior
Your LLM feature must return JSON that downstream code parses. How do you make that reliable?
Junior
What is prompt injection, and why is it a bigger deal once your model can use tools?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free