Tool Use, Function Calling, and Computer Use
Tool use lets a model ask software to do work.
The model should not directly execute arbitrary actions. It should request a typed tool call, and your app decides whether to run it.
Tool-call loop
text
user goal -> model chooses tool -> app validates args -> tool runs -> model observes result -> final answer
Good tool design
Each tool needs:
- clear name
- narrow purpose
- typed arguments
- validation rules
- permission checks
- safe error messages
- audit logging
Function calling vs computer use
| Tool style | Best for |
|---|---|
| API/function call | reliable structured systems |
| MCP tool | reusable cross-client tools |
| browser/computer use | systems without APIs |
Prefer APIs when available. Use computer use only when the UI is the interface.
Risky tools need approval
Require approval for:
- sending email
- deleting data
- spending money
- changing permissions
- deploying code
- accessing sensitive records
Knowledge check
Q1: Who should validate tool arguments?
Your application, not only the model.
Q2: Why are narrow tools safer?
They limit what the model can ask the system to do.