MCP Server Architecture: Host, Client, Server, and Tools

MCP — Model Context Protocol — is a standard that defines how an AI application connects to external tools. It divides the connection into three roles: the host (the AI app the user interacts with), the client (the MCP engine built into the host), and the server (the external process that exposes tools, data or actions). Understanding how these three interact explains why a particular connection works the way it does and what you need to configure on each side.

The protocol is open and implemented by a growing number of AI apps: Claude, Claude Code, Cursor, Codex CLI, Gemini CLI, GitHub Copilot and others. Any compliant server — including tools like fenbs that keep project context outside the model — can connect to any compliant host without custom code on either side.

The three roles

The host is the AI application the person uses. Claude Desktop, Claude Code, Cursor and Codex CLI are all hosts. The host manages the conversation, decides when to call a tool, and presents the result to the user. It does not speak the MCP protocol directly — that is the client's job.

The client is embedded inside the host and handles the MCP wire protocol. It launches or connects to servers, negotiates capabilities at startup (a step called initialization), sends tool-call requests, and returns the results to the host's conversation engine. One host can maintain multiple client connections — one per server — at the same time.

The server is an independent process that provides capabilities. It could run locally on the same machine (launched by the client as a subprocess) or remotely over the network. It exposes a set of tools — functions the AI can call — and optionally resources (data the AI can read) and prompts (preconfigured instructions the AI can invoke). The server has no awareness of which AI model is using it, only of the MCP protocol messages it receives.

How a request flows

When an AI assistant decides it needs to call a tool, the sequence looks like this:

1. The host's conversation engine determines that a tool call is needed and passes the tool name and arguments to the client.
2. The client serializes the call as a JSON-RPC 2.0 request and sends it to the server over the transport — stdio for local servers, HTTP for remote ones.
3. The server receives the request, runs the tool's underlying logic, and returns a JSON-RPC response containing the result.
4. The client passes the result back to the host.
5. The host adds the tool result to the conversation context and the AI generates its next response.

The whole round trip happens within the normal conversation flow. From the user's perspective, the AI paused briefly and then gave a more informed answer. From the server's perspective, it received a well-defined request and returned a structured response.

Transport: local stdio vs. remote HTTP

Local servers communicate over stdin/stdout. The client launches the server as a subprocess and writes requests to its standard input; the server writes responses to its standard output. This is simple, fast and needs no network configuration. The downside is that a local server only works for the person running it on that machine.

Remote servers communicate over HTTP. The client sends POST requests to a URL; the server returns responses. Remote servers can be accessed by multiple clients and from any machine. The current MCP specification supports both traditional HTTP with Server-Sent Events (SSE) for streaming and a newer streamable HTTP transport.

fenbs is a remote server. It runs at https://fenbs.ai/api/mcp and can be connected from Claude on any machine with a browser to complete the OAuth sign-in. That's the remote model in practice: one server, many clients, no local process to launch.

Authorization boundaries

Authorization works differently for local and remote servers. Local servers typically run as the current user's process with access to local files and environment variables. There is no separate auth step — the server trusts that only the local user launched it.

Remote servers require explicit authentication. The MCP specification follows the OAuth 2.1 standard with PKCE for browser-based sign-in. The flow is: the client tells the user it needs authorization, the user signs in via a browser, the server issues an access token, and the client uses that token on subsequent requests. The user stays in control of which clients have access and can revoke tokens from the server's own settings.

An important boundary: the server authenticates who is making the request, but the host decides what to do with the result. The server cannot control the AI's reasoning or responses — it only controls what its tools return. If a denial is the right answer, the server returns an error result and the AI reads it and explains the situation to the user.

Tools, resources, and prompts

MCP servers expose three kinds of capabilities. Tools are functions the AI can call with arguments: create_task, get_context, list_boards. They perform an action or return data. Resources are data objects the AI can read: files, database records, API responses. Prompts are preconfigured message templates the AI can invoke by name.

Not every server exposes all three. A file-access server might expose only resources. A task management server might expose only tools. At initialization, the client asks the server which capabilities it supports and lists what is available. The AI host uses that list to decide what it can ask the server to do.

A remote server like fenbs supports multiple clients at once. Each team member connects with their own account, limited by their role and the access they approved. One server, many connected AI apps — all reading the same up-to-date project record. See how teams use fenbs.

State and session management

MCP servers may be stateful or stateless. A stateless server treats each request independently — no memory of previous calls in the same session. A stateful server can hold session context between requests, which is useful for multi-step operations.

For a serverless deployment (Vercel, Cloudflare Workers), the server is effectively stateless because each request may run in a different worker instance. This works fine for most MCP tools, which fetch data fresh on each call. Fenbs uses this model: requests are stateless, and the persistent state lives in the underlying database, not in the server process.

How to do this with fenbs

1. Create a free account and add your first project.
2. Open Integrations and follow the setup guide for the AI app you use. The guide provides the server URL (https://fenbs.ai/api/mcp) and walks through the OAuth sign-in.
3. At the start of a session, ask your AI to call fenbs_get_context (or ask it to "read the project context"). It retrieves your rules, tasks and Where we left off.
4. At the end of a session, ask the AI to save progress. It calls fenbs_save_progress and the record is updated for the next session — and the next AI app that connects.

For related reading, see best MCP servers for a curated list of servers worth connecting, and MCP server directory for a broader catalog.