What Is an MCP Connector? A Practical Definition

MCP server and MCP client are protocol roles. A server exposes tools; a client discovers and calls them. In Connic, the MCP Server connector is specifically the server-side product that publishes Connic agents as MCP tools. A Connic agent that consumes an external MCP server is acting as a client through its mcp_servers configuration.

What is the Model Context Protocol?

MCP is an open protocol that standardizes how AI applications reach external tools, data, and prompts. Anthropic introduced it in November 2024, and adoption spread quickly: OpenAI supports MCP in its Agents SDK, and Google DeepMind CEO Demis Hassabis confirmed Gemini and SDK support in April 2025. The protocol uses a JSON-RPC client-server design: a server exposes capabilities, and a client connects to it and makes those capabilities available to the model. The MCP documentation provides the full protocol.

Without a shared protocol, every AI application needs a hand-written integration for each system it touches. MCP lets a system implement one server that compatible IDEs, chat apps, and agent runtimes can call.

The setup paths are separate. The documentation covers external MCP tools for the client role and the MCP Server connector for publishing agents as tools.

What is an MCP connector? The server side and the client side

In everyday usage, an MCP connector is a packaged MCP server: an endpoint URL, authentication, and a set of tools, ready to plug into a client. That is the sense in which chat applications use the word; connectors added to clients such as Claude or ChatGPT are MCP servers underneath (supported MCP clients). The server and client sides have different responsibilities:

On an agent platform, both directions show up. An agent consumes external MCP servers to gain tools, which makes the agent runtime the client. And the platform can publish the agent itself as an MCP tool, which puts the agent behind a server that other applications call. A production agent can use both roles at once.

MCP connector vs custom API integration: when each wins

MCP does not replace existing APIs. It describes API operations as tools in a form every MCP client understands. The decision is whether to wrap an API in the protocol or wire it up by hand.

A typed Python function used as a custom tool is simpler when the integration does not need an MCP server.

MCP tool calls are client-initiated during a run. A server can return the result directly, while optional extensions can represent longer workflows. MCP is not event delivery. When an external event should trigger an agent, such as a Stripe payment, a Kafka message, or a PostgreSQL NOTIFY message, use an event connector with the appropriate delivery guarantees. Our event connector comparison helps with that decision. The pre-built connector guide explains the broader integration approach. MCP sits alongside those patterns, not above them. The Connic connector catalog lists available connections and links to their setup guides.

How MCP connectors work on an agent platform

We implement both directions. The following examples show how each side works in practice.

Consuming MCP servers: the agent as client

To give an agent tools from an MCP server, list the server in the agent's YAML. At runtime the platform connects to each server, discovers its tools, and exposes them to the model alongside the agent's local tools. Every MCP tool call is traced and visible in the run details. The execution trace documentation explains the recorded tool calls.

version: "1.0"

name: docs-assistant
type: llm
model: connic/kimi-k2.7-code-fast
description: "An assistant with access to library documentation via MCP"
system_prompt: |
  You are a helpful coding assistant with access to up-to-date
  library documentation through MCP tools.

# Connect to an MCP server
mcp_servers:
  - name: context7
    url: https://mcp.context7.com/mcp

At connection time, Connic negotiates current or legacy MCP automatically. Tool annotations, structured results, and UI resource metadata attached to tools are preserved, while existing authentication headers, tool filters, and Bridge routing continue to apply. This is separate from the MCP Server connector in the previous section, which exposes a Connic agent to other clients.

The configuration covers the client-side concerns from above: authentication headers with secrets injected from variables, a tools filter to restrict the agent to specific tools, and a discoverable flag for servers with large toolsets, which indexes their tools for on-demand search instead of loading all of them into the model's context. Servers inside a private network are reached through Connic Bridge without public exposure. The MCP integration reference documents every field.

Exposing agents as tools: the MCP Server connector

The opposite direction uses an MCP Server connector. It publishes linked agents as MCP tools. Creating the connector generates an endpoint URL and a secret; each linked agent becomes a tool whose schema takes a required message and an optional structured payload. The same endpoint supports the current 2026-07-28 stateless protocol, prior Streamable HTTP revisions, and the original HTTP/SSE transport. Current clients may call the optional server/discover method before their first tool request; Connic implements that method. Legacy clients start with initialize.

POST /mcp HTTP/1.1
Authorization: Bearer <connector-secret>
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: invoice_processor

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "invoice_processor",
    "arguments": {
      "message": "Process this invoice and extract the total",
      "payload": {
        "invoice_id": "INV-12345",
        "customer": "Acme Corp"
      }
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "your-mcp-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

The example shows the Streamable HTTP headers for a 2026-07-28 tool call. The MCP-Protocol-Version header selects the revision, Mcp-Method mirrors tools/call, and Mcp-Name mirrors the tool name. The clientInfo metadata is recommended for logging and debugging, but 2026-07-28 does not require it.

Sync mode waits for the agent run to complete and returns the result to the caller, with a five-minute timeout. Inbound mode returns immediately with a run ID and lets the agent work in the background. Inbound is Connic fire-and-forget behavior, not the optional MCP Tasks extension. Requests authenticate with a static secret in an Authorization Bearer or X-Connic-Secret header; the connector does not provide an MCP OAuth flow. Authentication is on by default and should only be disabled on trusted networks. The MCP Server connector setup describes how to connect a client.

Our MCP Server connector exposes MCP tools only. It does not expose resources, prompts, or subscriptions, and it does not implement the optional Tasks or MCP Apps extensions.

The invoice template MCP tutorial covers deployment, tool discovery, and a Python client that calls the extractor and checks its result.