PMaker home
Search
中EN
System
Color theme
空格的键盘
空格的键盘空格的键盘产品经理 · AI Builder
A model's "call" is really a request — your code does the actual work1. Send the tool listYour code sends each tool's name, parameter shape, and usage descriptionHow well the description is written decides whether the model uses it right2. Model writes a callThe model emits a structured request in its reply, usually JSONThe format follows the API spec; underneath it is just text3. Parse and executeYour code parses, validates arguments, calls the function, catches errorsArguments cannot be trusted; validation belongs at execution4. Feed the result backWrite the result or error back into the context so it can plan the next stepErrors that never return cause retries until the agent hangsThree of the four boxes are your code — it writes requests, does the work, and hands back what it needs to see

The model executes nothing. It only outputs "I want to call this tool with these arguments"; the actual action is performed by your code.

Tool Calling

The model can't do anything by itself. You lend it your hands; only then can it touch the world.

"It calls APIs and queries data by itself" is the most common misunderstanding about agents. The model cannot call a single interface. All it can do is write a structured request in its reply; everything else is your code.

Symptoms you'll recognize:

  • You expect that connecting a database means the model will query it.
  • The model passes wrong arguments, and you do not know who to blame.
  • You do not know what the tool list means to the model, so you stuff dozens of tools into it.

It doesn't actually call

Everything the model does is "given the context, output the next token." Tool calling is just it writing a piece of text in a specific format, usually JSON saying "call query_order with order number A1024."

Once that sentence is written, the model's job is done. No code runs because of it. The code that actually queries the order, sends the email, or modifies the database is yours. It sees the JSON, parses it, calls the function, and puts a tool result back into the context.

That is what "you lend it your hands" means: the model decides what to do, you do it, and you hand back what it needs to see. It lives entirely in the world of text. The ReAct paper, which first established the "reason, then act" pattern, emphasized exactly this division: the model thinks and writes, the outside world executes. react-paper

What one call looks like

The full loop:

  1. You send the tool list. Each tool gets three things: a name, a parameter structure (types and meanings), and a description of what it does and when to use it. The description's quality directly decides whether the model uses it correctly.
  2. The model outputs a call request. The format follows the API; OpenAI and Anthropic each document their own, but underneath it is the same: a structured text declaring which tool and which arguments. openai-function-calling claude-tool-use
  3. Your code executes. Parse, validate, call the function, catch errors.
  4. Return the result. Pack the outcome, data or error, into text and resend it with the conversation. The model reads it and plans the next step.

Note step four: errors must come back too. "Query failed: order not found" is exactly what the model needs to retry with different arguments or to tell the user it cannot find it. Many agents hang simply because failure results never flowed back.

Designing the tool list

The tool list is an instruction manual for the model; its quality decides whether the model reaches correctly. Three lessons.

Few and clear beats many and complete. More tools means more wrong picks and more context consumed. Only include tools this task might use. Dozens of vague tools usually perform worse than three well-written ones.

Write "when to use and when not to." For example: "'query_order: look up order details by order number. Use only when the user provided an order number; order numbers usually start with A followed by digits'" is far more useful than "query orders."

Be rigorous with parameter names and types. The model copies your names. Give it order_id and it passes order_id; give it id and it passes id. Vague naming carries mistakes all the way to execution.

One thing people overlook: tool stability. Your function changes its signature, but the model still emits the old parameter format, and requests fail. Version your tool changes, or build parameter tolerance into the code.

Three pitfalls

Tools are not free. Each one needs execution logic, error handling, concurrency, and timeouts. More tools, more engineering debt.

Do not forget they are your tools. The model will call anything you list, including tools with side effects. Where you need tiered permissions and human checkpoints, add them. And see prompt injection: external data can trick the model into calling a tool it should not.

Do not treat tool results as ground truth. Tool data can be wrong, stale, or from an untrustworthy source. The model can confidently fabricate from bad data just as easily. The longer the chain, the more you should verify after critical actions.

References

  1. Tool use with Claude — Anthropic
  2. Function calling — OpenAI
  3. ReAct: Synergizing Reasoning and Acting in Language Models — arXiv