# Quiz — Advanced Level, Session 2 # “Advanced tool use” **Program:** Applied AI — Yann Isola **Format:** 10 MCQs (Multiple Choice Questions), certification level Claude Certified Architect **Recommended scale:** 1 point per question, mastery threshold: 8/10 **Duration:** 20 min The commented corrections are at the end of the document. --- ### Q1 — Life cycle Your application receives a response from the Messages API with `stop_reason: "tool_use"`. What does this field mean and what is the correct next step? - A. The model executed a tool; you must read the result in `response.content`. - B. The model requires the execution of one or more tools; Your code should execute each `tool_use` block and return the `tool_result` in a `role: "user"` message. - C. The model encountered a tool error; you must retry the request with the same messages. - D. The conversation is over; the assistant used an internal tool to produce its final response. --- ### Q2 — Tool_result format What message is **valid** to return a tool result to the Anthropic API? - A.`{"role": "tool", "content": [{"type": "tool_result", "tool_use_id": "toolu_01A", "content": "42"}]}` -B.`{"role": "user", "content": [{"type": "tool_result", "tool_use_id": "toolu_01A", "content": "42"}]}` - C. `{"role": "assistant", "content": [{"type": "tool_result", "tool_use_id": "toolu_01A", "content": "42"}]}` - D.`{"role": "user", "content": [{"type": "tool_output", "id": "toolu_01A", "content": "42"}]}` --- ### Q3 — Chat history After receiving a `tool_use` block, a developer constructs the following request including only: the initial user message + a user message with the `tool_result`. What is happening? - A. The API accepts: `tool_use_id` is enough to make the link. - B. The API accepts but the model ignores the result. - C. The API returns a 400 error: the assistant message containing the corresponding `tool_use` block must appear in the history. - D. The API returns an error 429 (rate limit). --- ### Q4 — tool_choice You build an intention router: each user message must be classified by ONE of the 5 routing tools available, depending on the model. Which `tool_choice` is best suited? - A.`{"type": "auto"}` -B.`{"type": "any"}` - C.`{"type": "tool", "name": "route_intent"}` - D. Omit `tool_choice` and require it in the system prompt. --- ### Q5 — Structured output What is the main advantage of the “false tool” pattern (tool never executed + `tool_choice: {"type": "tool", ...}`) compared to the “reply only in JSON” instruction in the prompt? - A. It reduces latency, because the model generates fewer tokens. - B. It semantically guarantees that the extracted values ​​are exact. - C. It guarantees schema-compliant output (parsed JSON, constrained fields and types), eliminating spurious text and format errors. - D. It is less expensive, because tool definitions do not consume input tokens. --- ### Q6 — Taxonomy of errors An extraction pipeline returns valid, schema-compliant JSON, but consistently categorizes "refund" tickets as `technique` instead of `facturation`. What is the nature of the error and the priority remedy? - A. Syntactic → retry the call (retry) with the same request. - B. Syntactic → increase `max_tokens`. - C.Semantics → refine the prompt: enrich the description of the tool and enum values, add examples. - D. Semantics → retry the call: the temperature will introduce corrective variability. --- ### Q7 — is_error Your `get_invoice` tool throws an “invoice not found” exception. What is the best practice? - A. Break the loop and display the exception to the end user. - B. Return a `tool_result` with `is_error: true` and an actionable message (e.g. "INV-123 invoice not found, check identifier"), then let the model decide what to do next. - C. Do not return anything for this `tool_use` and let the model try again spontaneously. - D. Return the complete stack trace in `content` so that the model has as much information as possible. --- ### Q8 — Multi-tool A template response contains two blocks `tool_use` (ids `toolu_A` and `toolu_B`). What is the correct way to return results? - A. Two successive `role: "user"` messages, one by `tool_result`. - B. A single message `role: "user"` containing the two blocks `tool_result`, each with its `tool_use_id`. - C. A single `tool_result` concatenating the two outputs, with the id of the first block. - D. Execute only the first tool: the model will request the second one again the next turn. --- ### Q9 — Security Which of these statements correctly describes the tool use security model? - A. The model runs the tools in a sandbox hosted by Anthropic, with the permissions declared in `input_schema`. - B. The model does not execute anything: the tools run in your code with your authentications; So input validation and access control are entirely up to your application. - C. The API validates `input` against the schema and blocks any dangerous values ​​(SQL injection, file paths) before passing them to you. - D. Providing `enum` in the schema is enough to ensure that the values ​​received are safe for an SQL query. --- ### Q10 — max_tokens and tool_use A response arrives with `stop_reason: "max_tokens"` while the last block of `content` is a `tool_use` whose `input` seems incomplete. Which analysis is correct? - A. This is impossible: a `tool_use` block is always sent in full or not at all. - B. Semantic error: the model misunderstood the diagram; the description of the tool must be rewritten. - C. Syntactic error due to truncation: the JSON of the call has been cut; you must restart with a higher `max_tokens` and check `stop_reason` before any analysis. - D. Normal behavior: the API will complete the `input` on the next request using the `tool_use_id`. --- --- ## Commented fixes **Q1 → B.** `stop_reason: "tool_use"` = execution request, never an execution already done (A/D false: the model does not execute anything). This is false: trying again without sending `tool_result` does not advance the protocol. **Q2 → B.** At Anthropic, the `tool_result` is a content block in a `role: "user"` message (a classic trap for those coming from the OpenAI API, where there is a role `tool`). D invents a non-existent type `tool_output`. **Q3 → C.** Each `tool_result` must be preceded, in the history, by the assistant message containing the `tool_use` of the same id — otherwise rejection 400. The assistant message is returned as is (with all its blocks). **Q4 → B.** `any` forces the call of a tool while leaving the choice of which one: exactly a router.A does not offer any guarantee of appeal; C forces ONE specific tool (there is not just one here); D is based on obedience to the prompt, without structural guarantee. **Q5 → C.** The guarantee is **syntactic**: well-formed JSON, types and enums respected, no prose around it, and the SDK provides `input` already parsed. B is the trap: no **semantic** guarantee (the model can get the wrong value by respecting the diagram). D is false: definitions consume input tokens. **Q6 → C.** Valid format + false content = **semantic** error. The retry (A, D) generally reproduces the same error, because it reflects the understanding of the model, not a generational error. The remedy: richer descriptions, examples, possibly redistribution of the task. **Q7 → B.** `is_error: true` + actionable message = the model can catch up (correct the id, request clarification, explain the failure). Unnecessarily breaks the experience; C produces an orphan `tool_use` → error 400 in the next round; D wastes tokens and can leak internal details. **Q8 → B.** A `tool_result` by `tool_use`, all grouped in the following user message, correlated by `tool_use_id`. A/C/D violate the protocol or lose information (C mixes the correlations, D leaves a `tool_use` unanswered). **Q9 → B.** Cardinal principle: client-side execution, with your identifiers. The API does not validate the business security of the values ​​(C false); `enum` constrain the model but an architect treats any `input` as unreliable and parameters its SQL queries (insufficient D); there is no execution sandbox on the Anthropic side for your client tools (False). **Q10 → C.** Generation can be cut off in full JSON of `input` when the `max_tokens` budget is exhausted — truncation = **syntactic** error. Architect's reflex: always test `stop_reason` before parsing; remedy: increase `max_tokens` and restart. D invents a non-existent completion mechanism. --- ## Interpretation grid | Score | Reading | |---|---| | 9-10 | Ready for certification tool use questions | | 7-8 | Solid ; review the answers to missed questions (often Q3, Q5, Q10) | | ≤ 6 | Redo exercise 2 (debugging) and reread blocks 1 and 5 of the guide |