What this domain covers
This is the largest-weighted material you will face in this area of the Claude Certified Architect exam. Expect scenario-based questions that test whether you can apply these concepts, not just recall them.
- Writing detailed tool descriptions and clear input schemas
- Structured error responses that let the model self-correct
- The tool-use loop and tool_choice options
- Parallel tool calls and tool_result blocks
- MCP architecture: host, client, server, and primitives
- MCP transports (stdio, streamable HTTP) and the MCP connector
- Integration security and prompt injection via tool results
Free practice questions: Tool Design & MCP Integration
8 original, exam-style questions from this domain. Reveal each answer for the full explanation.
Which of the following tool names is valid for the Claude Messages API?
- Asearch customer records
- Bvector_db-search_v2
- Cget.stock.price
- Dchercher_météo
▸Show answer & explanation
Answer: B. vector_db-search_v2
Tool names must match the regex ^[a-zA-Z0-9_-]{1,64}$: only ASCII letters, digits, underscores, and hyphens, with a length of 1 to 64 characters. Spaces, periods, and accented or other non-ASCII characters are all rejected, which rules out the other three options. Underscores and hyphens are both permitted, so mixing them as in the correct option is fine.
Read the docs →What guidance does Anthropic give about the length of a tool description?
- AAim for at least 3 to 4 sentences per tool, and more for complex tools
- BKeep it to a single sentence so tool definitions consume as few tokens as possible
- CKeep it under 10 words because the API truncates longer descriptions
- DLength does not matter because Claude relies only on the input_schema when choosing tools
▸Show answer & explanation
Answer: A. Aim for at least 3 to 4 sentences per tool, and more for complex tools
The documentation says to aim for at least 3 to 4 sentences per tool description, and more for complex tools. Ultra-short descriptions appear as the poor example in the docs, the API does not truncate description text at any short word count, and Claude weighs the description heavily rather than relying on input_schema alone.
Read the docs →Which three core primitives can an MCP server expose to connected clients?
- ASampling, roots, and elicitation
- BFunctions, embeddings, and completions
- CTools, hooks, and skills
- DTools, resources, and prompts
▸Show answer & explanation
Answer: D. Tools, resources, and prompts
MCP servers expose tools (executable functions), resources (data sources for context), and prompts (reusable templates). Sampling, roots, and elicitation are the primitives exposed by clients, not servers, while hooks and skills are Claude Code concepts rather than MCP protocol primitives.
Read the docs →What guidance do Anthropic's docs give about the length of a tool description?
- AAim for at least 3-4 sentences per tool description, and more when the tool is complex
- BKeep each description to a single sentence, because longer text dilutes the model's attention across tools
- CLength is irrelevant because descriptions are metadata that never enter the model's prompt
- DStay under 100 characters so every description fits within the constructed system prompt
▸Show answer & explanation
Answer: A. Aim for at least 3-4 sentences per tool description, and more when the tool is complex
The documentation recommends at least 3-4 sentences per description, with more detail for complex tools. Descriptions are injected into the tool use system prompt and strongly influence behavior, so they are not inert metadata. The docs' "poor description" example is exactly the terse one-liner style, which leaves Claude with open questions about usage.
Read the docs →What information does a tool_use content block in a Messages API response contain?
- AAn id, the tool name, and an output field populated once the API finishes executing the tool
- BAn id to match results to the call, the name of the tool, and an input object conforming to the tool's input_schema
- CA tool_use_id, a content field, and an optional is_error flag
- DThe tool name, an arguments field containing a JSON-encoded string, and a call_index
▸Show answer & explanation
Answer: B. An id to match results to the call, the name of the tool, and an input object conforming to the tool's input_schema
A tool_use block carries an id used to match the eventual result, the name of the tool, and an input object that conforms to the tool's input_schema. tool_use_id, content, and is_error are fields of the tool_result block you send back, not of tool_use. There is no output field because the API does not execute client tools, and input arrives as a parsed JSON object rather than an encoded arguments string.
Read the docs →How does an MCP client communicate with a local MCP server over the stdio transport?
- AThe client opens a WebSocket connection to a port number the server prints when it starts up.
- BThe client and server exchange messages through a shared memory-mapped file on the local disk.
- CThe client polls a Unix domain socket that the server creates in the current working directory.
- DThe client launches the server as a subprocess and exchanges newline-delimited JSON-RPC messages through the server's standard input and standard output.
▸Show answer & explanation
Answer: D. The client launches the server as a subprocess and exchanges newline-delimited JSON-RPC messages through the server's standard input and standard output.
In the stdio transport the client launches the server as a subprocess, writes JSON-RPC messages to the server's stdin, and reads responses from its stdout, with messages delimited by newlines. WebSockets, shared memory, and Unix domain sockets are not part of the two standard MCP transports, which are stdio and Streamable HTTP.
Read the docs →Which wire format do all MCP messages use, regardless of which transport carries them?
- AProtocol Buffers over gRPC, with JSON permitted only for local debugging.
- BJSON-RPC 2.0, with requests, responses, and notifications encoded as UTF-8 JSON.
- CREST-style resource URLs where the HTTP verb encodes the operation being performed.
- DGraphQL queries and mutations validated against a schema the server publishes.
▸Show answer & explanation
Answer: B. JSON-RPC 2.0, with requests, responses, and notifications encoded as UTF-8 JSON.
MCP's data layer is built on JSON-RPC 2.0, and every transport (stdio, Streamable HTTP, or a custom transport) must preserve that message format, encoded as UTF-8. MCP is not defined in terms of Protocol Buffers, REST resource semantics, or GraphQL, even though Streamable HTTP happens to use HTTP as a carrier.
Read the docs →Which set of fields defines each custom tool passed in the tools parameter of a Messages API request?
- Aname, endpoint_url, and http_method, so the API can invoke the tool on your server
- Bfunction_name, arguments, and return_type, matching the standard function-calling format
- Cname, input_schema, and handler (a callback function the API executes when the tool is selected)
- Dname, description, and input_schema (a JSON Schema object describing the tool's expected parameters)
▸Show answer & explanation
Answer: D. name, description, and input_schema (a JSON Schema object describing the tool's expected parameters)
Each custom tool in the tools parameter is defined by a name, a description, and an input_schema expressed as JSON Schema; an optional input_examples array can also be added. The API never invokes your code directly, so there is no endpoint, HTTP method, or handler to register: your application executes the tool when Claude emits a tool_use block. The function_name/arguments/return_type shape belongs to other providers' APIs, not the Claude Messages API.
Read the docs →Drill this domain in Claude Prep
The app has dozens more questions in this domain alone, plus a Domain Drill mode that focuses your practice exactly here, and full mock exams that weight it at 18%.