Module 3 — Tool Use
Lesson notes
A tool is a controlled interface through which a model can observe the world or request an action. The model does not execute a function by wishing; it emits a structured call, application code validates and runs it, and the result becomes the next observation.
Creating a useful tool
A tool needs:
- a precise, action-oriented name;
- a description saying when to use and not use it;
- a narrow input schema with required fields and constraints;
- a stable structured result;
- explicit error states;
- authentication and authorization outside the model;
- timeouts, retries, idempotency, logging, and rate limits as appropriate.
Prefer small, composable tools over a vague do_everything tool. Return only the information needed for the decision.
Tool syntax and the control loop
Tool schemas are contracts. Validate arguments before execution and validate outputs before returning them to the model. Unknown tools, malformed arguments, timeouts, permission denials, and empty results are normal states that the workflow must handle.
Functions into tools
Existing functions become safe tools only after their interfaces are tightened. Remove ambient assumptions, give inputs explicit types, make side effects visible, normalize errors, and add policy checks. A function that is safe for trusted application code may not be safe for model-selected execution.
Email-assistant workflow
Classify the message, retrieve relevant thread/contact context, choose a permitted action, draft a response, and request approval before sending. Reading and drafting may be automatic; sending, deleting, forwarding sensitive data, or changing a calendar should normally require confirmation.
Code execution
Execution gives strong feedback for mathematics, data transformation, tests, and charting. Isolate it with a sandbox, resource limits, restricted filesystem/network access, dependency controls, and captured stdout/stderr. Treat generated code as untrusted.
Model Context Protocol (MCP)
MCP standardizes how AI applications connect to external capabilities. A client communicates with servers that expose tools and contextual resources through discoverable schemas. It reduces one-off integrations, but it does not remove the need for trust boundaries, least privilege, user consent, or defenses against malicious tool output.
Tool-selection checklist
- Is fresh, private, or exact information required?
- Can ordinary code make this decision more reliably?
- What is the smallest permission the tool needs?
- Is the action reversible or idempotent?
- What must a human approve?
- How will calls and outcomes be audited?
- Could tool output contain prompt injection?