Tool Calling enables LLMs to interact with external systems by defining structured interfaces for function invocation. The model detects when to call tools, extracts the correct parameters, and processes responses. This pattern extends LLM capabilities beyond text generation to real-world action execution.
How it works
Tool Definition: Define available tools with schemas for parameters and returns
Tool Invocation: Model decides which tool to call based on user intent
Parameter Extraction: Model generates structured arguments matching the schema
Execution: External system processes the tool call and returns results
Response Integration: Model incorporates tool output into final response
Tool types
Search: Web search, database query, vector retrieval
Compute: Calculator, code execution, data processing
Action: API calls, workflow triggers, device control
Information: Knowledge base lookup, entity resolution
Best practices
Use structured schemas for parameter validation
Implement retry logic for transient failures
Validate tool responses before model consumption
Set clear boundaries on allowed tool operations
Log tool usage for debugging and compliance
Build This Pattern
Copy this prompt and paste it into Claude Code, OpenCode, Codex, or Cursor to implement this pattern.
Build me a tool-calling system for LLMs. Architecture: define a tool registry where each tool has a name, description, JSON Schema for parameters, and a handler function. The LLM receives available tool definitions and decides when to call them. Implement automatic parameter extraction from LLM response (parse tool_call JSON), parameter validation against schema before execution, and result formatting for the LLM. Use a dispatcher pattern to route tool calls to handlers. Support both OpenAI function-calling format and Anthropic tool-use format via an adapter layer. Error handling: implement retry logic on tool failure (2 retries with exponential backoff). If parameter validation fails, return descriptive validation error to the LLM so it can correct. Handle handler exceptions by catching and returning a friendly error message. Edge cases: handle LLM requesting a nonexistent tool by returning a tool_not_found error. Support tools with empty parameter schemas. Handle tools returning very large results by truncating or summarizing. Manage concurrent tool executions with proper isolation. Best practices: include example tools: search_web, calculate, get_weather, send_email. Add rate limiting per tool. Log all tool calls with parameters, result, and latency. Set tool execution timeout (default 10s). Testing: unit test parameter extraction and validation. Integration test each tool handler. Test error recovery by mock-failing tools at different stages. TypeScript.