Home / CCA-F / Tool Design & MCP / Building MCP Servers — Detail & Examples
DWG 2.2 — DETAIL & EXAMPLES

Building MCP Servers — Detail & Examples

Part of Tool Design & MCP · overview: domain-2.html
In this page

The three MCP capability types with a concrete example each, and a full client/server/transport exchange traced end to end.

2.2aThe three capability types, with an example each

Tools, resources, and prompts
  • Tool — an action: an MCP server for a project-tracking system might expose create_ticket(title, description, assignee).
  • Resource — readable data: the same server might expose the current sprint board as a resource Claude can read without "calling" anything, the way a file is read rather than executed.
  • Prompt — a reusable template the server offers, e.g. a standard "write a ticket description from a bug report" prompt other clients can reuse instead of each reinventing it.

2.2bServer, client, and transport in one exchange

CLIENT (Claude Code)Connects to the project-tracker MCP server over its configured transport.
SERVERAdvertises its available tools, resources, and prompts during connection setup.
CLIENTCalls the create_ticket tool with the fields it has gathered from the conversation.
SERVERExecutes the action against the real project-tracking system and returns a structured result (ticket ID, URL).

If that server runs on the same machine as the client, a local/stdio transport is the simplest choice — low latency, no network auth to manage. If it's a shared service used by many clients, it needs a network transport with its own connection lifecycle and authentication, which is where Domain 2.3's production concerns start to apply.


Claude Certified Architect — Study NotesDWG 2.2