Interview: Tools and Function Calling

What you will be able to do

• ✓Explain native function calling step by step
• ✓Design good tool names, descriptions and schemas
• ✓Validate and secure tool calls
• ✓Handle models without native tool calling
• ✓Scale to many tools

The idea, in plain English

Tools are what turn a chatbot into an agent, so interviewers go deep here: how the model "calls" a function, what a tool schema looks like, and what happens when a call goes wrong.

The most important idea to get across: the model only REQUESTS a call. Your code decides whether to run it, with which checks, and what to send back.

You built this by hand in Lessons 1.5 and 1.7, then with LangChain (2.6), LangGraph (3.5), MCP (Module 4) and CrewAI (Module 7).

Worked example: Fourteen questions on tool use, tied to the manual tool calling of Module 1 and the tool nodes of LangGraph and CrewAI.

Basic: How does function calling work?

You send the model a list of tools, each with a name, a description and a JSON schema for its arguments. When a tool would help, the model replies with a structured call - name and arguments - instead of text. Your code runs the function and sends the result back; the model then continues.

• •The model never executes anything.
• •The loop of request -> run -> result is the agent loop.
• •Lesson 1.5 does it manually, without any framework.

Basic: What makes a good tool description?

It says what the tool does, when to use it, and what each argument means - in plain words the model can match to a user's request.

• •Clear name: get_weather, not tool1.
• •Say what it does NOT do, to avoid wrong picks.
• •Describe units and formats ("city name in English").

Basic: What is a tool schema?

A JSON Schema that lists a tool's arguments, their types, which are required, and allowed values. Frameworks often build it from a Python function's type hints and docstring.

• •Types and enums reduce bad arguments.
• •Keep arguments few and simple.

Intermediate: How do you validate tool arguments?

Parse the arguments into a typed model (Pydantic) before running the tool, check ranges and allowed values, and return a clear error to the model if something is wrong, so it can correct itself.

• •Never pass raw model output into a shell, SQL query or file path.
• •A validation error is information for the model, not a crash.

Intermediate: What happens if a tool fails?

Catch the error and return it as the tool's result - for example "City not found, use an English city name". The model can then retry with better input or choose another route. Retry temporary failures (timeouts) in code, with a limit.

• •Distinguish user errors, temporary errors and bugs.
• •Limit retries so a broken tool does not loop forever.

Intermediate: What if the model does not support native tool calling?

Describe the tools in the prompt and ask the model to answer in a fixed text or JSON format ("Action: ... Action Input: ..."), then parse that format in code. This is how ReAct worked before native tool calling.

• •Parsing is less reliable - validate and retry on bad formats.
• •In Module 7, llama3 refused native tool calls and CrewAI fell back to a text format.

Intermediate: What are parallel tool calls?

Some models can request several tool calls in one turn when they do not depend on each other - for example the weather in three cities. Running them in parallel saves time.

• •Only for independent calls.
• •Your code must handle each result, including partial failures.

Intermediate: How do you keep tool results from overflowing the context?

Return only what the model needs: trim, filter or summarise large results, paginate, and give IDs the model can use to ask for more.

• •A 10,000-row query result in the prompt is cost, noise and maybe a cut-off.
• •Structure results so the important fields come first.

Advanced: How would you handle an agent with 100 tools?

Do not give all 100 to the model at once. Group tools, select a relevant subset per request (by retrieval over tool descriptions or a router), or split the work across specialised agents.

• •Too many tools confuse the model and fill the context.
• •Measure tool-selection accuracy as tools are added.

Advanced: How do you secure tools that change things - payments, emails, deletions?

Apply least privilege: give the agent only the tools and permissions the task needs, separate read from write tools, validate every argument, require human approval for risky actions, rate-limit, and log every call.

• •Make write tools idempotent where possible (safe to retry).
• •Never let tool input come straight from untrusted text without checks.

Advanced: What does idempotent mean for a tool, and why does it matter?

An idempotent tool gives the same result if called twice with the same input - like "set status to paid" rather than "add Rs 500". Agents and retries can repeat calls, so idempotent tools prevent double actions.

• •Use request IDs to detect duplicates.
• •Especially important for payments and messages.

Advanced: How do you test tools and tool selection?

Unit-test each tool like normal code. Separately, test the agent's choices: a set of requests with the tool and arguments it should choose, scored automatically.

• •Tool selection is a model behaviour - it changes with prompts and models.
• •Keep these tests in your evaluation set (Module 5).

Advanced: What is the difference between a tool, a resource and a prompt in MCP?

A tool is an action the model can call. A resource is data the application can read and give as context. A prompt is a reusable prompt template offered by the server.

• •Tools are model-controlled; resources are application-controlled; prompts are user-chosen.
• •Module 4 builds all three.

Advanced: Function calling vs letting the model write code - when would you choose code?

Function calling is safer and easier to control. Letting the model write and run code is more flexible for data analysis or complex logic, but needs a sandbox with no network, file or time access beyond what is required.

• •Code agents need strong isolation.
• •Start with tools; add code execution only with a real need.

Interview questions