MCP Server
Connic publishes your agent as an MCP tool with auto-generated schema. Cursor, Claude Desktop, partner apps, and other agents can call it directly: same logic, no second implementation.
Overview
The Model Context Protocol is how AI applications discover and call external tools. The MCP Server connector puts your Connic agents on the serving side of that protocol: every agent you link becomes a tool with a generated input schema, listed by a standard tools/list call and invoked by tools/call. Anything that speaks MCP, from Claude Desktop and Cursor to a partner's product or another team's agent, can use your agent without a custom API integration.
That makes one deployment serve three audiences at once. Your team calls the agent from their coding tools, partners call it as a metered capability inside their own AI products, and other agents compose with it at runtime. The agent's logic, tracing, and access control stay in one place; only the callers multiply.
How it works
Create the connector and pick a mode
Add an MCP Server connector from your agent's Connector Flow. Sync mode waits for the agent to finish and returns the result (up to 5 minutes). Inbound mode returns a run ID immediately and processes in the background, for jobs that take longer.
Link agents; each becomes a tool
Every agent you link is exposed as an MCP tool with a standardized schema: a required message and an optional structured payload your agent reads through template variables. Agent names map to tool names automatically.
Paste the endpoint into any MCP client
The connector generates a unique endpoint URL and secret key. Add both to Claude Desktop, Cursor, or any MCP-compatible client, and your agents show up in its tool list.
What you can build
Patterns teams ship in production. No queues, workers, or schedulers to run.
Partner calls your agent
mcp://your-product/agentEach partner gets its own credentials, rate limiting, and metering. Their AI tools call your agent like any other function — you ship a paid API without writing one.
Partner calls your agent
mcp://your-product/agentEach partner gets its own credentials, rate limiting, and metering. Their AI tools call your agent like any other function — you ship a paid API without writing one.
Authentication and access
Every request carries the connector's secret key, either as an Authorization: Bearer header or an X-Connic-Secret header. Authentication is on by default and can be disabled for trusted networks. Each connector has its own endpoint and secret, so a partner integration and an internal integration never share credentials, and revoking one touches nothing else.
Every tool call is a normal agent run underneath: it appears in run history with full traces, token and cost tracking, and the same guardrails and approval rules as any other trigger.
What a tool call looks like
The connector implements the MCP methods clients expect: initialize for capabilities, tools/list for the linked agents, tools/call to invoke one, and ping for health checks. A call sends a required message plus an optional payload object the agent accesses as template variables, so structured data arrives structured instead of packed into prose. See the full request and response formats in the MCP docs.
Information
- Publisher
- By Connic
- Category
- Connectors
- Modes
- Inbound, Sync
- Documentation
- MCP Server docs
Frequently Asked Questions
Which MCP clients can call a Connic agent?
initialize, tools/list, tools/call, and ping methods, so no Connic-specific client code is needed.Should I use Sync or Inbound mode?
Is this the same as an agent consuming MCP tools?
Bring the event source, payload shape, result destination, and any private-network or approval requirements. We will map MCP Server to the right Connic connector mode, deployment path, and observability setup.
Talk to Sales