Clients, Servers, Tools, Resources, And Prompts

The five pieces

Every MCP integration is built from the same small set of roles. Getting this model right before you code is what stops you from building a server that dumps too much context or exposes actions it should not.

• Client: the application the user runs, such as Claude Desktop, Claude Code, or Cursor. The client hosts the agent and connects out to your server.
• Server: the process you write. It advertises what it offers and answers the client's requests over the protocol.
• Tools: actions the agent can call, such as create_ticket or lookup_customer. These are the parts that do something, and they carry the most risk.
• Resources: read-only context the agent can pull in, such as a document, a record, or a config file. Resources give grounding without granting write access.
• Prompts: reusable templates the client can invoke for common tasks, so a proven workflow is a menu item rather than something the agent improvises each time.

How a session flows

1. The client starts your server and asks what it offers.
2. The server responds with its list of tools, resources, and prompts, each with a schema and description.
3. During a task, the agent decides which tool to call or which resource to read, and the client sends that request to your server.
4. Your server does the work, usually by calling an API underneath, and returns a result the agent can use.

Why the split matters

The separation between tools, resources, and prompts is a safety design, not just naming. Tools act, so they are where you enforce permissions. Resources only read, so they are safer to expose broadly. Prompts capture the workflows you want repeated correctly. Keeping each in its lane means you can reason about risk one category at a time.

What good looks like

You can draw an integration on one page: the client on the left, your server on the right, and three labelled buckets for tools, resources, and prompts. For any capability you plan to add, you know which bucket it belongs in and why. That clarity is what keeps the server narrow.

Common mistakes

• Turning everything into a tool, including things that should be read-only resources, which hands the agent write access it never needed.
• Exposing a resource that returns an entire production dataset, so the agent pulls far more context than the task requires.
• Skipping prompts, then wondering why the agent runs a critical workflow slightly differently every time.