CCAR-F practice questions: 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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