What Is a Tool — The API Call Your Agent Makes on Your Behalf

APIs have existed for thirty years. Your agent calling one on your behalf — that’s new.

If you’ve used an AI agent that reads your email, posts to Slack, queries your CRM, and books a meeting — all in one conversation — each of those actions was a tool call. A tool is a single, well-defined capability the agent can invoke. Read a file. Search the web. Create a calendar event. Send a message. Every tool has a name, a description, input parameters, and an output format. The agent reads the description, decides when to call it, fills in the parameters, and interprets the result.

That sounds simple. It is simple. The interesting part is everything around it.

This is the third post in the Agent Primitives series — four posts that cut through the confusion around agents, skills, tools, and agent harnesses. The first post defined what an agent is (and isn’t). The second defined skills — reusable encoded methodology. This one defines the atomic layer underneath both: tools.

A Tool Is a Function With a JSON Schema

Strip away the marketing and a tool is a function signature. It has:

• A name: email_send, file_read, calendar_view, web_search
• A description: natural language explaining what the function does — this is what the model reads to decide whether to use it
• Input parameters: typed fields with descriptions (e.g., to: string, subject: string, body: string)
• An output: whatever the function returns — a list of emails, a file’s content, search results, a confirmation

The agent’s reasoning model reads the description and decides: given my current goal and the tools available, which one should I call next, and with what parameters?

That decision — the model selecting and parameterizing a tool call at runtime — is the fundamental shift. APIs existed long before AI agents. SDKs, webhooks, REST endpoints, GraphQL queries. All the plumbing was already there. What changed is that the human is no longer the one deciding which API to call. The model is.

Tools Are Not New. Who Calls Them Is.

A Slack API endpoint for posting a message has existed since 2013. An Outlook API for reading email has existed since 2015. A Salesforce API for querying opportunities has existed since the early 2000s. None of this is novel infrastructure.

What’s novel: an AI model sitting in a reasoning loop, examining your goal (“triage my inbox and flag anything from Tier-1 accounts”), scanning its available tools, and autonomously deciding:

1. Call email_inbox to pull the last 50 messages
2. Call file_read on accounts.csv to load the Tier-1 list
3. For each email, reason about sender, subject, and body against the Tier-1 list
4. Call file_write to produce a triage report
5. Call conversations_add_message to post the summary to Slack

No human selected those tools. No human wrote that sequence. The agent reasoned through it based on the goal and the tools available.

This is why the tool layer matters: it’s the interface between the agent’s reasoning and the external world. Without tools, the agent is a brain in a jar — it can think about your email, but it can’t read it.

Seven Categories of Tools

In practice, tools cluster into functional categories. Here’s what a production knowledge-work agent actually uses:

No single tool is interesting on its own. file_read by itself is cat. email_inbox by itself is Outlook. The power comes from what the agent does with the result of one tool to decide the next tool call. That’s the agent loop, and it’s the primitive that makes tools useful.

MCP: The Universal Tool Protocol

Before 2024, every agent platform defined its own tool format. OpenAI had function calling. LangChain had tool classes. Anthropic had tool-use blocks. If you built a Slack integration for one platform, you rebuilt it for every other one.

Then Anthropic released the Model Context Protocol — MCP — in late 2024. It standardized how agents discover, authenticate with, and invoke tools. JSON-RPC over stdio or Streamable HTTP. Language-agnostic. Open standard.

The adoption curve has been vertical:

• 97 million monthly SDK downloads by March 2026 — up from ~2 million at launch. 4,750% growth in 16 months.
• 13,000+ public MCP servers on GitHub as of April 2026, spanning databases, dev tools, communication platforms, and cloud infrastructure.
• Governed by the Linux Foundation’s Agentic AI Foundation (AAIF) with backing from Anthropic, OpenAI, Google, Microsoft, and AWS.
• Natively supported in Claude, Cursor, Windsurf, VS Code, Kiro, and 200+ other tools.

MCP is to agent tools what HTTP was to web services — the universal transport. Before HTTP, every networked application had its own protocol. After HTTP, you built one server and any client could talk to it. Before MCP, every agent had its own tool format. After MCP, you build one server and any MCP-compatible agent can discover and call it.

The architecture has three roles:

1. Host: the application holding the LLM (Claude Desktop, Amazon Quick Desktop, Cursor)
2. Client: maintains a stateful connection to a specific MCP server
3. Server: an independent process exposing tools, resources, and prompts for the agent to use

A single host connects to multiple servers simultaneously. Each server exposes its own tools. The agent sees all of them in one unified namespace.

This is why MCP matters: it turns the long tail of integrations from a build problem into a plug-in problem. A team at Particula Tech shipped eleven enterprise integrations in nine days because every one spoke MCP. Two years earlier, that would have been three months of custom plumbing per integration.

Tool Composition: Where the Real Work Happens

A single tool call is not interesting. file_read returns text. email_inbox returns a list. web_search returns results. None of that constitutes work.

Work happens when the agent chains tool calls into a workflow:

Example — Morning triage:

1. email_inbox → pull last 50 messages from priority inbox folder
2. file_read → load triage-rules.csv for sender-tier classification
3. file_read → load accounts.csv for account-level context
4. calendar_view → pull today’s meetings for cross-reference
5. Agent reasons: classify each email as T1/T2/T3 based on sender, keywords, account context, calendar overlap
6. file_write → produce a structured triage report with decision-lines
7. conversations_add_message → post the T1 items to Slack

Seven tool calls. One coherent workflow. The agent selected each tool, parameterized it, interpreted the result, and decided the next step. No human orchestrated the sequence.

That chain — tool selection, invocation, interpretation, next-step reasoning — is not a tool. It’s the agent loop using tools. The distinction matters because people confuse tool access with capability. Having 250 tools does not make your agent capable. Having methodology for when and how to combine those tools does.

That methodology is a skill. And that’s the boundary between the two concepts.

The 250-Tools-One-Conversation Reality

The scale of tool access in production agents has blown past what anyone expected two years ago.

Amazon Quick Desktop runs 250+ tools in a single conversation. Those 250 are individual tool functions spread across all connected MCP servers — Slack MCP server tools (read, write, search, react), Outlook MCP server tools (email and calendar), SharePoint tools, Salesforce MCP server tools, file system tools, Python and JavaScript execution, web search, browser automation, image generation, audio transcription, and more — plus native harness capabilities like AgentCore’s code interpreter sandboxes and cloud browser sessions. (AgentCore is an AWS service with its own MCP server that exposes runtime primitives to agents; it gets its own dedicated post.) All simultaneously available. The agent selects from the full set based on the user’s intent.

Claude Code integrates with 150+ tools via MCP — file system, git, shell commands, web search, browser automation, and any MCP server the developer adds. Sub-agents can spawn with their own tool access to work in parallel.

Kiro connects to AWS services natively through Amazon Bedrock, with MCP servers for additional tool access — SAM templates, CloudWatch, DynamoDB, Lambda.

The number of tools is not the flex. The number is the precondition. Once you have 250 tools available, the bottleneck shifts. The question stops being “can the agent send a Slack message?” and becomes “does the agent know which channel to post in, what tone to use, when to thread vs. top-level, and what prior context to reference?”

That’s not a tool problem. That’s a skill problem. Tools provide the hands. Skills provide the judgment.

Tools vs. Skills: The Critical Distinction

This is where the industry gets confused. Arcade.dev put it precisely: “Tools and skills get used interchangeably in marketing decks and conference talks, but they represent fundamentally different approaches to extending agent capabilities.”

Here’s the difference:

A tool is an API call. A skill is institutional knowledge about when, why, and how to make that API call — and the six calls that should follow it.

The GTM AI Podcast framed it well: “Tools let agents act. Skills provide the knowledge of how and when to act — including the company-specific, team-specific, and user-specific context that separates a capable AI from a competent one.”

If you’re building an agent and you think the answer is “add more tools,” you’re solving the wrong problem. The agent already has the tools. What it’s missing is the methodology to use them well. That’s the skill layer, and it’s the topic of the second post in this series.

So What

Tools are the atomic capabilities that let agents interact with the world. They are necessary but not sufficient. MCP standardized how tools are discovered and invoked — that’s a protocol win comparable to HTTP. The ecosystem response has been 97 million SDK downloads and 13,000+ servers in 16 months.

But tools alone don’t produce work. A tool is a single function call. Work is a chain of function calls governed by methodology — which tools to call, in what order, with what parameters, interpreted against what context, and checked against what quality bar.

The tool layer is solved. MCP won. The open question is the layer above it: who encodes the methodology that makes those tools useful? That’s the skill layer, and it’s the new frontier.