Without tools, a model can only advise. With them, an agent can read, search, send and change real state. This is where capability and risk grow together.
A good tool expresses capability, boundaries, cost, failure mode and whether it can be undone.
01 / THREE TOOL TYPESSeparate perception, execution and collaboration first
Perception tools read the world; execution tools change it; collaboration tools delegate to people or other agents. Their risks differ, so they must not share default permissions. Perception reads files, the web, databases or a screen. Execution writes files, submits forms, sends messages, pays or publishes. Collaboration delegates work, asks for human confirmation or synchronizes another system.
02 / PRACTICEChoose tool granularity around verifiable action
One large general tool is convenient but makes parameters complex and failures hard to locate. Tools split too finely make the model call too many times. A useful size corresponds to one clear, checkable and retryable business action. Repeated methods belong in a Skill; a tool is for capability that really accesses an external system. This pairing is easier to maintain than a new API for every task.
03 / PRACTICEDescriptions, parameters and returns must preserve meaning
A tool’s name and description affect whether the model selects it. Its parameter schema determines whether execution can land; its return structure determines whether the next round can judge success. Dates, amounts, paths and enum values must not become vague in an intermediary. Describe suitable and unsuitable use; validate high-risk parameters with enums, ranges and required fields; return real state, error cause and retry advice; and distinguish request accepted from action completed.
04 / MCPMCP standardizes connection, not tool choice
MCP lets different agents discover and call external capability through a common protocol, reducing integration cost. It does not remove the problems of selection, permissions or context use when tool lists grow. MCP servers should still be organized by domain, expose lists when needed, and use permission and approval gates for actions that change outside state.
05 / PRACTICELong work needs events, not a conversation held open
Approvals, builds, uploads and human replies can last minutes or days. An asynchronous agent saves state, resumes when an event arrives and explains current progress. Virtual identities and isolated environments can limit the scope of credentials and files, so a long-running agent does not receive unlimited power.
06 / DISCOVERY & SAFETYTool discovery must still follow least privilege
At scale, an agent can search a tool directory or load a relevant Skill before choosing a call. Discovery cannot bypass authorization: finding a tool does not grant its permission. In legal work, an agent may read one designated case directory, draft and check missing materials. Sending outside, deleting originals, changing deadlines or filing a formal document must stop before human confirmation. First exercise: draw a case-organizing flow, mark each tool read-only, writable or externally sending, then give the latter two confirmation and rollback paths.
Source book and chapter references
- bojieli/ai-agent-book.
- Chapter 4 — tools and MCP.
- Chapter 4 experiments.
- This is an applied reorganization, not a replacement for the source book; use the source text and code for exact claims.
READER COMMENTS
Leave the thought this article gave you.
No comments yet. You can leave the first one.