CCAR-F Tool Design and MCP Integration Practice Question
An MCP server exposes an `execute_task` tool that can run arbitrary shell commands in a sandbox. During evaluation, the architect observes that the model sometimes calls the tool with a command that succeeds but produces no useful output, then calls it again with a nearly identical command, repeating several times. Which design change most directly addresses this loop behavior?
⚠ Common exam trap
The trap here is treating repeated tool calls as a timeout or parameter problem when the real issue is ambiguous result semantics.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Return a structured result that distinguishes success with empty output from failure, and include guidance on the next valid action.
Loops typically arise when the model cannot tell the difference between an uninformative success and a failure, so it retries in the hope of a better result. A structured result that flags empty output as a distinct outcome, together with guidance about acceptable next actions, breaks that cycle. Input schema changes and tool splitting do not supply the missing feedback.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add a required `command` parameter to the schema so the model must always supply a command string.
Why it's wrong here
The schema already requires a command, since the model is successfully calling the tool. Making an existing requirement explicit does not change behavior. The loop occurs after the call returns, so tightening the input contract cannot resolve it.
- ✓
Return a structured result that distinguishes success with empty output from failure, and include guidance on the next valid action.
Why this is correct
The model repeats because a successful-but-empty result looks the same as an uninformative one, so it has no signal that retrying is pointless. Returning a structured result that separates the empty-success case from genuine failure, plus a hint about valid next actions, gives the model the information it needs to change strategy instead of looping. This targets the actual cause.
- ✗
Split `execute_task` into separate tools for read-only and mutating commands to reduce accidental side effects.
Why it's wrong here
Separating tools by side-effect class is good hygiene, but the observed loop involves commands that already succeed, not dangerous ones. The split does not give the model any new signal about why its output was unhelpful, so the retry pattern would persist. It addresses a different risk than the one observed.
- ✗
Increase the tool's timeout so slow commands have more time to return useful output.
Why it's wrong here
The observed commands succeed quickly and simply return unhelpful output, so timeout is not the limiting factor. Extending the timeout lengthens each unproductive call without changing the model's decision to retry. The loop stems from the model not receiving actionable feedback, not from premature termination.
About these practice questions
One of 271 original CCAR-F practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Anthropic exam blueprint
This CCAR-F practice question is part of Courseiva's free Anthropic certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CCAR-F exam.