CCAR-F Tool Design and MCP Integration Practice Question
A team is exposing an existing internal REST API to Claude through an MCP server. The API requires an OAuth 2.0 bearer token per user, and the team wants each user's Claude session to act with that user's own permissions. Where should the per-user OAuth token be handled in the MCP architecture?
⚠ Common exam trap
The trap here is assuming the model should carry credentials because it orchestrates tool calls, when in fact the MCP server must own authentication and authorization.
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
✓
Have the MCP server obtain and hold the user's OAuth token, attaching it to outbound API calls on the user's behalf.
Per-user authorization requires the MCP server to act as the trust boundary: it acquires each user's OAuth token through the client's authorization flow and attaches it to outbound API calls. This preserves least privilege and isolation while keeping credentials out of the model's context and the tool schema. Shared service accounts, schema-embedded tokens, and tokens returned in results all break the isolation or leak secrets.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Return the token to the model in the tool result and instruct the model to include it in subsequent calls.
Why it's wrong here
Returning tokens in tool results leaks credentials into the conversation context, where they may be logged, cached, or surfaced to the user. It also makes the model responsible for credential lifecycle, which it cannot manage. Tokens should remain in the server's auth layer and never enter the model's context.
- ✓
Have the MCP server obtain and hold the user's OAuth token, attaching it to outbound API calls on the user's behalf.
Why this is correct
The MCP server is the trust boundary between the model and the upstream API. By acquiring the user's OAuth token through the client's authorization flow and attaching it to outbound requests, the server enforces per-user permissions without exposing secrets to the model. This keeps the tool schema free of credentials and preserves isolation across sessions.
- ✗
Store a single shared service account token in the server's environment variables and use it for all users.
Why it's wrong here
A shared service account collapses per-user permissions into one identity, so every user inherits the broadest access the account holds. This violates the requirement that each session act with the user's own permissions and creates an audit and least-privilege problem. It is simpler to operate but architecturally wrong for multi-tenant access.
- ✗
Embed the token in the tool's `inputSchema` so the model passes it as an argument on every call.
Why it's wrong here
Placing credentials in the input schema exposes them to the model and to any logs that capture tool arguments, and it forces the model to manage secrets it should never see. It also breaks per-user isolation if the model reuses a token across sessions. Credentials belong in the server's transport and auth layer, not in the tool contract.
About these practice questions
This CCAR-F question is part of Courseiva's 271-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.