# CCAR-F Practice: Tools & MCP | Your AI Department > 35 free CCAR-F practice questions on tool design and MCP (18% of the exam), with study notes and explanations. Source: https://youraidept.com/network/ccar-f-practice-questions/tool-design-and-mcp CCAR-F domain drill # CCAR-F practice questions: Tool design and MCP. 35 original questions on Tool design and MCP, which carries 18% of the Claude Certified Architect – Foundations exam per the published guide. Study notes first, then the questions with an explanation for each. When this domain feels solid, take [the timed CCAR-F practice exam](https://youraidept.com/network/ccar-f-practice-exam) and check the domain breakdown. ## What to know about Tool design and MCP - A tool definition is a name, a description, and a JSON schema for inputs. The description is what the model reads to decide when to call it; write it for the model, with edge cases and examples. - A few well scoped tools work better than many overlapping ones. Namespace related tools, return meaningful context rather than raw dumps, and keep responses within a sane token budget. - The tool_choice parameter (auto, any, a specific tool, none), parallel tool use, and how a tool result with an error flag differs from a successful result. - MCP primitives: tools, resources, and prompts. Servers expose them; clients (Claude Code, the Agent SDK, Claude.ai) connect to them. - MCP transports: stdio for local processes, streamable HTTP for remote servers, and where authentication sits for remote ones. - Idempotency and safety: which tools need confirmation, which are read-only, and how the schema and description communicate that. ## Tool design and MCP questions All domains (35) Tool design and MCP (35) Tool design and MCP A tool named q with the description "queries db" is being called at the wrong times with the wrong arguments. Best fix? - Add separate tools for each common query so the model no longer has to work out the arguments - Rename it and write a description covering when to use it, what each parameter means, and edge cases - Add a system prompt rule that the model should think carefully before every database query - Return a longer error message from the tool whenever the arguments do not match a known query Check answer ### Show answer Answer: Rename it and write a description covering when to use it, what each parameter means, and edge cases. The description is what the model reads to decide when and how to call a tool; write it for the model, with parameter meanings, edge cases, and an example. More tools with the same thin descriptions multiply the confusion, and error messages only help after a wrong call has already been made. Tool design and MCP You need the model to call one specific tool on this turn, no matter what. Which setting? - tool_choice set to auto with the tool listed first in tools - disable_parallel_tool_use set to true and one tool listed - tool_choice set to that tool by name, forcing the call - tool_choice set to any, so the model must call some tool Check answer ### Show answer Answer: tool_choice set to that tool by name, forcing the call. tool_choice with a specific tool name forces that call. any forces some tool but leaves the choice to the model; auto leaves the decision to the model entirely, regardless of tool order; disable_parallel_tool_use limits how many calls happen, not whether one does. Tool design and MCP An MCP server will run on the developer's own machine, launched by the client as a child process. Which transport? - WebSockets over a public URL - Server-sent events endpoint - stdio over the child process - Streamable HTTP on localhost Check answer ### Show answer Answer: stdio over the child process. stdio is the transport for a local server the client launches as a child process. Streamable HTTP is for remote servers that many clients connect to; running it on localhost works but adds a network layer and a port for no benefit here. Tool design and MCP A tool call fails because the record does not exist. What should the tool return so the agent can recover? - A successful empty result, so the loop continues and the model infers the record was missing - No result for that call, holding the turn until a person can look up the record by hand - A tool result flagged as an error, with a message saying the record was not found and what ids are valid - The raw exception and stack trace from the database driver, so the model can see exactly which query failed Check answer ### Show answer Answer: A tool result flagged as an error, with a message saying the record was not found and what ids are valid. Error results with actionable messages let the model choose a different path. An empty success hides the failure and invites the model to proceed on a missing record; a raw stack trace is an error the model has to decode rather than act on. Tool design and MCP Two tools, search_customers and find_customers, do nearly the same thing and the model picks inconsistently. What should you do? - Add a routing instruction to the system prompt that says which tool to prefer - Merge them into one well-described tool, or make their purposes clearly distinct in name and description - Set tool_choice to the preferred tool so the model no longer has to choose - Keep both and add a third tool that wraps them and picks the right one internally Check answer ### Show answer Answer: Merge them into one well-described tool, or make their purposes clearly distinct in name and description. Overlapping tools confuse selection; fewer, clearly scoped tools work better. Forcing tool_choice removes the model's choice on every turn, including turns where no tool is needed; a wrapper tool adds a third overlapping name. Tool design and MCP A tool returns a 4 MB JSON dump on every call and the agent's context fills quickly. Best fix? - Ask the model to summarize each result before continuing so the raw dump is dropped - Return only the fields the task needs, paginate, and let the model request more - Call the tool less often by caching its output in the system prompt for the session - Compress the JSON before returning it so it occupies fewer tokens in context Check answer ### Show answer Answer: Return only the fields the task needs, paginate, and let the model request more. Tools should return concise, meaningful context, not raw dumps. Compressing JSON does not reduce tokens meaningfully; having the model summarize still costs the full dump in context first. Tool design and MCP Which naming convention helps a model with many tools? - Consistent namespacing by system, such as crm_search and crm_update - Short names of one or two characters so the tool list stays compact - Names that describe the return type, such as list_result and single_result - Names that include the version, such as search_v2, so the model picks the latest Check answer ### Show answer Answer: Consistent namespacing by system, such as crm_search and crm_update. Predictable, namespaced names make the tool surface legible to the model. Return-type names say nothing about purpose; version suffixes ask the model to guess which one is current. Tool design and MCP An MCP server exposes a 'prompts' primitive. What is it for? - Reusable prompt templates the client can discover and invoke - The configuration block that tells the client how to authenticate and transport - Instructions the server injects into the client's system prompt on connect - The templates a tool uses to format its own results before returning them Check answer ### Show answer Answer: Reusable prompt templates the client can discover and invoke. MCP has tools, resources, and prompts; prompts are reusable templates the client exposes to the user. Servers do not inject text into the client's system prompt; authentication and transport are handled outside the primitives. Tool design and MCP A remote MCP server holds customer data. Which is required? - Restricting the server to read-only tools so a compromised client cannot change data - Storing an API key in the tool description so the model can present it on each call - Running the server over stdio through an SSH tunnel so that no HTTP endpoint is ever exposed to the network - Authentication and authorization on the server, with the client presenting credentials Check answer ### Show answer Answer: Authentication and authorization on the server, with the client presenting credentials. Remote servers with sensitive data need auth like any other service. Read-only tools still leak customer data to anyone who connects; a key in the tool description is visible to every client and the model. Tool design and MCP What should a tool's description include beyond what it does? - When to use it and when not to, parameter meanings, and edge cases - The list of other tools that must be called before it, so ordering is explicit - The expected latency and rate limits so the model can plan parallel calls - The server it lives on and the endpoint it calls, so the model can troubleshoot failures Check answer ### Show answer Answer: When to use it and when not to, parameter meanings, and edge cases. The description is the model's decision guide for the tool. Endpoint details and latency are operational data the model cannot act on; a required call order is better expressed by returning what the next call needs than by a list the model has to track. Tool design and MCP A tool has a 'delete' action and a 'read' action behind one parameter. Why is that a design problem? - Enum parameters are poorly supported in JSON Schema, so the model will often pass an invalid value - The model will default to the first enum value, so reads will be attempted as deletes - One parameter cannot carry two verbs, so the schema will fail validation on the API - Read-only and destructive actions need different gating; split them so the destructive one can be permissioned separately Check answer ### Show answer Answer: Read-only and destructive actions need different gating; split them so the destructive one can be permissioned separately. Separating safe and dangerous operations lets you gate the dangerous one. Enums are well supported and the schema is valid; the problem is not the schema but the fact that a permission rule cannot tell a read from a delete. Tool design and MCP The model calls a tool with a date in the wrong format, repeatedly. Best fix? - Remove the date parameter and have the tool default to today, asking the user for other dates - Add a schema format hint and an example value in the description, and return a clear error on bad input - Add a system prompt rule stating the date format, since the model reads the tool description less carefully - Accept any format the model sends and normalize it inside the tool, so the loop never stalls Check answer ### Show answer Answer: Add a schema format hint and an example value in the description, and return a clear error on bad input. Schema hints, examples, and actionable errors fix malformed calls. Silent normalization hides a defect that will bite when a date is ambiguous; the tool description is exactly where the model looks when it builds the call. Tool design and MCP When is parallel tool use appropriate? - When latency matters, regardless of whether one call's input comes from another - When the model is confident about all the arguments before the first result returns - When the calls are independent and the results do not depend on one another - When the tools belong to the same MCP server, so one connection can batch them Check answer ### Show answer Answer: When the calls are independent and the results do not depend on one another. Independent calls can run concurrently; dependent ones cannot. Latency is the motivation, not the condition; if one call needs another's output, it has to wait. The server they belong to is irrelevant. Tool design and MCP Which is a resource in MCP terms? - The transport the client uses to reach the server, such as stdio or streamable HTTP - Data the client can read, like a file or a record, addressed by URI - A function the model can call to change state on the server - A reusable template the user selects to start a conversation Check answer ### Show answer Answer: Data the client can read, like a file or a record, addressed by URI. Resources are readable data; tools are callable actions; prompts are templates. Transport is how the client connects, not one of the three primitives. Tool design and MCP A tool should be idempotent when: - It only reads data, since reads are the calls the loop repeats most - Its effects must be safe to repeat, because agent loops retry - It has no parameters, so every call is identical by construction - It runs over stdio, where a dropped connection replays the call Check answer ### Show answer Answer: Its effects must be safe to repeat, because agent loops retry. Retries are normal; idempotency makes them harmless. Read-only tools are already idempotent by nature; the property matters for tools with side effects. Transport does not replay calls. Tool design and MCP What is the safest default for a new tool that writes to an external system? - Disabled in production and enabled only in a staging environment until accuracy is measured - Autonomous use for small writes and confirmation for large ones, with the threshold set by the model - Requires confirmation until its accuracy is measured - Autonomous use with a nightly report of what it wrote, so problems surface within a day Check answer ### Show answer Answer: Requires confirmation until its accuracy is measured. Start gated; expand autonomy on evidence. Staging-only means no real accuracy data; letting the model set its own threshold makes the model the gate again. Tool design and MCP A tool takes 20 optional parameters and the model rarely sets them correctly. Best redesign? - Move the parameter guidance into the system prompt so it is not lost in the schema - Keep the tool but add a validation step that rejects calls with unset parameters - Make every parameter required so the model has to think about each one explicitly - Split into focused tools with few required parameters and sensible defaults Check answer ### Show answer Answer: Split into focused tools with few required parameters and sensible defaults. Narrow tools with few parameters are easier to call correctly. Making all 20 required makes every call harder, and validation catches errors without reducing them. Tool design and MCP What should a search tool return to be most useful to an agent? - The raw response from the underlying search service, unmodified - A count of matches with a suggestion to narrow the query whenever the count is above a threshold - Every matching record in full, so the agent never needs a second call - A compact ranked list with identifiers and snippets, plus a way to fetch details Check answer ### Show answer Answer: A compact ranked list with identifiers and snippets, plus a way to fetch details. Compact, actionable, and fetchable. Full records flood the context, and a count alone gives the agent nothing to act on. Tool design and MCP Which MCP capability lets a server suggest a full workflow prompt to the client? - Resources, which expose text or data the client can load into context by URI when it needs it - Sampling, which lets the server request a completion from the client's model - Prompts, which are reusable templates the client can present for the user to invoke - Tools, which return a suggested plan the client then executes step by step Check answer ### Show answer Answer: Prompts, which are reusable templates the client can present for the user to invoke. Prompts are reusable templates exposed by servers. Resources expose data, tools perform actions, and sampling runs in the other direction. Tool design and MCP A tool's description says 'Use this for anything related to customers'. Why is that weak? - It is too broad: it invites misuse and overlaps with other tools; describe the job and when not to use it - It is phrased as an instruction to the model, when descriptions should be neutral statements of what the tool does and returns - It fails to list the parameter types, so the model cannot construct a valid call - It is too short; a description should run to several paragraphs to cover every case Check answer ### Show answer Answer: It is too broad: it invites misuse and overlaps with other tools; describe the job and when not to use it. Specificity guides selection. Parameter types belong in the schema, and length alone does not make a description useful. Tool design and MCP When should a tool return an error rather than a best-effort result? - Only when the model has asked for strict mode; otherwise return a best-effort result silently - When the input is invalid or the operation cannot complete correctly, with a message saying what would fix it - Only on timeouts and network failures; for bad input, return the closest valid result with a note explaining the substitution - Whenever the operation partially succeeds, so the model retries the whole call from scratch Check answer ### Show answer Answer: When the input is invalid or the operation cannot complete correctly, with a message saying what would fix it. Honest errors beat silent partials, and an actionable message lets the model correct the call. Returning the closest valid result for bad input hides the problem from the model. Tool design and MCP Which is true of tool_result blocks? - They replace the assistant's tool_use block in the conversation history - They are returned in a user turn, matched to the tool_use block's id - They are placed in the system prompt so the model sees them on every later turn - They must contain valid JSON so the model can parse them reliably Check answer ### Show answer Answer: They are returned in a user turn, matched to the tool_use block's id. Results come back in the next user turn, matched by id to the tool_use block, which stays in the history. Content can be text, JSON, or images; JSON is not required. Tool design and MCP How do you keep an MCP server safe when it exposes both read and write operations? - Trust the model's judgment on each call but log every write so problems can be traced and reversed afterward - Separate read and write tools, require authentication, and gate writes with confirmation or scopes - Combine reads and writes in one tool with a mode flag so the model sees fewer tools - Expose write operations only over stdio, since local transport limits who can call them Check answer ### Show answer Answer: Separate read and write tools, require authentication, and gate writes with confirmation or scopes. Separate the tools, authenticate callers, and gate writes. A mode flag makes it easier to write by accident, and logging after the fact does not prevent damage. Tool design and MCP A model keeps calling a tool that is not relevant to the task. Which fix comes first? - Delete the tool from the set, since a tool that gets misused is a net cost - Lower the temperature so the model becomes more conservative about tool selection - Add a system prompt rule that lists the exact tasks the tool may be used for and the tasks it may not - Tighten its description with 'when not to use' guidance and check for overlap with other tools Check answer ### Show answer Answer: Tighten its description with 'when not to use' guidance and check for overlap with other tools. Descriptions drive selection, so fix the description and any overlap first. A system prompt rule can help but is further from the point of choice than the tool's own description. Tool design and MCP Why include units and formats in parameter descriptions? - They let the model skip the schema and construct calls from the description alone - So the model supplies values the tool can parse, avoiding silent errors - They are mainly for the humans who review tool calls in the logs - The MCP specification requires units in every numeric parameter description Check answer ### Show answer Answer: So the model supplies values the tool can parse, avoiding silent errors. Precision prevents malformed calls, such as seconds passed where milliseconds were expected. Descriptions are model-facing, and the schema still applies. Tool design and MCP What is a good reason to expose a resource instead of a tool? - The data is read-only reference material the client can load on demand by URI - Loading the data has side effects that should be visible in the audit log - Access to the data requires a human approval step before it is released - The data changes every second and the client needs the freshest possible copy Check answer ### Show answer Answer: The data is read-only reference material the client can load on demand by URI. Read-only reference data suits resources. Side effects and approval gates are tool concerns. Tool design and MCP A tool's parameters are named a, b, and c. Why does that hurt? - The model cannot infer meaning, so it guesses; descriptive names and descriptions fix it - It only matters if the tool has no description, since the description explains the parameters - Single-letter names shrink the JSON payload, so this is a reasonable trade for speed - The schema will fail validation because JSON Schema requires property names of three or more characters Check answer ### Show answer Answer: The model cannot infer meaning, so it guesses; descriptive names and descriptions fix it. Names carry meaning to the model. A description helps, but the model reads the schema at call time and short names give it nothing. Tool design and MCP Which tool response is best for a 'list orders' call that matched 5,000 orders? - The first page with a total count and a cursor for more - An error telling the model to narrow the query before retrying - The total count only, with a note that details are available on request - All 5,000 orders, so the model has everything it needs in one call Check answer ### Show answer Answer: The first page with a total count and a cursor for more. Paginate with a cursor and a total. Forcing a narrower query throws away a valid result, and a count alone gives the model nothing to work with. Tool design and MCP When should a tool call require confirmation in a Claude Code or Agent SDK setup? - Only for reads from production systems, since reads can expose sensitive data - When it writes, deletes, sends, or spends, until its accuracy is proven - For every call, since the cost of asking is small compared with any wrong action - Only when the model reports low confidence in the parameters it chose Check answer ### Show answer Answer: When it writes, deletes, sends, or spends, until its accuracy is proven. Side effects need gates until accuracy is measured. Confirming every call, including reads, makes the gate noise that people stop reading. Tool design and MCP What is the practical difference between exposing data as an MCP resource versus returning it from a tool call? - Resources are for structured data and tools are for text, so the choice follows the payload type - Resources require user approval before the client loads them; tool calls are executed by the model directly without a prompt - Resources are addressable read-only data the client loads when needed; tools perform actions and return results - Resources are faster because the client caches them; tool results are fetched fresh every time Check answer ### Show answer Answer: Resources are addressable read-only data the client loads when needed; tools perform actions and return results. Resources are addressable read-only data the client loads on demand; tools perform actions and return their results. Neither is defined by payload type or caching. Tool design and MCP A remote MCP server should identify which agent is calling. Why? - The stdio transport requires a caller id in every request frame - The server selects which model to use based on the calling agent - Identified callers get their tool lists cached, which speeds up discovery - Authorization, rate limits, and audit depend on knowing the caller Check answer ### Show answer Answer: Authorization, rate limits, and audit depend on knowing the caller. Identity underpins control. Model selection is the client's concern, and stdio is the transport a remote server does not use. Tool design and MCP An agent misuses a tool because its description was written for developers. What changes? - Keep the developer description and add a system prompt section explaining to the model how and when to use the tool - Move the developer notes into the parameter descriptions where the model reads them - Rewrite it for the model: what it does, when to use it, when not to, parameter meanings, an example - Add more parameters so the model has finer control over the tool's behavior Check answer ### Show answer Answer: Rewrite it for the model: what it does, when to use it, when not to, parameter meanings, an example. Descriptions are model-facing, so rewrite the description itself. A system prompt section is further from the point of selection than the tool's own text. Tool design and MCP How should a tool report partial success, such as 8 of 10 records updated? - Return success, since most of the records were updated and the model can move on - Retry the failed records silently inside the tool and return success once they complete - Return a structured result listing what succeeded and what failed, with reasons - Return failure so the model retries the whole batch until every record succeeds Check answer ### Show answer Answer: Return a structured result listing what succeeded and what failed, with reasons. Partial outcomes need detail. A blanket failure triggers a retry of the eight records that already succeeded. Tool design and MCP Which MCP transport suits a server that many users hit concurrently from a web app? - Streamable HTTP, which supports remote, concurrent clients - WebSocket only, since HTTP cannot carry the server's notifications - A shared file system watched by the server for request files - stdio, with one server process spawned per user session on the web host Check answer ### Show answer Answer: Streamable HTTP, which supports remote, concurrent clients. Remote, concurrent access is Streamable HTTP. stdio is for a local process owned by one client. Tool design and MCP Why keep tool schemas strict rather than accepting free-form strings? - Strict schemas are optional in the API, so this is a style preference rather than a requirement - Free-form strings are faster to generate, but strict schemas produce shorter code - Free-form strings are rejected by the Messages API, so strict schemas are required - Strict schemas let the model produce valid calls and let you validate before execution Check answer ### Show answer Answer: Strict schemas let the model produce valid calls and let you validate before execution. Validation before action. The API accepts string parameters; the point is that strict types catch bad calls before they run. ## Next - [Timed CCAR-F practice exam](https://youraidept.com/network/ccar-f-practice-exam): 60 questions in 120 minutes, scored against the 720 pass mark. - [All CCAR-F practice questions](https://youraidept.com/network/ccar-f-practice-questions) with a domain filter. - [The CCAR-F exam page](https://youraidept.com/network/ccar-f): format, weights, registration, study path. ### Other CCAR-F domains - [Agentic architecture (52 questions)](https://youraidept.com/network/ccar-f-practice-questions/agentic-architecture) - [Claude Code workflows (40 questions)](https://youraidept.com/network/ccar-f-practice-questions/claude-code-workflows) - [Prompt engineering (40 questions)](https://youraidept.com/network/ccar-f-practice-questions/prompt-engineering) - [Context management (33 questions)](https://youraidept.com/network/ccar-f-practice-questions/context-management) ## FAQ ### How much of the CCAR-F exam is tool design and MCP? + 18% of the marks, per the published CCAR-F exam guide. The full domain list with weights is on the CCAR-F exam page. ### Are these real CCAR-F exam questions? + No. They are 35 original scenario questions written from the blueprint for this domain. Reproducing exam content would violate the candidate agreement. ### How should I study tool design and MCP for CCAR-F? + Read the domain notes on this page, answer the questions with explanations hidden, then take the timed CCAR-F practice exam and check the per-domain breakdown for this domain. ## Who wrote this ### [Matei Olaru](https://youraidept.com/about/matei-olaru) CEO, Your AI Department Former public-company CEO, corporate attorney, and World Bank consultant. Runs the YAID Network and the partner relationship with Anthropic. ### [Michael Greenberg](https://youraidept.com/about/michael-greenberg) AI Product Lead, Your AI Department AI at Google, Meta, and Samsung. Six patents. Leads member support and the certification prep guidance. Your AI Department is a registered Claude Partner Network company. Our members sit these exams under our partner standing. Facts on this page were last checked on October 15, 2026. ## Ready to sit CCAR-F for real? Registration needs a Claude Partner Network organization. [YAID Network](https://youraidept.com/network) members register under our partner standing. $149 per quarter, exam fee separate. [Apply to join YAID ↗](https://youraidept.com/network/apply?ref=drill)[How registration works →](https://youraidept.com/network/register-for-claude-certification)