Understanding Claude's "Tools" and "Clients" from a Structural Perspective

Introduction

While learning system design using Claude, I repeatedly stumbled over two terms: "Tool" and "Claude."

"Tool" appears throughout Anthropic's official documentation and learning materials, alongside terms like "Skill," "MCP," and "Agent SDK." Since all of them appeared to be "mechanisms for making Claude do something," I initially assumed "Tool must be an umbrella term for all of these." "Claude" also creates confusion because it refers to different things depending on context—sometimes the model itself, sometimes Claude Code or the desktop app.

This article clarifies these two terms. Here are the conclusions:

• A tool is the fundamental mechanism called tool_use (function calling) in Claude's API. MCP, Skill, and Agent SDK are separate layers built on top of it—they are not what "tool" is a collective name for.
• claude.ai, Claude Code, the desktop app, and custom scripts all serve the same role as "clients." They are distinct from the model itself—the other thing the word "Claude" refers to.

To understand both, you first need to grasp how interactions with Claude work. I'll explain from the ground up.

1. How Interactions with Claude Work

Stateless Request-Response

Interactions with Claude ultimately involve just two actors.

• Client (app): The side that sends requests
• Claude model itself: The inference engine running on Anthropic's servers. Specific models such as Opus, Sonnet, and Haiku fall under this category, and requests specify which model to use.

The two communicate through Claude's API (the Messages API for sending and receiving messages). This API follows a stateless request-response pattern. It returns one response per request, and the server does not retain any memory of previous exchanges. Specifically, two things follow from this:

• The API never proactively responds to the client. Each round trip is complete when "the client sends → the API returns once."
• The API does not remember past exchanges. To continue a conversation, the client must send the entire history (the messages array) with every request.

The appearance of an ongoing conversation exists because the client saves past exchanges and sends them back in full each time. The messages array alternates between user (the user's utterances) and assistant (Claude's utterances), but these assistant messages are not the model speaking in real time—they are the text the model returned in a previous response, saved by the client and resent.

"Send a request → receive one response" is the fundamental unit of everything. Tools and agents are all built from combinations of this unit.

This mechanism also has cost implications. Because the entire history is resent each time, the number of tokens sent per request grows as the conversation lengthens. Since all history is billed as input tokens, longer conversations mean higher cost and longer wait times per round trip.

stop_reason: Indicating Why the Response Stopped

Every response includes a stop_reason field indicating why the model stopped generating. The client reads this value to decide what to do next. For example, if the value is tool_use, the client executes the tool and resends; if it is end_turn, the process is complete.

The following table shows the main values stop_reason can take (from the official documentation "Stop reasons and fallback"; others such as model_context_window_exceeded also exist).

Even in ordinary chat without tools, the flow is the same: stop_reason: "end_turn" is returned and the exchange completes in one round trip. When tools are used, the "one request, one response" mechanism does not change. The only difference is that when a response comes back with tool_use instead of end_turn, the client executes the tool and sends another request—adding more round trips.

2. What Tools (tool_use) Really Are

Why Tools Are Needed

On its own, all Claude can do is generate text based on input. It cannot query an inventory database, process a refund, or read a file by itself. To enable external data retrieval and processing, a mechanism is needed that lets the model express which function it wants executed, while the actual execution is handled by the client-side program. This is the tool (tool_use).

What a tool does is let the model declare "I want to call this function with these arguments," while leaving the actual execution to an external program.

A Tool Definition Has Three Elements

The client passes a list of permitted tools in the tools field of the request. Each tool is defined by three elements:

{
  "name": "lookup_order",
  "description": "Retrieves the shipping status of an order by order ID",
  "input_schema": {
    "type": "object",
    "properties": { "order_id": { "type": "string" } },
    "required": ["order_id"]
  }
}

The description is critical. The model compares the user's message against this description to decide on its own whether to call the tool. If the description is vague, the tool won't be called when it should be. The input_schema specifies the format of the arguments (JSON Schema) and guarantees the structure of the arguments the model passes.

The Exchange When Using a Tool

Let's walk through an actual exchange using tools, with customer support as an example.

① Client → Model (sends the question with tool definitions)

{
  "messages": [
    { "role": "user", "content": "What's the status of order 12345?" }
  ],
  "tools": [ { "name": "lookup_order", "...": "..." } ]
}

② Model → Client (cannot execute on its own, so returns "please call this")

{
  "role": "assistant",
  "content": [
    { "type": "text", "text": "Let me check." },
    { "type": "tool_use", "id": "toolu_01",
      "name": "lookup_order", "input": { "order_id": "12345" } }
  ],
  "stop_reason": "tool_use"
}

③ Client → Model (executes the function locally and returns the result under the user role)

{
  "role": "user",
  "content": [
    { "type": "tool_result", "tool_use_id": "toolu_01",
      "content": "Order 12345 has been shipped. Tracking number: XYZ." }
  ]
}

④ Model → Client (provides the final answer based on the result)

{
  "role": "assistant",
  "content": [ { "type": "text", "text": "Your order 12345 has been shipped. The tracking number is XYZ." } ],
  "stop_reason": "end_turn"
}

The round trips illustrated in a diagram:

Two Key Points to Keep in Mind

There are two common misconceptions about how tools work:

1. It is the client, not the model, that executes the function. The model only declares "I want to call this" (the tool_use in step ②); the database query is performed by the external program (step ③).
2. Execution results are returned as user role messages. Because Claude's API has no dedicated tool role, tool results are included in user messages as tool_result blocks. Some other APIs return results under a dedicated role, which can be a source of confusion.

Client Tools and Server Tools

Tools fall into two categories based on where the code runs.

The four-step loop described above applies to client tools. Server tools are executed on Anthropic's side, so the client does not need to manage execution round trips—it simply receives the results.

3. What Exactly Is a "Client"?

Throughout the above, I have used the word "client." What it specifically refers to is directly tied to the other source of confusion: the dual meaning of "Claude."

"Claude" refers to two distinct things:

• Claude (the model itself) … The inference engine on the server side. It lives on the other side of the API.
• Claude Code, the desktop app, etc. … Separate programs running in the user's environment. These call the API as clients.

All of the following are "clients (apps)." They differ in developer and form, but from the API's perspective, they all play the same role of "client."

• claude.ai … A browser-based chat interface
• Claude desktop app … The same chat experience as claude.ai, used as an installed app rather than through a browser
• Claude Code … A command-line tool used in the terminal
• Claude Cowork … A task execution feature of the Claude desktop app that lets you delegate work such as file operations
• Custom scripts … Programs that call the SDK or API directly. When calling Claude through Amazon Bedrock or Google Cloud's Gemini Enterprise Agent Platform (formerly Vertex AI), the calling program is the client.

claude.ai and the desktop app offer the same chat experience—the only difference is whether you access it through a browser or an installed app. Both are official Anthropic clients.

For example, when Claude Code receives stop_reason: tool_use from the model (e.g., "please run ls with Bash"), it executes that command on the user's PC and sends back the result to advance the loop. The model itself never touches the user's PC. The roles are divided: "the model that returns instructions" and "the client that executes locally."

Different Clients, Different Execution Locations for Tools

When I say the client "executes tools locally," the meaning of "locally" varies by client. Comparing Claude Code and Claude Cowork:

Claude Code executes commands and file operations directly in the local shell (with permission approval before execution). Claude Cowork, on the other hand, runs inside an isolated virtual machine (VM) that mounts only the working folder the user has selected, and cannot touch anything else on the host.

The interface (CLI vs. desktop), execution environment (local vs. VM), and permission handling differ, but the underlying structure of communication with the model—client sends request → model returns content and stop_reason → if tool_use, client executes tool → resends result → loops until end_turn—is the same Messages API mechanism in both cases. "What tool, where, and with what permissions" differs; "how to communicate with the model" is shared.

With a clear understanding of tools and clients as two foundational concepts, you can move on to "agents."

4. From Tools to Agents

At this point, we have seen how a single round trip with tool_use works. An AI agent is a mechanism that repeats this round trip multiple times based on the model's own judgment, advancing the process until a goal is achieved.

The behavior is a direct extension of the loop we saw in Chapter 2. While stop_reason is tool_use, the client executes the tool, attaches the result, and sends it back to the model. The model looks at the returned tool result and decides "which tool to call next, with what arguments" or "is this enough." By repeating this until end_turn is returned, the system handles multi-step tasks that cannot be completed in a single round trip.

For example, with a request like "fix the bug in this repository," what to do, in what order, and how many files to read cannot be known in advance. An agent first searches for relevant files, reads the suspicious ones based on the results, hypothesizes the cause, makes a fix, and runs the tests. If the tests fail, it uses that output as a clue to investigate elsewhere, makes another fix, and runs the tests again. In this way, the agent decides its next move and how many times to repeat based on the previous tool result, and stops when it determines "the tests passed." The defining characteristic of an agent is that the model itself decides the procedure—rather than having the procedure fixed in advance.

A contrasting approach is a "workflow." Workflows fix the procedure in code and call the LLM as a component in predetermined steps. Tasks where the procedure or number of steps changes based on intermediate results cannot be fully expressed by a workflow that fixes steps in advance. Agents delegate the judgment of what to do and in what order to the model, making them suited for exploratory tasks like these. Conversely, for routine processing where the flow is the same every time, a workflow is more reliable and easier to manage.

Agent SDK: The Runtime That Takes Over the Agent Loop

When you try to build this agent loop (executing tools, resending, and repeating until end_turn) seriously, you need to implement not just the loop itself, but also tool execution, multi-step management, and cleanup of increasingly long conversations—all from scratch.

The Agent SDK is a runtime that takes over this entire set of responsibilities. It automatically runs the tool_use loop and comes equipped with:

• Built-in tools (file read/write, command execution, web search, etc.)
• Sub-agents (a mechanism for delegating subtasks)
• MCP integration (incorporating tools from external services)
• Context management (automatic cleanup when conversations grow long)

The difference from calling the API directly (Client SDK) is whether you "write this loop yourself or delegate it."

The Agent SDK was originally created as the runtime powering Claude Code. Because the agent loop turned out to be general enough for uses beyond coding, it was renamed from "Claude Code SDK" to "Agent SDK" in 2026. Claude Code and Claude Cowork, compared in Chapter 3, are both agents built on this runtime, running the same loop in different environments (local shell vs. isolated VM).

5. MCP and Skill: Easy to Confuse with Tools, but Different

At the outset, I wrote that I had assumed "Tool must be an umbrella term for MCP and Skill." When Tool, MCP, Skill, and Agent SDK appear together in the same sentence, they all seem to play similar roles. But as we have seen, these concepts differ in abstraction level (layer). Arranged by layer:

We covered tools, agents, and Agent SDK in previous chapters. Let's look at MCP and Skill.

MCP: A Mechanism for Supplying Tools

If you only need to create one tool, it's enough to pass the definition in the tools field, as we saw in the tools chapter. However, if you want to use multiple external services (Slack, GitHub, internal databases, etc.) from multiple AI apps, you end up implementing a connection for every combination. MCP (Model Context Protocol) is a protocol that standardizes "the part that connects AI apps to external services" to reduce redundant implementation.

The key to understanding MCP is to see it not as "the tool itself" but as "a mechanism for supplying tools." An MCP-compliant server can expose three types of things to the outside:

• Tools … Functions the model can call. These are ultimately passed to Claude as tool_use.
• Resources … Data the model can reference (files, documents, etc.).
• Prompts … Standard prompt templates.

In this way, MCP is not the tools themselves but a protocol for delivering tools and data to Claude in a standardized form. The key point here is that MCP is not a collective name for tools.

Skill: A Different Axis from Tools

A Skill (agent skill) is a package centered on a procedure document called SKILL.md, bundled together with necessary scripts and resources. For example, it passes to Claude something like "the procedure for generating a PDF in our company's invoice format"—the how-to of a task.

A Skill is not "a function to call." While a tool is an individual function that Claude calls, a Skill is a package that delivers the how-to of a task (procedures and knowledge) to Claude. In the course of carrying out work, a Skill may use tools (for example, using a code execution tool to generate a PDF). Skills and tools exist on different axes; they are not the same category but different in kind.

Summary

Here are the answers to the article's two questions: "What is a tool?" and "What is a client?"

• A tool is the most fundamental mechanism called tool_use (function calling) in Claude's API—the mechanism that gives an LLM the ability to execute external operations. It is not a collective name for Skill or MCP.
• claude.ai, Claude Code, the desktop app, and custom scripts all serve the same role as "clients." They are distinct from the model itself—the other thing the word "Claude" refers to.
• Tools come in two types: client tools, executed in your own environment, and server tools, executed on Anthropic's side.
• An agent is a mechanism in which the model autonomously runs the tool loop to achieve a goal. The Agent SDK is the runtime that takes over that loop, and Claude Code and Claude Cowork are built on top of it.
• MCP is a protocol for supplying tools; Skill is a package of procedures and knowledge. Both are separate layers positioned around the tool foundation, and neither is a collective name for tools.

Clarifying the two terms "tool" and "Claude" allows the concepts that build on top of them to be understood as differences in which part of the same skeleton you are designing. I hope this is helpful for anyone who has stumbled in the same places.

References (Official Documentation)

• Claude API — Tool Use (overview): https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
• How tool use works: https://platform.claude.com/docs/en/agents-and-tools/tool-use/how-tool-use-works
• Stop reasons and fallback (list of stop_reason values): https://platform.claude.com/docs/en/api/handling-stop-reasons
• Claude Agent SDK — Overview: https://platform.claude.com/docs/en/agent-sdk/overview
• Agent Skills (Skill overview): https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• Model Context Protocol: https://modelcontextprotocol.io/
• Claude Code — Overview: https://code.claude.com/docs/en/overview
• Get started with Claude Cowork: https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork