Tool Use

When AI reaches beyond language into the real world.

// The Concept

Tool use is an AI model's ability to invoke external functions — web search, code execution, API calls, database queries, file operations — during generation. Instead of relying solely on knowledge baked into its parameters during training, the model decides when it needs external information or capabilities and calls the appropriate tool. This is what transforms a language model from an oracle that can only recite its training data into a system that can interact with the live, dynamic world.

Without tool use, a language model is powerful but fundamentally limited. It can only generate text based on patterns learned during training. Ask it for today's weather and it can only apologize — the answer isn't in its weights. Ask it to search the web and it can only describe what searching would look like. Ask it to run a calculation and it can only approximate the answer from pattern matching, which fails spectacularly on arithmetic with large numbers. Tool use removes these limitations. The model calls a weather API, invokes a web search function, or executes a calculation in a Python interpreter — and incorporates the real results into its response.

This is what makes AI agents possible. An agent is fundamentally a language model with tools. The model provides the reasoning — deciding what to do, interpreting results, planning next steps. The tools provide the capabilities — actually searching, actually reading pages, actually writing files, actually executing code. Strip away the tools and you have a chatbot. Add tools and you have an agent capable of autonomous multi-step task completion.

The concept has deep roots in cognitive science. Humans became the dominant species not because of raw brain power alone, but because of tool use — we extend our cognitive and physical capabilities through external instruments. A calculator extends our arithmetic capability. A search engine extends our memory. An AI model with tool use follows the same principle: the base model's language capabilities are extended through external tools that compensate for its inherent limitations. The model knows what it doesn't know, and it knows which tool can fill the gap.

// How It Works

The mechanism is surprisingly elegant. During generation, instead of producing the next text token, the model outputs a structured tool call: a function name and its parameters. The system intercepts this call, executes the tool, and returns the result to the model's context. The model then continues generating, now informed by real-world data it didn't have before. The entire exchange — tool call, execution, result — becomes part of the conversation context for subsequent reasoning.

The model learns WHEN to call tools through alignment training — specifically RLHF (reinforcement learning from human feedback). During training, human raters score the model's tool-use decisions: Did it call the right tool? Did it construct the parameters correctly? Did it call a tool when it should have just responded from knowledge? Did it skip a tool call when external data was needed? These ratings train the model to make sophisticated meta-cognitive judgments about when its internal knowledge is sufficient versus when it needs to reach for external tools.

MCP — Model Context Protocol — is Anthropic's open standard for tool interfaces, and it represents a fundamental shift in how AI systems interact with the world. Before MCP, every AI platform had its own proprietary tool format. OpenAI had function calling with one JSON schema. Anthropic had another. Google had yet another. MCP standardizes the interface: a tool server describes its capabilities in a universal format, and any MCP-compatible model can use those tools. Think of it as USB for AI — one standard connector that works with everything.

The implications of standardized tool interfaces are enormous. Any service can expose its capabilities as an MCP tool server. A database can expose query tools. A CMS can expose content creation tools. An analytics platform can expose data retrieval tools. Once exposed, any AI agent can use these tools without custom integration work. This creates an ecosystem where AI agents can compose capabilities from many different tool providers to accomplish complex tasks — without anyone having to build the integration manually.

// Why It Matters for Search

Here is the key insight: AI search IS tool use. When Perplexity.ai answers your question, it's calling a "web_search" tool to find relevant pages, a "read_page" tool to extract content, and a "cite" tool to attribute sources. When Google's AI Overview composes an answer, it's using retrieval tools against its index. When ChatGPT with browsing researches a topic, it's calling browsing tools to visit and read your pages. Every AI search product is a language model using search and retrieval as tools.

Understanding tool use helps you understand the mechanism by which your content gets discovered and cited. Your page isn't just a document in an index. It's a potential tool result. When an AI agent calls its web_search tool, your page appears in the results based on search relevance. When the agent then calls its read_page tool on your URL, the tool extracts your content and returns it to the model's context. The quality of what gets extracted — clean text, structured data, clear entity signals — determines whether the agent cites you, uses your information, or moves on to the next result.

This reframes every technical SEO practice. Sitemap.xml isn't just for Google's crawler — it's the discovery tool that AI agents' crawl functions use to find your pages. Schema markup isn't just structured data for rich snippets — it's machine-readable entity information that extraction tools can parse reliably. robots.txt isn't just access control for traditional crawlers — it's the permission layer that determines whether AI browsing tools (GPTBot, ClaudeBot, PerplexityBot) can access your content at all.

The rise of MCP creates a new opportunity. Instead of waiting for agents to crawl your website and extract information from HTML, you can expose your data directly as MCP tool endpoints. An MCP server for your business could let agents query your inventory, check your service availability, or access your expert knowledge base — returning structured, authoritative data without the lossy process of web crawling and HTML extraction. This is the difference between hoping an agent reads your menu PDF correctly and giving the agent a structured API that returns your menu in perfect JSON.

// In Practice

Make your content tool-friendly. This starts with the basics: clean, parseable HTML that extraction tools can process reliably. Semantic HTML elements — article, section, header, nav, main, footer — give extraction tools clear structural signals about which content is primary and which is navigation chrome. When an agent's read_page tool processes your HTML, semantic structure helps it extract the content that matters and discard the boilerplate.

Schema markup enriches tool results with structured data. When an extraction tool pulls your page, the JSON-LD in your head section provides machine-readable entity information that doesn't require natural language parsing to understand. The tool can return not just your page's text content but also structured facts: who authored it, what organization publishes it, what entity it's about, what credentials the author holds. This structured metadata makes your content dramatically more useful to the agent's reasoning process.

RSS feeds give tool-enabled agents a subscription mechanism. An agent monitoring a topic can check your RSS feed for new content without crawling your entire site. Sitemap.xml provides a comprehensive inventory of your pages that crawl tools use for systematic discovery. Both are machine-readable documents designed for automated consumption — exactly what tool-enabled agents need.

Check your robots.txt to ensure you're allowing AI crawlers. GPTBot (OpenAI), ClaudeBot (Anthropic), and PerplexityBot (Perplexity) are the primary AI search crawlers. Blocking them means your content is invisible to the fastest-growing segment of search traffic. Some sites block AI crawlers out of principle or concern about training data usage — but the practical effect is removing your content from AI-mediated discovery entirely. For most content creators, the visibility benefit of AI citations far outweighs the training data concern.

Think beyond the webpage. If you have structured data — product inventory, service catalogs, scheduling availability, knowledge bases — consider exposing it through MCP tool servers. This is cutting-edge, but it's the direction the ecosystem is moving. Agents that can query your data directly through structured tool interfaces will always get better results than agents that must crawl your HTML and hope the extraction is accurate. Every API you build, every structured data endpoint you expose, becomes a potential tool in an agent's capability set.