CCDV-F - Tools and MCPs (10.6% of the exam) - Section 8.2
Develop and integrate MCP servers with Claude applications.
Published skill weight 2.1 percent. Covers authoring and deploying an MCP server, integrating it with Claude applications, the three primitives it exposes as resources, tools and prompts, and the communication patterns available including stdio and sockets and the split between client and server responsibilities.
MCP server authoringMCP server deploymentMCP resources, tools, and promptsstdio and socket transportsclient versus server responsibilities
Practice question for this objective
lock_openFree sampleTools and MCPsmedium
An engineering team is designing an MCP server for a ticketing system. It must expose the current sprint board, which is read-only reference content the model should be able to pull into context, and separately expose the ability to transition a ticket's state, which mutates the system. How should these two be modelled?
AModel both the sprint board and the state transition as tools, since both ultimately involve the server performing work on the model's behalf.
BModel the sprint board as a prompt template and the state transition as a resource, so each side of the workflow is retrievable by the client.
CModel both as resources and have the client interpret a state-transition resource read as a request to change the ticket's state.
DModel the sprint board as a resource and the state transition as a tool, keeping read-only context separate from the mutating action.check_circle Correct
Distinguish MCP resources, tools and prompts: resources supply read-only context, tools take actions, prompts are reusable interaction templates. The three MCP primitives are not interchangeable naming choices. Resources are read-only content a client pulls into context, tools are invocable actions that may have side effects, and conflating them removes the signal a client needs to decide what is safe to call automatically.
Why A is wrong: Tempting because a tool call can certainly fetch the board as well, but collapsing reference content into the tool surface loses the distinction between reading context and taking an action with a side effect.
Why B is wrong: Tempting because prompts and resources are both genuine MCP concepts, but a prompt is a reusable interaction template rather than data, and a resource cannot perform the mutation the transition requires.
Why C is wrong: Tempting because it gives the server one uniform surface to document, but it overloads a read primitive with a side effect, which hides the mutation from any client reasoning about what is safe to call.
Why D is correct: Correct because MCP resources carry read-only content the client can pull into context, while tools are the surface for actions with side effects, which is precisely the split described.
Answers that look right on this material and are not. Each one is a distractor from a different question in the CCDV-F bank for this domain.
Ask the platform team to delete the 36 unused tools from the shared server, so that every consuming application receives a smaller surface and the cost problem is solved once for all of them.
errorWhy it is wrong: Tempting because it fixes the symptom at the source, but those tools are the surface the other three applications depend on, so this trades one team's cost ceiling for three broken consumers.
Have each consuming application install whatever server build is current when it starts, so that all three converge on the newest tool surface without any team needing to track a version explicitly.
errorWhy it is wrong: Tempting because it removes version bookkeeping, but a floating install means the tool surface can change under an application between two restarts, which both breaks the staged cut-over and makes returning to last week's behaviour impossible.
The transport a server is reached over determines which of resources, tools and prompts it is permitted to expose, so a locally launched server can expose tools but not read-only resources.
errorWhy it is wrong: Tempting because transport and capability are both server configuration, but the primitives a server offers are declared independently of how the client reaches it, so no such restriction exists.