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.

The setup paths are separate. Configure an agent to consume external MCP tools when Connic is the client. Create the connector that publishes agents as MCP tools when Connic is the server.

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 across the ecosystem: OpenAI supports MCP in its Agents SDK, and Google DeepMind CEO Demis Hassabis confirmed Gemini and SDK support in April 2025. The protocol is a JSON-RPC client-server design: a server exposes capabilities, a client connects to the server and makes those capabilities available to the model. Read the MCP documentation for 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.

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; the connectors you add to clients such as Claude or ChatGPT are MCP servers underneath (see which clients support MCP). 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 your 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.

See how to expose a typed Python function as a custom tool 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. Compare the event connector patterns for that decision. For broader context, Read why pre-built connectors replace integration glue for the broader argument. MCP sits alongside those patterns, not above them.

How MCP connectors work on an agent platform

Connic implements both directions, so it makes a concrete example of what each side of the connector looks like in practice.

Consuming MCP servers: the agent as client

To give an agent tools from an MCP server, you 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. Inspect tool calls in the execution trace.

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 by tunneling the connection through a Connic Bridge instead of exposing them publicly. Route a private MCP server through Bridge. Read the MCP integration reference for every field.

Exposing agents as tools: the MCP Server connector

For the opposite direction, create an MCP Server connector. It publishes your agents as MCP tools. Creating the connector generates an endpoint URL and a secret; each agent you link to it 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. Follow the MCP Server connector setup to wire up a client.

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