CCAR-F Tool Design and MCP Integration Practice Question
An architect is designing an MCP server that exposes tools for a customer relationship management (CRM) system. The tools include 'get_customer', 'update_customer', and 'delete_customer'. The architect wants to ensure that tool invocations are properly authorized and audited. Which two design elements should be included in the MCP server implementation? (Choose two.)
⚠ Common exam trap
The trap here is thinking that embedding identity in the tool schema or relying on system prompts provides security, when real protection requires server-side token validation and independent audit logging.
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
✓
Validate the caller's OAuth 2.0 access token on every tool invocation before executing the operation.
The two correct elements are validating the caller's OAuth 2.0 access token on every invocation and logging full tool inputs/outputs with authenticated user ID and timestamp. Together they enforce authorization at the server and provide an audit trail. Token validation ensures only authorized callers can execute tools, while logging enables traceability and detection of misuse.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Rely on the model's system prompt to instruct it to only call tools when the user is authorized.
Why it's wrong here
System prompts are not a security control; they can be overridden or ignored by the model, especially under adversarial prompting. Authorization must be enforced by the server, not by instructions to the model. Trusting the prompt leaves the system vulnerable to prompt injection and accidental misuse, and it provides no verifiable audit trail of who authorized the action.
- ✓
Validate the caller's OAuth 2.0 access token on every tool invocation before executing the operation.
Why this is correct
Validating the OAuth 2.0 access token on each invocation ensures that only authenticated and authorized callers can execute tools. It ties tool execution to a verifiable identity and scope, preventing unauthorized access even if the model is manipulated. This is a standard security practice for MCP servers that expose sensitive operations and should be enforced server-side, independent of model behavior.
- ✗
Embed the caller's identity and permissions in the tool input schema as required parameters.
Why it's wrong here
Embedding identity in the input schema lets the model supply or alter identity claims, which is insecure. The model could fabricate a privileged user. Authorization context should come from the transport or session layer, not from model-generated arguments. This approach also bloats the schema and mixes concerns, making it harder to enforce consistent access control across all tools.
- ✗
Store a static API key in the MCP server configuration and use it for all tool calls regardless of caller.
Why it's wrong here
A static API key shared across all callers eliminates per-user authorization and accountability. It cannot distinguish between legitimate users or enforce scoped permissions, and if compromised it grants broad access. This design also fails audit requirements because all actions appear to come from the same identity, making it impossible to attribute changes to a specific user.
- ✓
Log the full tool input and output along with the authenticated user ID and timestamp for each invocation.
Why this is correct
Audit logging of inputs, outputs, user ID, and timestamp provides traceability for all tool executions. It enables detection of anomalous behavior, supports forensic analysis, and satisfies compliance requirements. Since the model can invoke tools with varying parameters, capturing the authenticated identity alongside the payload ensures that actions can be attributed to a real user or service account.
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.