
Agent Tool Builder
Design agent-callable tools with tight JSON schemas, LLM-friendly descriptions, validation, and explicit errors so function calling stays accurate and cheap on tokens.
Overview
Agent Tool Builder is an agent skill for the Build phase that teaches how to design function-calling and MCP-style tools—from schema and descriptions through validation and error handling—so agents invoke capabilities re
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill agent-tool-builderWhat is this skill?
- Treats tool descriptions as the primary interface—the model never sees your implementation code
- Recommends fewer than 20 tools per agent to reduce selection confusion
- Validation gates before execution: reject, fix, or escalate—no silent failures
- Return strings for tool results because LLMs process text, not opaque object blobs
- Covers JSON Schema, error handling patterns, and MCP as the emerging AI-tool interchange standard
- Aim for fewer than 20 tools per agent to limit confusion
- Tool descriptions matter more than implementations for LLM accuracy
Adoption & trust: 714 installs on skills.sh; 40.1k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent has code behind the tools, but vague schemas and silent failures make the model pick wrong functions, waste tokens, or act on garbage results.
Who is it for?
Indie builders adding custom tools to an agent stack or standardizing MCP tool definitions before wider rollout.
Skip if: Builders who only consume prebuilt MCP servers with no custom schemas and no need to author new callable surfaces.
When should I use this skill?
When designing agent tools, function calling, MCP tool surfaces, or fixing unreliable tool selection and silent failures.
What do I get? / Deliverables
You ship a small, well-described tool set with validation upfront and explicit error strings the agent can reason about on the next turn.
- Tool JSON schemas with LLM-oriented descriptions
- Validation and explicit error-response patterns for each tool
Recommended Skills
Journey fit
Tool schema and MCP-style surfaces are created while you assemble the agent product, before ship-time hardening. Canonical shelf for procedural knowledge about function-calling and MCP tool design—not a one-off integration recipe for a single SaaS API.
How it compares
A design-and-implementation methodology for agent tools—not a hosted MCP marketplace entry or a generic REST client skill.
Common Questions / FAQ
Who is agent-tool-builder for?
Solo and indie developers shipping AI agents who need to author or refine function-calling tools, JSON schemas, and MCP-compatible tool descriptions.
When should I use agent-tool-builder?
During Build when you define new agent tools, shrink an overcrowded tool list, fix silent tool failures, or align descriptions with MCP conventions before agents touch production data.
Is agent-tool-builder safe to install?
It is procedural guidance for tool design; review the Security Audits panel on this Prism page and treat any generated tool code like your own—scope permissions and secrets deliberately.
SKILL.md
READMESKILL.md - Agent Tool Builder
# Agent Tool Builder Tools are how AI agents interact with the world. A well-designed tool is the difference between an agent that works and one that hallucinates, fails silently, or costs 10x more tokens than necessary. This skill covers tool design from schema to error handling. JSON Schema best practices, description writing that actually helps the LLM, validation, and the emerging MCP standard that's becoming the lingua franca for AI tools. Key insight: Tool descriptions are more important than tool implementations. The LLM never sees your code - it only sees the schema and description. ## Principles - Description quality > implementation quality for LLM accuracy - Aim for fewer than 20 tools - more causes confusion - Every tool needs explicit error handling - silent failures poison agents - Return strings, not objects - LLMs process text - Validation gates before execution - reject, fix, or escalate, never silent fail - Test tools with the LLM, not just unit tests ## Capabilities - agent-tools - function-calling - tool-schema-design - mcp-tools - tool-validation - tool-error-handling ## Scope - multi-agent-coordination → multi-agent-orchestration - agent-memory → agent-memory-systems - api-design → api-designer - llm-prompting → prompt-engineering ## Tooling ### Standards - JSON Schema - When: All tool definitions Note: The universal format for tool schemas - MCP (Model Context Protocol) - When: Building reusable, cross-platform tools Note: Anthropic's open standard, widely adopted ### Frameworks - Anthropic SDK - When: Claude-based agents Note: Beta tool runner handles most complexity - OpenAI Functions - When: OpenAI-based agents Note: Use strict mode for guaranteed schema compliance - Vercel AI SDK - When: Multi-provider tool handling Note: Abstracts differences between providers - LangChain Tools - When: LangChain-based agents Note: Converts MCP tools to LangChain format ## Patterns ### Tool Schema Design Creating clear, unambiguous JSON Schema for tools **When to use**: Defining any new tool for an agent # TOOL SCHEMA BEST PRACTICES: ## 1. Detailed Descriptions (Most Important) """ BAD - Too vague: { "name": "get_stock_price", "description": "Gets stock price", "input_schema": { "type": "object", "properties": { "ticker": {"type": "string"} } } } GOOD - Comprehensive: { "name": "get_stock_price", "description": "Retrieves the current stock price for a given ticker symbol. The ticker symbol must be a valid symbol for a publicly traded company on a major US stock exchange like NYSE or NASDAQ. Returns the latest trade price in USD. Use when the user asks about current or recent stock prices. Does NOT provide historical data, company info, or predictions.", "input_schema": { "type": "object", "properties": { "ticker": { "type": "string", "description": "The stock ticker symbol, e.g. AAPL for Apple Inc." } }, "required": ["ticker"] } } """ ## 2. Parameter Descriptions """ Every parameter needs: - What it is - Format expected - Example value - Edge cases/limitations { "location": { "type": "string", "description": "City and state/country. Format: 'City, State' for US (e.g., 'San Francisco, CA') or 'City, Country' for international (e.g., 'Tokyo, Japan'). Do not use ZIP codes or coordinates." }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"], "description": "Temperature unit. Defaults to user's locale if not specified. Use 'fahrenheit' for US users, 'celsius'