MCP Servers and Clients

MCP defines three roles, and keeping them straight is the key to reasoning about any MCP system. The host application, the MCP client, and one or more MCP servers each have a distinct job, and the boundaries between them are where security and governance live.

The three roles

• Host application — the AI app the user actually interacts with: a chatbot, an IDE assistant, an internal copilot. It owns the conversation, the model, and the decision of which capabilities to make available. The LyraLearn Tutor is a host.
• MCP client — a component inside the host that speaks the protocol. The host runs one client per server connection; the client handles the handshake, capability discovery, and the JSON-RPC request/response traffic. One host can hold many clients at once.
• MCP server — a standalone process that wraps a real system (a SQL database, a ticketing API, a file store) and exposes its tools, resources, and prompts over MCP. Servers are independent and reusable across hosts.

A single host commonly connects to several servers simultaneously — a database server, a documents server, a ticketing server — composing their capabilities into one assistant.

How a request flows

When a user asks the assistant to do something, the sequence is:

1. The client discovers capabilities at connection time (tools/list, resources/list) and advertises them to the model.
2. The model decides to call a tool and emits a structured call; the host mediates — applying policy, and often a human-approval step for sensitive actions.
3. The client sends tools/call to the server; the server executes against the real system and returns a typed result.
4. The host feeds the result back to the model as context for its next turn.

The model never holds a database connection or an API key. It only ever names a tool and reads a result — the server is the only thing touching the real system.

Transports and where servers run

MCP runs over two main transports: stdio, where the host launches a local server as a child process (ideal for local files or developer tooling), and HTTP/SSE, where the server is a network service (ideal for shared enterprise systems). In a .NET shop you'll typically build the latter as an ASP.NET Core service, hosted on Azure behind the same auth, networking, and observability you give any internal API.

This separation is the architectural payoff: the team that owns the SQL database can own and secure its MCP server, while AI-app teams consume it as clients — without ever sharing raw credentials or coupling their release cycles.