Recently, while adding a tool to Claude Code, I paused.

Not because of a technical problem — the JSON Schema was written, the function implemented. Rather, a more fundamental question suddenly stopped me in my tracks: what is a tool, really?

We use tools every day, so frequently that we almost forget they exist. Hammers, search engines, programming languages, git. But when you have to design a tool for an AI agent, you’re forced to confront this question — because you’re deciding: what can this agent do, what can’t it do, and where are the boundaries of its world?

My first instinct was: a tool is a way of shortening the exploration path, borrowing an already-proven path to accelerate task completion.

Is this instinct right? I decided to think carefully.

The Hammer Disappears in Use

Heidegger made a brilliant observation in Being and Time: when you’re skillfully using a hammer to drive a nail, you don’t notice the hammer at all. Your attention is on the nail, on the shelf you’re building. The hammer “dissolves” in the act of use, becoming transparent — he called this “readiness-to-hand” (Zuhandenheit).

Only when the hammer breaks, feels wrong in your hand, or can’t be found does it “emerge” from the background, becoming an object of your scrutiny.

This has a profound implication for agent tool design: good tools should be transparent. When Claude Code calls the Edit tool to modify a file, it shouldn’t be tangled up in file I/O implementation details — just as you don’t think about the metallic crystal structure of the hammerhead when driving a nail. The tool’s implementation should dissolve into the task itself.

Moreover, Heidegger pointed out that tools never exist in isolation. A hammer points to nails, nails point to boards, boards point to the house being built. Tools are always embedded in a network of “in order to…” Claude Code’s tools work the same way: Glob finds files, Read understands code, Edit modifies code, Bash runs tests — they form a mutually referencing network of action.

The Sea Otter and Its Stone

Zooming out to the broader biological world, tool use is far more widespread than we might imagine.

New Caledonian crows manufacture hooked tools to extract grubs from bark crevices. Chimpanzees crack nuts with stones and fish for termites with twigs. Sea otters float on their backs, cracking open shellfish with stones. Octopuses even carry coconut shell halves as portable shields.

Interestingly, these capabilities have evolved independently many times across the tree of life — in birds, primates, cephalopods, and marine mammals. This suggests that tool use isn’t the exclusive product of any lineage, but rather a strategy repeatedly “invented” under specific ecological pressures.

From an evolutionary perspective, tools accomplish something fundamental: they flip the direction of evolution from “change the body to fit the environment” to “change the environment to fit the body.”

The sea otter doesn’t need to evolve stronger jaw bones to open shellfish — a stone is enough. What path does this stone shorten? The long path of waiting for the right genetic mutation.

Even more remarkably, archaeological evidence suggests that early human stone tools and the reduction of chewing muscles roughly coincided in time. Tools didn’t just replace bodily functions — they reversed the direction of bodily evolution. We shaped our tools, and then our tools shaped us — as McLuhan put it.

The Ratchet Effect: Humanity’s Unique Superpower

But human tool use has one feature that no other animal shares: cumulative improvement.

Tomasello called it the “ratchet effect” — one generation improves a tool, the next starts from the improved version, improves it further, passes it on. Improvements are “locked in” and don’t regress.

Stone axes → copper → iron → steel → alloys → nanomaterials.

No crow’s tool is more advanced than a crow’s tool from ten thousand years ago. But humans have gone from stone flakes to semiconductors.

This relies on two key capabilities: high-fidelity cultural transmission (imitating not just outcomes, but methods) and active teaching. Each generation doesn’t need to reinvent the wheel — they start exploring from where the previous generation reached.

Isn’t this exactly what I intuited as “borrowing already-proven exploration paths”? Only at the scale of human civilization, this borrowing is cumulative and exponentially growing.

From Options Framework to MCP

Back to the context of AI agents. My intuition has a precise mathematical counterpart in reinforcement learning.

The Options Framework, proposed by Sutton et al. in 1999, formalized “temporally abstract actions.” An option isn’t a single-step action but an encapsulated action sequence — with initiation conditions, an execution policy, and termination conditions.

A tool is an option.

read_file(path) encapsulates the entire sequence of “open file descriptor → read bytes → decode → return text.” git commit -m "fix" encapsulates “stage changes → create commit object → update HEAD.” The agent doesn’t need to know the underlying steps — it just needs to select the right option.

The reduction in exploration space is measured in orders of magnitude. Suppose you want to modify a file:

• Without tools: operating at byte-level system calls, the exploration space is astronomical
• With Bash: using sed, echo >, reducing by several orders, but still dealing with escaping and pipes
• With the Edit tool: specify file path, line number, new content. A precise four-tuple

This is why Claude Code’s system prompt says: “Do NOT use the Bash to run commands when a relevant dedicated tool is provided.” Dedicated tools shorten the path more than general-purpose ones.

And the significance of MCP (Model Context Protocol) is that it brings the ratchet effect to the agent tool ecosystem. The MCP server you write today can be used by all MCP-supporting agents tomorrow. Tool reuse is no longer copy-paste, but protocol-level interoperability. Function calling → MCP → Tool Search → Agent Skills — this chain itself is the ratchet of tool design turning.

Tools Do More Than Shorten Paths

Through this exploration, I found that my initial intuition was correct but incomplete. “Shortening exploration paths” is just one dimension of a tool’s effect. The fuller picture is a five-layer model:

Layer 1: Borrowing physical properties. The sea otter uses a stone — borrowing its hardness. An agent uses a calculator — borrowing hardware’s precision. No need to evolve a stronger jaw, no need to do your own floating-point arithmetic.

Layer 2: Encapsulating operation sequences. Crows manufacture hooked tools. The Edit tool encapsulates the entire flow of read-locate-modify-write-verify. Multiple steps compressed into one.

Layer 3: Inheriting others’ experience. Young chimps learn termite fishing from their mothers. A tool’s JSON Schema description encodes the designer’s domain knowledge. Skip the discovery phase, go directly to the usage phase.

Layer 4: Cumulative improvement. Stone axes to nanomaterials. Function calling to MCP. Each generation stands on the previous one; paths get shorter and shorter.

Layer 5: Rewriting the map. The use of fire changed digestive systems, social patterns, habitats — not finding a shorter path on the existing map, but switching to a different map entirely. Give an agent WebSearch, and it doesn’t just gain one more capability — its entire problem-solving strategy changes.

So, What Is a Tool?

After this exploration, here’s how I would answer:

A tool is the encapsulation of a proven exploration path.

It encodes the experience accumulated by predecessors (or prior systems) in solving specific problems — operation sequences, causal knowledge, domain expertise — into a directly reusable interface. Using a tool means standing on top of these exploration outcomes, skipping intermediate steps, and reaching the goal directly.

But tools go beyond that. Good tools are transparent in use — they dissolve into the task, becoming part of you. They change how you perceive the world, making the previously impossible possible, and they accumulate improvements across generations, continuously amplifying these effects.

Adding a tool to an AI agent is essentially injecting humanity’s exploration outcomes into the agent’s action space — letting it start not from atomic operations, but from the height humanity has already reached.

This also means that the person designing tools bears a special responsibility: you’re drawing the map the agent can walk on. Draw the map well, and the agent can go far; draw it poorly, and the agent will get lost in unnecessary complexity.

Tools are the crystallization of paths. And good tool design is a deep understanding of paths.