For a while I thought agent was a marketing word for something vaguely magical. Then I actually implemented tool use, and the magic collapsed into something better: a loop. Claude looks at the goal, says I need to call this function with these inputs, my code runs the function, I hand back the result, and Claude goes again. That is the whole trick. An agent is not a smarter model, it is this loop around one.
Once you see it, you can build it. This guide walks tool use on the Claude API: how to define a tool, how the loop actually runs, and how a CRM lookup plus an enrichment call turn into the research agent you wanted. No magic, just a conversation with pauses where real work happens.
Tool use is how Claude acts
By default Claude generates text. Tool use gives it a second option: instead of answering, it can ask to run one of the functions you have made available. You might define a tool that looks up an account in your CRM, one that enriches a contact, one that sends a Slack message. Claude cannot touch those directly, but it can request them, and that request is what turns talking into doing.
The key thing to internalize up front, because it changes how you reason about safety and control: Claude does not execute your tools. It returns a structured request saying which tool and what inputs, and your code decides whether and how to run it. You are always the one holding the actual power to act.
The loop, step by step
Here is the cycle. You send a request that includes your tools. Claude either answers normally or comes back with a tool_use block, its request to call a function. Your code runs that function, then sends the outcome back as a tool_result. Claude reads the result and continues, maybe answering, maybe calling another tool. You repeat until it stops asking for tools and gives a final answer.
That repetition is the agentic loop, and it is exactly what Claude Code and the Agent SDK run under the hood. Building it yourself with tool use is how you get an agent shaped precisely to your GTM workflow, rather than a general one.
Defining a tool
A tool definition has three parts: a name, a description, and an input schema. The name is the identifier. The input schema, written as JSON schema, tells Claude exactly what arguments the function takes and their types, so it fills them correctly. The description explains what the tool does and when to use it.
You pass a list of these definitions with your request. You are not giving Claude the function itself, you are giving it a menu: here is what exists, here is what each one needs. Claude reads the menu and orders when a step calls for it.
The description is the whole game
If one part decides whether tool use works, it is the description. Claude picks tools from it, so a vague description means the wrong tool at the wrong time, and a sharp one means reliable, well-timed calls. Write it as when to use this and what it does, in the language the task will actually appear in, not a terse label.
This is the same lesson as writing a skill's description or a good CLAUDE.md: the model acts on what you tell it, so the sentence that guides the choice is worth more than the code behind the tool. Spend your care there.
TipWrite each tool's description as when Claude should reach for it, with the inputs spelled out. A tool that gets called at the wrong moment is almost always a description problem, not a model problem.
Running the tool and returning the result
When Claude returns a tool_use block, your code takes over. You read which tool it asked for and the inputs it chose, run the real function, your CRM query, your enrichment call, and package what comes back as a tool_result tied to that request. Then you send the messages, now including the result, back to Claude.
This is the moment you have full control. You can validate the inputs before running, refuse a call that looks wrong, or run it in a sandbox. The tool_result you return is also your chance to shape what Claude sees next: a clean, relevant result keeps the loop sharp, a giant dump of raw data clogs it.
Multi-tool and the agentic loop
Real work needs more than one tool, and Claude chains them. Ask it to research an account and it might call the CRM tool for history, then the enrichment tool for a missing title, then compose an answer, each step feeding the next. You run each call as it comes and return each result, and the loop handles the sequencing.
Your job is to keep looping until Claude stops requesting tools. That means a small controller in your code: send, check for a tool_use, run and return, repeat. A few dozen lines, and you have the same engine that powers every agent, tuned to your stack.
Read tools and write tools
The distinction that keeps tool use safe is read versus write. Read tools, look up an account, fetch a report, enrich a contact, are low risk, so you can let Claude call them freely. Write tools, update a deal, send an email, change a record, touch your systems and your prospects, so those deserve a check before your code runs them.
Because you are the one executing every tool, this guardrail is entirely in your hands. You can auto-run the reads and gate the writes behind a validation step or an approval, so an agent researches at full speed and pauses at the actions that would actually cost you if they were wrong.
There is a cost dimension to the split too. Read tools tend to be cheap and safe to run often, so letting Claude call them freely is fine. Write tools are where a mistake is expensive in both senses, a wrong record and, if it loops, a wrong record many times over, so gating them protects your data and your bill at once.
- Read tools (lookups, fetches, enrichment): safe to let Claude call freely.
- Write tools (update, send, delete): run only after a check or an approval.
- You execute every tool, so the read/write guardrail is yours to enforce in code.
Keeping the loop from running away
An agentic loop can loop too much. A confused agent might call the same tool over and over, or chase a goal it cannot reach, and each turn costs tokens. So put a ceiling on it: a maximum number of iterations, after which you stop and surface what happened. A loop without a bound is a bill without a bound.
The related guard is watching for repetition. If Claude calls the same tool with the same inputs twice in a row, it is usually stuck, and the fix is to break in with a clearer instruction or stop, not to let it spin. Treat the loop like any long-running process: give it a budget and a way to fail cleanly.
The GTM version: a research agent
Put it together and here is the first agent worth building. Two tools: one that reads an account from your CRM, one that enriches a contact through a provider like FullEnrich. You give Claude a goal, research this account and tell me the angle, and it loops: pull the CRM history, notice a missing title, call enrichment, then write a grounded brief. You ran every tool; Claude did the thinking and the sequencing.
That is a real research agent, built from a loop and two functions, shaped exactly to how you sell. Add a write tool later, gated, and it can log the brief back to the CRM. What two tools would turn your most tedious research task into a loop you no longer run by hand?
How to set it up
Define your tools
Describe each tool with a name, a when-to-use description, and an input schema. Pass the list with your request:
Send the request and check for a tool call
Include the tools in the call. Claude either answers or returns a tool_use block asking you to run one:
Run the tool and return the result
Read which tool and inputs Claude chose, run the real function, and send the outcome back as a tool_result so Claude can continue:
TipValidate the inputs before you run a write tool. You execute every call, so this is exactly where you gate the actions that touch your CRM or your prospects.
Loop until it stops asking
Wrap send, check, run, return in a loop that repeats while Claude keeps requesting tools and ends when it returns a final answer. That loop is your agent.
Frequently asked questions
Does Claude run the tools itself?
No. Claude returns a structured request naming the tool and inputs; your code runs the function and sends back the result. You always hold the actual power to act, which is what makes the read/write guardrail enforceable.
What defines a tool?
Three things: a name, a description of what it does and when to use it, and an input schema describing its arguments. You pass a list of these with your request.
Why does the description matter so much?
Claude chooses tools from their descriptions. A vague one leads to the wrong tool at the wrong time; a precise, when-to-use description leads to reliable calls. It matters more than the code behind the tool.
How does tool use become an agent?
You loop it: send the request, run any tool Claude asks for, return the result, and repeat until it stops requesting tools. That request-run-return loop is the agentic loop, the same one Claude Code runs.
How do I keep write actions safe?
Split tools into read and write. Let Claude call reads freely, and run write tools only after a validation step or approval. Because your code executes every call, you enforce this directly.
Can Claude use several tools in one task?
Yes. It chains them, calling one, reading the result, calling another, until it has what it needs. Your loop runs each call as it comes and returns each result.
What should the tool_result contain?
A clean, relevant version of what the function returned. It shapes what Claude sees next, so a focused result keeps the loop sharp while a raw data dump clogs it.
What is a good first tool-use project for GTM?
A research agent with two tools: read an account from your CRM and enrich a contact. Claude loops between them to produce a grounded brief. Add a gated write tool later to log it back.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.