Tool Calling

A tool call is a request, not an execution

Tool calling became a common API capability when model providers exposed function descriptions and JSON Schema parameters alongside a prompt. The capability solved a concrete boundary problem: a model can propose an operation, but only application code has credentials, network access, and authority to perform it.

The host sends the available tool names and schemas. The model returns a tool choice and arguments, the host validates and executes them, and the tool result enters the next model turn.

Function calling, structured output, and MCP solve different boundaries

Function calling is a provider name for tool calling. Structured output constrains the shape of a response but does not imply that any function will run.

The Model Context Protocol standardizes how clients discover and invoke tools across a connection; it does not replace the tool-call loop inside the host.

Tool selection and argument generation are separate failures

A model can choose the wrong tool with perfectly valid arguments, or choose the right tool with a malformed identifier. Logs and evaluations should preserve both decisions so a routing failure is not mistaken for a schema failure.

The host can also remove tools that are irrelevant to the current step. A smaller allowed set reduces accidental selection and prevents a later prompt from reaching capabilities the task never needed.

The host owns safety after the model chooses a tool

The same tool schema can serve a harmless lookup and a destructive operation, so syntax alone cannot set the policy. The host needs rules for identity, argument ranges, side effects, confirmation, retries, and result handling.

Those rules should be enforced before execution and recorded with the request. A model explanation of why an action seems safe is not a substitute for the policy decision.

A safe weather lookup has two validation layers

Suppose a model returns {"city":"Pune","units":"metric"} for a get_weather tool. Schema validation can reject an unknown unit, while application policy can reject a location the user is not authorized to query.

A valid JSON object is not proof that the request is safe.

The MCP architecture guide shows how this boundary extends across clients and servers. Tool calling is unnecessary for facts already present in context, and its common misuse is treating a schema-valid request as permission to execute it.

Retries must account for side effects

A timed-out weather lookup can usually be repeated. A timed-out payment or ticket-creation call may already have succeeded, so a blind retry can duplicate the action.

Mutation tools need an idempotency strategy or a read-after-write check that resolves an uncertain result. Returning the tool error to the model without that protection shifts a distributed-systems problem into generated text.

Tool results are untrusted context too

A tool can return malformed data, stale records, or text containing instructions that should never override the host policy. The application should label the result as data, validate the expected shape, and limit what the next model turn may do with it.

Continue with these glossary entries:

• Agentic Engineering
• Model Context Protocol (MCP)