Skip to content

How MCP Works

This page explains the mechanics behind a connected client: who does what, how a single request runs, what the model receives, and how the client is authorized. For what MCP is and why it matters, see the Introduction.

The Client, the Server, and the Model

MCP follows a client-server architecture:

  • MCP Server: An application (like Qualytics) exposes a set of tools and resources through the MCP protocol. The server handles authentication, executes the tool logic, and returns structured results.
  • MCP Client: An AI assistant or agent (like Claude Desktop, ChatGPT, or Cursor) connects to one or more MCP servers and can call their tools during a conversation.
  • LLM: The language model decides which tools to call, in what order, and how to interpret the results. The MCP protocol itself is model-agnostic.

How a Request Works

When you send a message to an MCP-connected assistant:

  1. The LLM receives your message along with a description of available tools.
  2. It decides whether to call a tool and which one.
  3. The client sends the tool call to the MCP server.
  4. The server executes the action and returns a structured result.
  5. The LLM receives the result and incorporates it into its response.
  6. This loop repeats until the LLM produces a final answer.

What the Model Sees

The LLM does not connect directly to your data infrastructure. It receives the context and structured tool results needed for the request. The data a tool can return is governed by that tool's capabilities and the requesting user's Qualytics permissions.

Most results describe your data rather than quote it. A few tools can surface individual values, such as a value quoted in a quality check failure explanation or a profile statistic, but no tool returns rows or records in bulk, and masked fields stay masked. For the category of data each tool shares with the model, see the Tool Catalog.

Tools, Resources, and Prompts

Tools

Tools are the primary mechanism through which MCP servers expose functionality. Each tool has:

  • A name: how the LLM references it (e.g., query_qualytics)
  • A description: natural language description the LLM uses to decide when to call it
  • An input schema: the parameters the tool accepts (JSON Schema)
  • An output: structured data returned after execution

The LLM reads tool descriptions and schemas to understand what each tool does and how to call it correctly. Well-written tool descriptions are essential because they allow the model to select the right tool for a given user request.

Resources

MCP also defines a resources concept for exposing read-only data (files, database records, documents) that the LLM can reference as context. Qualytics primarily uses tools rather than resources for its MCP integration.

Prompts

MCP supports server-defined prompt templates: pre-built message structures that guide the LLM through specific workflows. Support for prompts depends on the client and server.

Tool Registration

MCP supports dynamic tool discovery, allowing clients to start with a small core set and load additional tools on demand. Qualytics' MCP server takes a different approach. It registers its full tool catalog upfront, and tool descriptions are kept concise so the complete catalog fits within the LLM's context budget.

Transport and Authorization

MCP supports multiple transport mechanisms. Qualytics exposes its MCP server over streamable HTTP, the standard transport for remote MCP servers, which uses Server-Sent Events (SSE) to stream responses. This means:

  • No special local software is required to connect external clients.
  • External clients authorize through OAuth. The client sends a separate, short-lived MCP access token with each request.
  • Streaming responses are supported for long-running tool executions.

To authorize a client, you paste a Personal API Token on a Qualytics authorization page that the client opens in your browser. The client never receives that token. It receives its own MCP access token, and every tool call is checked against your identity and permissions. For the endpoints, scopes, and token lifetimes, see the MCP API.

See Also