Claude Tool/Function Builder

What This Tool Does

The Claude Tool/Function Builder is a visual interface for creating tool definitions that conform to the Anthropic Messages API tool use specification. Instead of hand-writing JSON schema by trial and error, you define your tools through form fields and the builder generates the complete tool definition object, including the input_schema with proper JSON Schema types, descriptions, required fields, enum constraints, and nested structures. The output updates in real time as you modify any field.

Tool use is one of the most powerful features of the Claude API. It allows Claude to call external functions, query databases, interact with APIs, and perform actions in the real world. However, the tool definition format has specific requirements that are easy to get wrong: the schema must be valid JSON Schema draft 2020-12, property descriptions affect Claude's tool selection accuracy, and the required array must list mandatory fields. This builder handles all of these requirements automatically while generating code you can drop directly into your application.

Understanding Tool Definitions

Every Claude tool definition consists of three required fields. The name is a unique identifier in snake_case format that Claude uses to reference the tool. Choose descriptive names like get_weather, search_database, or send_email rather than generic names like tool_1. Claude uses the name as a semantic signal when deciding which tool to call, so a clear name improves selection accuracy.

The description is plain text that tells Claude what the tool does, when to use it, and what it returns. This is the single most important field for tool selection accuracy. A good description includes the purpose, trigger conditions, and output format. For example, "Search the product database by name or category. Use this when the user asks about products, prices, or availability. Returns a JSON array of matching products with name, price, and stock count." Bad descriptions like "Search tool" give Claude insufficient context to make good decisions.

The input_schema is a JSON Schema object that defines the parameters Claude must provide when calling the tool. Each property has a type (string, number, integer, boolean, array, or object), an optional description, and optional constraints like enum, minimum, maximum, or pattern. The required array lists parameters that must always be present. Optional parameters should have sensible defaults in your tool implementation.

Supported Parameter Types

The builder supports all JSON Schema types that the Claude API accepts. String parameters are the most common, used for text inputs like names, queries, and identifiers. Add an enum constraint to restrict values to a predefined list, such as ["celsius", "fahrenheit"] for a temperature unit parameter. The pattern constraint accepts a regular expression for input validation, like ^[A-Z]{2}$ for a two-letter country code.

Number and integer parameters accept numeric values with optional minimum and maximum constraints. Use integer when you need whole numbers (like page numbers or quantity), and number when decimal values are valid (like latitude/longitude or price). Claude reliably generates numbers within the specified range when constraints are provided in the schema.

Boolean parameters are simple true/false flags. Use them for toggles and binary options. Array parameters accept a list of values with an items schema that defines the type of each element. For example, an array of strings for tags, or an array of objects for structured data. Object parameters allow nested structures with their own properties and required fields, enabling arbitrarily complex input schemas. For comparing how different models handle tool definitions, LockML provides model comparison tools.

The Tool Use Conversation Flow

Tool use follows a specific request-response cycle. First, you send a request with a tools array containing your tool definitions and a messages array with the user's message. Claude analyzes the message and decides whether to call a tool. If it decides to use a tool, the response has a stop_reason of "tool_use" and the content array contains a tool_use block with the tool name, a unique ID, and the generated input arguments.

Your application then executes the actual function using the provided arguments and returns the result in a new message. This message has the role "user" and contains a tool_result content block with the tool_use_id from the previous response and the result as a string or content blocks. Claude processes the tool result and generates a final text response to the user. The entire cycle takes two API calls: one that triggers the tool call, and one that processes the result.

Claude can also decide that no tool is needed and respond with text directly. The tool_choice parameter lets you control this behavior. Set it to "auto" (default) to let Claude decide, "any" to force tool use, or {"type": "tool", "name": "tool_name"} to force a specific tool. For webhook-driven architectures where tool calls trigger external actions, InvokeBot provides webhook management tools.

Best Practices for Tool Definitions

Write descriptions as if you are explaining the tool to a new team member. Include what the tool does, when it should be used versus other available tools, what format the input should be in, and what the output looks like. Claude reads these descriptions to decide tool selection, so vague descriptions lead to incorrect or missed tool calls. A description of 50 to 150 words typically provides enough context without being wasteful.

Make parameter descriptions specific and include examples. Instead of describing a location parameter as "The location", write "The city and state/country, e.g., 'San Francisco, CA' or 'London, UK'. Use the most specific location the user mentions." This helps Claude generate accurate parameter values that your function can parse reliably. Parameter descriptions are part of the input token count, so keep them informative but concise.

Use the required array judiciously. Only mark parameters as required when your function truly cannot operate without them. Optional parameters should have sensible defaults in your implementation. This gives Claude flexibility to omit parameters when the user does not specify them, resulting in more natural conversations. If a parameter has a clear default value, mention it in the description: "The number of results to return (default: 10, max: 100)."

Test your tool definitions with the sample input validator in this builder before deploying to production. Common issues include mismatched enum values, overly restrictive patterns that reject valid input, and required parameters that should be optional. The validator checks that sample inputs conform to your schema and shows any validation errors. For comprehensive API testing including tool use flows, use the ClaudKit API Request Builder to construct the full request.

Code Output Formats

The JSON Schema tab shows the raw tool definition object exactly as it appears in the tools array of an API request. This is useful for developers who want to store tool definitions in configuration files or databases and load them dynamically. The schema follows JSON Schema draft 2020-12 and is fully compatible with the Anthropic Messages API.

The Python output uses the official anthropic SDK with the tools parameter in client.messages.create(). The tool definition is embedded directly in the code as a Python dictionary. Install the SDK with pip install anthropic. The generated code includes the complete message flow: sending the initial request, checking for tool use, and handling the response.

The JavaScript output uses the official @anthropic-ai/sdk package with async/await syntax. Install with npm install @anthropic-ai/sdk. The tool definition is embedded as a JavaScript object. Like the Python output, it includes the complete tool use conversation flow. The curl output provides the full HTTP request body for terminal testing, with the tool definition embedded in the JSON payload. For monitoring LLM costs across tool-use-heavy applications, KickLLM offers cost tracking dashboards.