Agent Skills: How to Package Reusable Capabilities Without Overloading Context
August 26, 2026
NVIDIA DGX Spark 4 TB Review: A Local AI Lab Not a Tiny Gaming PC
August 30, 2026
Tools turn an AI system from a text generator into an actor. They also create the point where a probabilistic decision meets a deterministic API and, potentially, the real world. Good tool design therefore has two audiences: the model that must select and call the interface, and the control layer that must keep the call within policy.
Make each tool’s purpose obvious
Anthropic’s engineering guidance treats tool design as a contract between deterministic software and a non-deterministic agent. Names and descriptions must distinguish one capability from another. Parameters should express the information required for a safe call, not invite the model to improvise missing values.
Prefer get_customer_order and prepare_refund_request over a generic manage_customer. A narrow tool makes selection, permissions and evaluation easier.
Separate reading from changing
Read tools gather information. Write tools create consequences. Keep them distinct even when they access the same service. This lets the system grant read-only access during evaluation and require approval for mutations.
Parameters can change risk. Reading one public document is not equivalent to exporting an entire private repository. Sending a draft to the current user is not equivalent to emailing a list. Validate values, not only the tool name.
Return useful observations
The model needs enough output to choose the next step. It rarely needs a raw database dump or a complete HTML page. Return structured fields, stable identifiers, clear error states and source metadata. Store large payloads outside context and provide a preview plus a retrievable reference.
Where MCP fits
Model Context Protocol standardizes how AI applications connect to tools and data. It can reduce duplicated integration work and support a portable ecosystem. The 2026 specification adds a stateless core, stronger routing signals, cacheable discovery and authorization changes that make ordinary infrastructure patterns easier to apply.
MCP does not certify that a server is trustworthy. The client or runtime must still decide which server to connect, which tools to expose, what credentials are used and when a human must approve a call.
A tool acceptance matrix
| Question | Read tool | Write tool |
|---|---|---|
| Is the source trusted? | Required | Required |
| Are arguments schema-validated? | Required | Required |
| Is action-time approval needed? | Sometimes | Usually for material impact |
| Is the output logged? | Yes, with privacy controls | Yes, with before/after state |
| Is rollback required? | Usually not | Yes where feasible |
When not to expose a tool
Do not create a tool when ordinary application code can perform the step without model judgment. Do not expose administrative endpoints merely because an integration makes it easy. If an operation has no safe validation, approval or recovery path, keep it outside the agent’s action space.
Read MCP Is Becoming Infrastructure for the protocol update, AI Agent Safety for the permission model and Agent Observability for tracing tool calls.
Primary sources
- Anthropic: Writing effective tools for agents
- MCP 2026 specification release
- OpenAI Agents SDK: tools and observability
Adaptation note: This article was informed by the tool-design treatment in AI Agents in Depth: Design Principles and Engineering Practice by Bojie Li and contributors, Apache License 2.0. It was independently rewritten and expanded with current primary documentation.
