agent-tool-design

Reviews and designs LLM tool schemas, descriptions, error messages, and return shapes.

Updated Aug 2, 2026
One-click install
npx skills add https://github.com/dperussina/function2agent --skill agent-tool-design-dperussina
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: agent-tool-design
Source: https://github.com/dperussina/function2agent/tree/main/.cursor/skills/agent-tool-design
Command: npx skills add https://github.com/dperussina/function2agent --skill agent-tool-design-dperussina

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Poorly designed tools cause agents to pick the wrong tool, hallucinate IDs, retry permanently-failing calls, and burn context on oversized results. This Skill provides a review checklist and design rules for tools exposed to an LLM so every name, description, parameter schema, error message, and return shape is optimized for model selection and token efficiency. ## Core Features & Use Cases - Pre-ship review checklist: Validates verb-first namespaced names, disambiguating descriptions, enum-constrained parameters, minimal required sets, and declared read_only metadata. - Error message design: Treats errors as prompts that state what was wrong, the valid space, the next action, and whether the failure is transient or terminal. - Token-efficient returns: Enforces summary-plus-handle patterns, projection support, hard-capped output with announced truncation, and machine-actionable structure. - Tool-set sizing: Applies the 30-50 tool confusion threshold with an escalation ladder covering deferred loading, tool search, and code execution, plus MCP security posture guidance. - Use Case: When defining an MCP server or function-calling schema, run the checklist to catch near-synonym tools, opaque ID parameters, and uncapped payloads before they degrade agent behavior. ## Quick Start Ask the agent to review your tool definitions against the agent tool design checklist and fix any naming, description, error message, or return shape defects it finds.

Frequently Asked Questions about agent-tool-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design tools for an LLM agent?▼

Use verb-first namespaced names, descriptions that state when to use and when not to use the tool, flat parameter objects with enums for closed domains, and errors returned as observations. Run a pre-ship checklist covering naming, disambiguation, error taxonomy, and return shape.

How many tools can an AI agent handle before accuracy drops?▼

Tool selection accuracy degrades once an agent has more than 30-50 available tools. Fixes include role-scoped allowlists, deferred loading with a tool search tool, and code execution for fan-out and filtering workloads.

How should tool error messages be written for LLM agents?▼

Error messages should state what was wrong, the valid value space, the next action, and whether the failure is transient or terminal. Return errors as observations rather than throwing exceptions so the agent can recover.

Why does my agent pick the wrong tool or hallucinate IDs?▼

Wrong-tool selection usually comes from near-synonym tools or descriptions that fail to disambiguate against siblings. Hallucinated IDs happen when a parameter requires an opaque identifier the model has no discoverable way to obtain.

Should I use MCP as the internal calling convention for agent tools?▼

MCP works well as an export surface but not as an internal calling convention, since connector tools block code execution mode and the trust model forces boundary re-validation. Treat every MCP server as untrusted input and pin and hash tool schemas at onboarding.

How do I reduce token usage from tool definitions and results?▼

Cap tool results with summary-plus-handle patterns and announced truncation, and defer loading of rarely used tool definitions behind a search tool. Code execution can cut input tokens further but roughly doubles output tokens and adds a sandbox boundary.