Basic Tool
UsecreateTool with a zod schema for the simplest approach:
execute function.
For working examples of tools in real agents, see the cli-agent (shell tool with zod) and code-review-bot (multiple tools with completion lifecycle).
Anatomy of a Tool
Every tool has four parts:| Field | Purpose |
|---|---|
name | Unique identifier (snake_case recommended) |
description | LLM reads this to decide when to use the tool |
inputSchema | Zod schema or JSON Schema defining accepted arguments |
execute | Function that does the work |
The Name
Usesnake_case. Keep it descriptive but concise:
search_database, notdborperformDatabaseSearchOperationsend_email, notemailorhandleEmailSending
The Description
This is the most important field for tool call accuracy. The LLM uses it to decide when and how to use the tool.- What the tool does
- What it returns
- When to use it (and when not to)
- Constraints (rate limits, read-only, max results, etc.)
The Input Schema
With zod, use.describe() on every field:
z.enum for fields with a fixed set of values. This dramatically improves accuracy.
Using AgentToolContext
Theexecute function receives a context object with execution metadata:
Error Handling
Return errors as structured data rather than throwing:Completion Tools
Mark a tool withlifecycle: { completesRun: true } to make it end the agent loop when called successfully:
Testing Tools
Test your tools in isolation before giving them to an agent:Registering Tools
- Cline Core
- Agent
- Via Plugin
Tool Design Rules
Good tools are specific and predictable.- Use action-oriented names:
get_pull_request,search_database,deploy_service. - Describe what the tool does, when to use it, and what it returns.
- Put constraints in the description: rate limits, read-only behavior, required permissions.
- Add descriptions for every input property.
- Return structured JSON instead of prose when possible.
- Respect
context.abortSignalin long-running tools.

