What Is an MCP Connector? A Practical Definition

An MCP connector links an AI application to an external system over the Model Context Protocol, so the model can discover that system's capabilities and call them as tools. One side of the link is an MCP server that exposes the tools; the other is an MCP client, the AI application or agent that consumes them. The connector is the packaged, configured connection between the two.

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 announced Gemini 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.

The problem it solves is multiplication. Without a shared protocol, every AI application needs its own hand-written integration with every system it touches: one for the IDE, one for the chat app, one for each agent. With MCP, a system implements one server and every MCP client can use it. The integration is written once, against the protocol.

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). But the connector concept has two distinct ends, and it pays to keep them apart:

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. Same protocol, opposite roles, and a production agent often plays both 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, so the question is not whether to have an API but whether to wrap it in the protocol or wire it up by hand.

One boundary matters more than the rest: MCP is request-and-response tool calling, initiated by the model during a run. It is not event delivery. When an external event should trigger an agent, a Stripe payment, a Kafka message, a new database row, that is the job of event connectors with their own delivery guarantees. Compare the event connector patterns for that decision, and 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.

version: "1.0"

name: docs-assistant
type: llm
model: gemini/gemini-2.5-pro
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

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. Read the MCP integration reference for every field.

Exposing agents as tools: the MCP Server connector

The opposite direction is the MCP Server connector, which 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. Any MCP client, Cursor, Claude Desktop, a partner application, or another agent, can then list and call your agents over JSON-RPC:

{
  "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"
      }
    }
  }
}

The connector runs in one of two modes. Sync waits for the agent run to complete and returns the result to the caller, with a five-minute timeout. Inbound returns immediately with a run ID and lets the agent work in the background, which fits longer tasks. Requests authenticate with the secret in an Authorization Bearer or X-Connic-Secret header; authentication is on by default and should only be disabled on trusted networks. Follow the MCP Server connector setup to wire up a client.