Domain 2 rewards a specific skill: given a scenario, choosing the mechanism that actually fits. That is harder than it sounds because the tool-use and MCP surface is full of pairs that look interchangeable until you ask who decides, when it runs, and what happens if the model simply doesn't call it. A tool that spawns a whole subagent and a tool that pokes an external API are both "tools" to the model. Resources and tools both come from an MCP server. tool_choice: any and tool_choice: tool both force a call. Each pair diverges on exactly the axis an exam scenario tests.
This guide compares five of the most-confused pairs head to head. For each, the question to hold in your head is not "what is X?" but "what does X guarantee that its look-alike doesn't?" The mechanism you want is usually the one whose control model matches the scenario — model discretion versus application control versus deterministic enforcement.
This is an independent, unofficial study aid. It is not affiliated with or endorsed by Anthropic, it teaches Foundations-level mental models only, and it never reproduces real exam items. Where a niche flag name would be guesswork, it teaches the concept instead.
Task tool vs MCP tool
Both appear in the model's tool list and are invoked the same way — an assistant tool_use block. The difference is what happens on the other side of the call. The Task tool (the built-in Agent/subagent tool) spins up a fresh Claude instance with its own context window and its own tool loop, hands it a prompt, and returns only that subagent's final summary. An MCP tool is a capability advertised by a connected MCP server; calling it sends the input to that external system (GitHub, a database, an internal API) and returns its result. One delegates thinking to another model; the other delegates doing to another system.
| Dimension | Task tool (subagent) | MCP tool |
|---|---|---|
| Purpose | Delegate an open-ended sub-task to a fresh Claude instance | Perform a concrete action against an external system |
| Scope | Spawns an isolated agent with its own context + tool loop | One request/response to a server-hosted capability |
| Who decides | Model chooses to delegate; you configure which subagents exist | Model chooses to call; the MCP server defines the tool + schema |
| When it runs | Runs a whole nested agent loop, then returns a summary | Runs once per invocation, returns a tool_result |
| Best for | Parallel/independent research, keeping noisy work out of the main context | Reaching a real service: read a row, open a PR, send a message |
| When NOT to use | A single deterministic action you could just call directly | Work that needs multi-step reasoning, not one external call |
MCP resources vs MCP tools
Both are exposed by an MCP server, so scenarios blur them. The dividing line is the MCP control model. Resources are read-only data the host application (or the user through it) selects and attaches as context — a file, a schema, a config blob. They are application-controlled: nothing happens until the app decides to fetch and include them. Tools are actions the model invokes on its own initiative, and they can have side effects. Resources feed context in; tools reach out and do something.
| Dimension | MCP resource | MCP tool |
|---|---|---|
| Purpose | Expose read-only data to include as context | Let the model perform an action |
| Scope | A retrievable piece of content (file, record, schema) | An invocable operation with an input schema |
| Who decides | Application / user selects it (application-controlled) | The model calls it (model-controlled) |
| When it runs | When the host fetches/attaches it, before or between turns | When the model emits a tool_use during generation |
| Best for | Grounding the model in documents, configs, known state | Querying, writing, or triggering effects in a system |
| When NOT to use | Anything with side effects or that the model must trigger | Passively supplying reference data the model should just read |
tool_choice: auto vs any vs forced (a specific tool)
tool_choice controls how much freedom the model has. auto (the default) lets it decide whether to use a tool at all, and to answer in plain text if that's better. any forces it to call some tool but leaves the choice of which. Forcing a specific tool ({type: "tool", name: ...}) compels exactly that one — the trick teams use to guarantee structured output, since the model must emit a tool_use matching that tool's schema. The sequencing caveat matters: forcing a tool prefills the assistant turn to produce a tool call, so the model won't write reasoning or explanatory text before it, and forced choice can't be combined with extended thinking.
| Dimension | auto | any / forced (specific tool) |
|---|---|---|
| Purpose | Let the model decide if and which tool to use | Guarantee a call — any tool (any) or one named tool (forced) |
| Scope | Full discretion, including a plain-text answer | Removes the no-call option; forced also removes tool choice |
| Who decides | The model | You constrain it; forced leaves zero choice |
| When it runs | Only when the model judges a tool is warranted | On that turn, unconditionally |
| Best for | Conversational agents; multi-step dependent workflows | One-shot structured extraction / a guaranteed schema'd result |
| When NOT to use | When you must guarantee a machine-parseable result | A step where the model needs to reason between dependent calls |
Tool descriptions vs system prompt
Both steer behavior, so guidance ends up in the wrong place. The rule: selection and usage guidance for a specific tool belongs in that tool's description — especially the when to call it trigger, which recent models weight heavily. Global behavior, persona, tone, and cross-cutting policy belong in the system prompt. A description travels with the tool and is what the model reads when deciding whether this tool fits; the system prompt frames the whole conversation regardless of which tools exist.
| Dimension | Tool description | System prompt |
|---|---|---|
| Purpose | Explain what one tool does and when to call it | Set global behavior, role, tone, and policy |
| Scope | Local to a single tool definition | Whole conversation, all tools |
| Who decides | You author it per tool; the model reads it to select | You author it once; frames every turn |
| When it runs | Consulted at tool-selection time | Applies across the entire session |
| Best for | Trigger conditions, input semantics, when-not-to-use notes | Persona, safety rules, output style, overall task framing |
| When NOT to use | Global persona or rules unrelated to one tool | Per-tool selection logic that belongs next to the tool |
Hooks vs tool use
This is the deepest pair because it's about guarantees. Tool use is discretionary: the model may call a tool, call a different one, or skip it entirely — you cannot make invocation certain by wording alone. Hooks (Claude Code lifecycle hooks) are deterministic: configured commands the harness runs on events such as before a tool call, regardless of what the model decides. That's the crux: if a rule must always hold — block a dangerous command, always run the formatter, gate a write — it cannot live inside a tool the model might not invoke. It belongs in a hook the harness fires unconditionally.
| Dimension | Hook | Tool use |
|---|---|---|
| Purpose | Deterministically enforce/observe around tool activity | Let the model take an action when it judges fit |
| Scope | Fires on a lifecycle event (e.g. pre/post tool call) | One model-initiated invocation |
| Who decides | The harness — runs no matter what the model wants | The model decides whether to call at all |
| When it runs | Every time the event occurs, unconditionally | Only if the model chooses to invoke the tool |
| Best for | Hard guarantees: guardrails, gating, logging, auto-formatting | Discretionary work the model reasons about |
| When NOT to use | Open-ended actions needing model judgment | Anything that must happen every time without exception |
Key takeaways
- 01For every pair, decide by control model: model discretion (tools, auto), application control (resources), or deterministic enforcement (hooks).
- 02Task tool delegates reasoning to a fresh subagent; an MCP tool delegates a single action to an external system — both are invoked as tool calls.
- 03MCP resources are read-only, application-selected context; MCP tools are model-invoked actions. The test is who controls it, not just "read-only."
- 04Force a specific tool to guarantee structured output; use
autowhen the model must reason between dependent steps — forced choice blocks that. - 05Per-tool when-to-call guidance goes in the tool's description; global persona and policy go in the system prompt.
- 06If a rule must hold every time, it belongs in a hook (deterministic), not in a tool the model may skip (discretionary).
- 07"Would this still hold if the model made no calls?" separates hooks from tools; "another brain or another system?" separates subagents from MCP tools.
Common mistakes
Treating every scenario that says "tool" as an MCP tool.
Check what's on the other side of the call: a nested agent loop (Task/subagent) or an external system (MCP tool). Both are invoked identically.
Calling a model-initiated read-only lookup an MCP resource because it doesn't change anything.
Read-only isn't the test. If the model decides to invoke it, it's a tool; resources are surfaced by the application/user.
Forcing a specific tool across a dependent multi-step workflow.
Forced/any choice prefills a tool call and blocks interleaved reasoning. Use auto for chains; reserve forced choice for a single structured-output step.
Putting per-tool selection rules in the system prompt.
Move trigger conditions into the specific tool's description, where the model reads them at selection time and they don't bloat the global prompt.
Relying on a tool the model is told to "always call" to enforce a guarantee.
The model can skip any tool. Use a deterministic hook (e.g. PreToolUse) for guardrails, gating, or mandatory steps.
Frequently asked
Is the Task/subagent tool part of MCP?
No. It's a built-in agent capability that spawns a nested Claude instance. MCP tools come from connected MCP servers. They only look alike because the model invokes both as tool calls.
Can an MCP server expose both resources and tools?
Yes — the same server commonly offers read-only resources (application-selected context) and tools (model-invoked actions). The distinction is the control model per capability, not the server.
Why does forcing a tool guarantee structured output?
The model must emit a tool_use that conforms to that tool's input schema, so the result is a validated, machine-parseable object rather than free-form prose. The trade-off is no pre-call reasoning and incompatibility with extended thinking.
When should guidance live in a tool description instead of the system prompt?
Whenever it's specific to one tool — especially when to call it. Keep the system prompt for persona, global rules, and framing that apply no matter which tools exist.
If I can gate an action in a tool, why use a hook?
Because a tool is discretionary — the model may not call it. A hook fires deterministically on the event, so it's the right place for anything that must happen every time (blocking, logging, formatting, approval gates).
Independent, unofficial study material. Not affiliated with, endorsed by, or authorized by Anthropic. Every example is original and written to teach the public exam objectives — no real exam questions are reproduced. Technical details reflect Claude, the Anthropic API, Claude Code, and MCP as of July 25, 2026; always confirm specifics against current official documentation.
Test yourself
Turn what you just read into answers you can check.