MCP Communication Patterns for the CCDV-F Exam

Connecting a client to a server

Authoring an MCP server defines what it exposes; a communication pattern is how a client actually connects to it. On the Claude Certified Developer - Foundations (CCDV-F) exam, this knowledge point sits at the apply level, which means you are expected to choose the right transport and topology for a given deployment, not just recite names. Two ideas carry it: the transport (stdio versus sockets) and the roles (client versus server).

stdio: a local server process

The stdio transport connects a local server process to the client running on the same machine. The client launches or talks to the server over standard input and output streams, and both live on the same host. This is the natural pattern for a server that is specific to one machine or one user's environment: a filesystem server, a local development tool, anything where the capability lives where the client runs and does not need to be shared across a network.

The strength of stdio is simplicity and locality. There is no network hop, no remote endpoint to secure, and the server is right there beside the client. The limitation is exactly the flip side: a stdio server is reachable only on that one machine, so it cannot be shared by clients running elsewhere.

Sockets: a networked server

The socket-based transport connects to a networked server the client reaches remotely. Here the server runs as a networked service, potentially on separate infrastructure, and clients connect to it over the network rather than by launching a local process. This is the pattern for a shared deployment: when many applications, possibly on many machines, all need the same MCP server, a networked socket-based server lets them all reach one central instance.

The strength of the networked pattern is reach and sharing: one deployed server serves many remote clients. The cost, echoing the client-side versus server-side trade-off in tool usage patterns, is that you now have a network boundary to secure and network latency on every call. The choice between stdio and sockets is therefore a choice about where the server needs to be reachable from.

Client versus server: who does what

The second idea is the roles, and it is a frequent exam trap. In MCP the client initiates the connection and the server exposes the capabilities. The Claude application is the client: it reaches out and connects. The MCP server is what it connects to: it exposes the tools, resources, and prompts. This holds regardless of transport, whether the client launches a local stdio process or dials a remote socket, the client is still the initiator and the server is still the provider.

Getting this backwards is a real error the exam probes. If you imagine the server reaching out to the application, or the application exposing tools to the server, you have inverted the relationship and will misread connection scenarios. Anchor it firmly: client initiates, server exposes.

Matching the transport to the deployment

The apply-level skill here is choosing correctly. If the server is specific to a single machine or user environment and does not need to be shared, stdio is the clean fit: local, simple, no network to secure. If the server must be reached by multiple clients or must live on shared infrastructure, a socket-based networked deployment is required, because a local stdio server simply cannot be reached from other machines.

The central exam trap is using a local stdio server where a networked, shared deployment is required. A scenario might describe a team that stood up a filesystem-style stdio MCP server and then wonders why colleagues on other machines cannot use it. The answer is that stdio is inherently local; sharing across machines needs the networked socket-based transport. This is the deployment concern that MCP server authoring and deployment first raised, now made concrete as a transport choice.

The traps the exam sets

Two traps dominate. The first is the transport mismatch: using a local stdio server where a networked, shared deployment is required. The tell is that clients on other machines cannot reach a server that works fine locally. The fix is a socket-based networked deployment.

The second is confusing which side is the client and which exposes the capabilities. If a scenario or answer describes the server initiating the connection to the app, or the app exposing tools to the server, it has the roles inverted. The client initiates; the server exposes.

Common misreadings to avoid

How this is tested on the exam

Domain 8 questions on this knowledge point give you a deployment and ask which transport fits, or describe a connection that fails and ask why. The correct answers trace back to the two ideas here: stdio is local and sockets are networked, and the client always initiates while the server exposes. Because this is an apply-level knowledge point, you must pick the right pattern for the situation, a local stdio server for a single-machine capability, a networked socket-based server for a shared one, and never invert the client-server roles.