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. Correct
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.