Tool-calling is the bridge between an LLM's reasoning and the real world. When an agent needs to query a database, send an email, or process a payment, it generates a structured function call that your code executes. The interview tests whether you understand the engineering challenges of making this reliable at scale.

Core Concepts You Must Know

Function Schema Design

Every tool an agent can use is described by a JSON schema. The schema tells the LLM what parameters the function accepts, their types, and which are required. Schema quality directly determines tool-call reliability.

  • Keep schemas simple. Models perform better with flat parameter objects than deeply nested ones. If you have a complex input, flatten it or break the tool into multiple simpler tools.
  • Use enums aggressively. Instead of status: string, use status: enum["active", "paused", "cancelled"]. This constrains the model's output space and dramatically reduces invalid calls.
  • Write clear descriptions. The description field in your schema is essentially a prompt. "Gets weather" is weak. "Returns current temperature in Celsius and conditions for a given city name" is strong.

Error Handling & Recovery

What happens when a tool call fails? This is where interviewers separate juniors from seniors.

  • Validation layer: Validate the LLM's generated parameters before executing the tool. Use Pydantic or JSON Schema validation. If validation fails, feed the error back to the LLM with a clear message: "Parameter 'date' must be in YYYY-MM-DD format, got '2026/08/06'."
  • Retry with context: Don't just retry silently. Include the error message in the next LLM call so it can self-correct. Cap retries (usually 2-3) to prevent infinite loops.
  • Graceful degradation: If a tool is unavailable (API timeout, rate limit), the agent should be able to continue without it — either by using cached data, skipping the step, or informing the user.

Multi-Step Tool Chains

Real agents rarely make a single tool call. They chain tools: search → retrieve → summarize → email. The interview tests your understanding of:

  • Data flow: How does output from Tool A become input to Tool B? Do you pass it through the LLM (more flexible, higher latency) or directly (faster, but brittle)?
  • Idempotency: If the agent retries a chain, will it send duplicate emails or charge a credit card twice? How do you make tool calls idempotent?
  • Parallel vs. sequential: Can some tools run in parallel? How do you express this in your agent framework?

Common Interview Questions

Q1: "Design a tool schema for an agent that can book meeting rooms."

What they're testing: Can you design a clean, constrained schema? Do you think about edge cases?

Strong answer elements:

  • Parameters: room_id (enum of available rooms), date (string, ISO format), start_time and end_time (string, HH:MM), attendees (array of email strings)
  • Validation: Check that end_time > start_time, date is not in the past, room exists
  • Return value: Confirmation object with booking ID, or error with reason (conflict, capacity exceeded)
  • Edge case: What if the room is booked between the validation check and the actual booking? → Use optimistic locking or a reservation hold pattern

Q2: "An agent keeps calling the wrong tool. How do you debug and fix this?"

Strong answer elements:

  • First: Check tool descriptions — are they ambiguous? If two tools sound similar, the model will mix them up. Make descriptions mutually exclusive.
  • Second: Check if there are too many tools. Models degrade with >15-20 tools. Consider tool selection routing: use a classifier to filter to 3-5 relevant tools before the LLM call.
  • Third: Add few-shot examples in the system prompt showing correct tool usage for common queries.
  • Fourth: Log all tool calls with the model's reasoning. Look for patterns — is it consistently confusing two specific tools?

Q3: "How do you handle side effects in tool calls?"

What they're testing: Do you understand that LLMs can hallucinate tool calls? A "send_email" tool that fires on every retry is dangerous.

Strong answer: "I separate read tools from write tools. Read tools (search, lookup) are safe to retry. Write tools (send_email, create_order) require a confirmation step — either human approval or a 'dry run' mode where the agent generates the action but doesn't execute it until confirmed. For critical operations like payments, I'd use an idempotency key so duplicate calls are no-ops. At Stripe, for example, this pattern is essential for any agent touching financial APIs."

The Practitioner's Edge

Generic candidates talk about tool-calling as "just API calls." Strong candidates discuss:

  • Observability: Logging every tool call with input params, output, latency, and the LLM's reasoning for making the call. This is how you debug agents in production.
  • Cost awareness: Each tool call involves at least one LLM round-trip. In a chain of 5 tools, you're burning 5x the tokens. Discuss batching, caching tool results, and when to short-circuit the chain.
  • Security: Never expose raw database queries or system commands as tools. Always sanitize inputs and use allowlists for tool parameters. An LLM can be prompt-injected into calling tools with malicious parameters.

Continue the Agentic AI Series: