- In short
- A constrained tool is a narrow, validating replacement for an overly permissive generic tool. Instead of fetch_url that retrieves anything, you expose load_document that accepts only validated document URLs. Constraining the interface shrinks the attack surface and removes whole classes of misuse before they can happen.
What constrained tools are
Constrained tools are purpose-built, validating replacements for tools whose interfaces are wider than the job requires. A generic tool is convenient to build and dangerous to ship: it accepts broad input and performs a broad action, which means it can be steered, by a confused model or a malicious prompt, into doing something you never intended. A constrained tool closes that gap by narrowing the interface itself. It validates what it accepts and bounds what it does, so the dangerous path is not blocked at runtime, it is absent by construction.
This is the security-minded sibling of role scoping. Scoping decides which agent holds a tool; constraining decides how much any given tool can do. You apply it whenever a tool is more permissive than its purpose, which, for tools that touch the network, the filesystem, or external systems, is most of the time.
- Constrained tool
- A tool whose interface is deliberately limited to its actual purpose: it validates inputs, accepts only in-scope values, and performs one bounded operation. It replaces a generic, permissive tool to remove classes of misuse structurally rather than relying on prompts to discourage them.
The canonical swap: fetch_url to load_document
The example to memorise is a generic fetch_url tool replaced by a constrained load_document tool. fetch_url does exactly what it says: hand it any URL and it retrieves the contents. That is enormously flexible and exactly the problem. An agent equipped with fetch_url can be talked into reaching internal addresses, following a redirect to somewhere unexpected, or pulling content that was never part of the task. The tool's breadth is its liability.
load_document performs the operation you actually wanted, fetch a document for analysis, but validates first. It accepts only URLs that pass a document check, rejecting anything outside the allowed set. The agent can still load the documents it legitimately needs, yet it can no longer be repurposed into a general web-fetch primitive, because the unsafe inputs never make it past validation. You did not add a warning to the prompt asking the model to be careful; you removed the capability to be careless.
Why a narrower interface is a safer one
The reason constraining works is that it shifts safety from runtime persuasion to design-time structure. Prompts that say "only fetch internal documents" are probabilistic, the model usually complies, but "usually" is not a security boundary. A validating tool is deterministic: an input outside its allowed set is rejected every time, regardless of how the request was phrased or how the model was steered. Anthropic's tool-design guidance points the same direction, favouring tools with clear boundaries and consolidated, well-defined behaviour over sprawling generic surfaces that are hard for the model to use correctly and easy to misuse.
There is a selection benefit too. A constrained tool has a sharper description, "loads an allowed document for analysis", than a vague generic one, "fetches a URL". Sharper descriptions are exactly what makes Claude choose the right tool, so constraining often improves reliability and safety at once.
Strict tool use: validation the platform enforces
Constraining is a design discipline, but Anthropic also gives you a platform mechanism that enforces part of it for you. Setting strict: true on a tool definition makes the model's tool calls conform exactly to your JSON schema, so an argument of the wrong type, an unexpected field, or a hallucinated parameter is rejected at the grammar level rather than slipping through to your code. That is the schema half of constraining handled by the API itself. Anthropic's engineering guidance pushes the same way at the design half: use strict, unambiguous data models, name parameters explicitly (user_id, not a bare user) so the model cannot misread what a field means, and return actionable errors that tell the agent exactly what to fix instead of opaque codes. Strict schemas, explicit parameters, and clear error contracts are all expressions of the same idea behind load_document, narrowing what a tool will accept so that misuse becomes structurally hard. The schema enforced by strict and the validation written inside load_document work as complementary layers: the schema bounds the shape of the input, and your validation bounds its meaning.
How to apply it in design
Treat every permissive tool as a candidate for constraining. Ask two questions: what is the narrowest input this tool truly needs, and what is the smallest action that satisfies its purpose? Then build the tool to accept only that input and perform only that action. The pattern generalises well beyond URLs, a run_query tool constrained to read-only statements, a write_file tool constrained to a specific directory, a send_message tool constrained to approved recipients.
The judgement to practise is recognising when generality is liability rather than feature. If a tool's extra reach is never exercised by the legitimate task, that reach is pure risk and you should design it away. This is least privilege applied to the agent's hands: give each tool exactly the power its job requires and not a watt more.
Worked example
A document-analysis agent uses a generic fetch_url tool so it can pull source files. A security review finds that a crafted instruction in an untrusted document could make the agent fetch an internal admin endpoint.
Diagnose the real flaw: the danger is not the agent's behaviour but the tool's breadth. fetch_url accepts any URL, so any path that reaches the agent, including text inside the very documents it analyses, can aim it at an internal target. No prompt wording reliably closes that, because the capability itself is the hole.
Apply the constrained-tool fix. Replace fetch_url with load_document, a tool that validates its input against the set of allowed document sources before doing anything, and reject everything else. Legitimate analysis is unaffected: the documents the agent is supposed to read still pass validation. The attack is eliminated structurally: a crafted internal URL never satisfies the document check, so the fetch simply does not happen.
The lesson is the shape of the fix, not its specifics. You did not add a denylist of bad URLs to a system prompt and hope the model honours it. You narrowed the tool so the unsafe action is outside what it can express. That is what replacing a generic tool with a constrained one buys you, and it is why the exam treats keeping a generic tool, when a constrained alternative exists, as the wrong call.
The pattern beyond URLs
The fetch_url to load_document swap is the example to memorise, but the shape generalises to any tool whose reach exceeds its purpose. Three more are worth holding in mind, because the exam can dress the same idea in different clothing.
- A read-only query tool. Replace a generic
run_querythat accepts arbitrary SQL with one constrained to read-only statements against an allowed set of tables. The legitimate task, reading data, is untouched; the dangerous reach, writes and schema changes, is gone by construction. - A directory-bound file writer. Replace a
write_filethat can target any path with one that writes only inside a designated working directory. Path traversal out of that directory stops being something the tool can even express. - A recipient-bound messenger. Replace a
send_messagethat can address anyone with one constrained to an approved recipient list, so a confused or steered agent cannot exfiltrate a message to an arbitrary address.
In every case the move is identical: identify the narrowest input the task truly needs, accept only that, and perform only the smallest action that satisfies the purpose.
Worked example
An analytics agent answers questions about a product database using a generic run_query tool that executes any SQL it is given. A review warns that a crafted question could induce a DELETE or an UPDATE and mutate production data.
Diagnose the breadth, not the behaviour. run_query accepts arbitrary SQL, so the capability to mutate data exists whether or not the agent is currently inclined to use it, and a cleverly phrased question, or untrusted text the agent reads, could supply a destructive statement. A system-prompt rule like "only run SELECT statements" is the probabilistic patch that the constrained-tool pattern explicitly rejects.
Replace run_query with a constrained read_records tool. It accepts a bounded query shape against an allowed set of tables and executes only read-only statements; anything that would write is not representable in its interface. Legitimate analysis is unaffected, because reading is all the task ever needed. The destructive path is eliminated structurally, because the tool cannot express a mutation no matter how the request is phrased. As a bonus, the sharper description, reads records from approved tables, helps the model select the tool correctly, the same selection benefit that constraining always brings.
How this is tested
This knowledge point is assessed at the apply level of Bloom's taxonomy under task statement 2.3, so the exam hands you a flawed design and asks for the fix rather than a definition. The signature trap is keeping a generic tool when a constrained alternative would be safer, usually disguised as a reasonable-sounding mitigation: add a denylist, tighten the prompt, lower the temperature, or route the same generic tool through a single agent. Each of those leaves the dangerous capability intact and merely discourages or relocates its use. The correct answer narrows the interface so the unsafe action cannot be expressed at all. Train yourself to ask, of any proposed fix, whether it removes the capability or merely asks the model to avoid it; only the former is a real boundary, and that single question resolves most of the distractors on this topic.
Misreadings to avoid
Misconception
A generic tool is fine as long as the system prompt clearly tells the agent not to misuse it.
What's actually true
Misconception
Constraining a tool mainly costs you flexibility, so keep tools generic for capability.
What's actually true
Where constraining fits the bigger picture
Constraining is the safety lever of tool design, the counterpart to the latency lever of scoped cross-role tools. Both start from the same root, the tool overload problem and the discipline of giving agents only what they need. When you design a whole multi-agent system you weigh them together: constrain tools for safety, scope cross-role tools for speed, and keep each agent's set small for reliability. That combined judgement is the tool distribution strategy this page leads into, where security, latency, and reliability are balanced at once.
A research agent needs to read source documents from a known content store. It currently uses a generic fetch_url tool, and a review flags that untrusted document text could redirect it to internal endpoints. What is the most appropriate fix?
People also ask
What is a constrained tool?
Why replace a generic tool with a constrained one?
How do constrained tools improve agent security?
What is the difference between fetch_url and load_document?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Building tools for agents: with agents
Why watch: Walks through designing well-scoped, purpose-built agent tools rather than broad generic ones, mirroring the idea of replacing permissive tools with constrained alternatives.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.