CCDV-F Tools and MCP Integration Practice Question
A developer is building an MCP client that connects to a remote MCP server over HTTP with Server-Sent Events. The server advertises tools that require user-specific permissions. Which TWO practices should the developer implement to keep the integration secure and functional? (Choose two.)
⚠ Common exam trap
The trap here is treating MCP's JSON message format as if it provided security, leading to choices that skip authentication or TLS.
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 server's identity and TLS certificate, and reject connections that fail certificate verification.
Remote MCP servers with permission-scoped tools require two things: proof of who the user is, and protection of the channel carrying that proof. Completing the server's OAuth flow and sending the access token satisfies authentication, while validating TLS certificates prevents interception or impersonation. Shared credentials, plaintext transport, and indefinite caching all undermine per-user authorization and would make the integration both insecure and unreliable.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Validate the server's identity and TLS certificate, and reject connections that fail certificate verification.
Why this is correct
Because the client sends credentials and receives tool results over the network, verifying the server's TLS certificate prevents man-in-the-middle attacks and credential theft. Rejecting connections that fail verification ensures the client only talks to the legitimate MCP server. This complements authentication by protecting the confidentiality and integrity of the session, which is essential when tools are permission-scoped.
- ✓
Authenticate the connection using the server's supported OAuth flow and pass the resulting access token with each request.
Why this is correct
Remote MCP servers that gate tools behind user permissions expect an authentication credential. Completing the server's OAuth flow and sending the resulting access token on each request lets the server attribute calls to the correct user and enforce authorization. Without authentication, permission-scoped tools will be rejected or expose data incorrectly, breaking both security and functionality for this client.
- ✗
Hard-code a shared service account token in the client binary so all users inherit the same permissions.
Why it's wrong here
A shared service account token collapses all users into one identity, defeating per-user authorization and creating a serious audit and least-privilege problem. If the binary leaks, the credential is exposed to everyone. MCP servers that advertise user-specific permissions expect per-user credentials, so this approach would either be rejected or silently grant excessive access, which is unacceptable for a secure integration.
- ✗
Disable TLS termination to reduce latency, since MCP messages are already structured JSON.
Why it's wrong here
JSON structure provides no confidentiality or integrity on the wire. Disabling TLS would expose access tokens and tool results to interception and tampering. Latency savings are negligible compared with the security risk, and many OAuth-protected servers will refuse plaintext connections outright. Structured payloads are not a security control, so this choice undermines the entire remote integration.
- ✗
Cache all tool results on the client indefinitely so users avoid repeated permission checks.
Why it's wrong here
Indefinite caching can serve stale or revoked data and bypasses the server's authorization model over time. If a user's permission is withdrawn, cached results would still be returned, creating a data exposure. Caching should be scoped, short-lived, and invalidated on authorization changes. Persistent caching is not a security practice and conflicts with the requirement for user-specific permission enforcement.
About these practice questions
One of 257 original CCDV-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 CCDV-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 CCDV-F exam.