MCP Integration in Claude Code
Last reviewed
Correct answer: B. The organisation has set that tool to blocked, so it is filtered out before Claude ever sees it.
Explanation
The principle — A capability can fail at three different moments, and the symptom tells you which. It can be absent, it can be offered and refused, or it can be offered and gated behind a prompt. Only the first one leaves no trace of a refusal.
Why the key is correct — An organisation can set a per-tool control on a connector, and when a tool is set to blocked Claude Code filters the tool out before Claude sees it, so it never appears in the tool list. That matches the symptom exactly: not a refusal, not a prompt, simply a tool Claude does not know about, while the connector itself is plainly healthy because its other tools work.
Why the others are wrong — A failed server would take all of its tools with it rather than one. A blocked tool does not appear and then refuse, which is the behaviour of a deny rule instead. And blocked is not a stricter version of the approval setting: the approval setting prompts on every call, which is a very visible behaviour, whereas blocking is silent because the tool was removed before anything could ask.
Remember this — Refused means a rule fired somewhere and you can go and find it. Absent means something removed the tool before the rule stage was ever reached, and the place to look in that case is organisational policy rather than anything in your own configuration.
Sources — Anthropic's Claude Code MCP reference, on organisation controls.
Sources
“Tool set to blocked: Claude Code filters the tool out before Claude sees it, so it never appears in the tool list.”
“Tool set to ask: Claude Code prompts on every call with the reason Your organization requires approval for this tool.”
Practise 10 questions on this topic
Take MCP Integration in Claude Code — Timed Test 1 (10 questions) — scored instantly, explanation for every question, no login.