Skip to main content
Conduit’s MCP server is available on the v3 plan. Contact support@conduit.ai to enable it for your workspace.

Overview

The Model Context Protocol is an open standard that lets AI assistants connect to external systems. Conduit’s MCP server exposes your contacts, conversations, tickets, calls, knowledge base, and agents as tools any MCP-compatible client can call. Once connected, your AI client can:
  • Look up contacts, conversations, tickets, calls, reservations, and appointments
  • Search the knowledge base and read knowledge nodes
  • Send messages on a conversation or ticket, or to a contact on a specific channel
  • Create and manage agents, skills, custom code tools, and contact custom attributes
  • Manage the Operator’s skills (operatorSettings.skills), separate from regular agent skills
  • List workspaces your token has access to
The server implements the MCP specification revision 2025-06-18 over streamable HTTP.

Endpoint

Every request includes an Authorization: Bearer <token> header. Workspace-scoped tools (most of them) also require a workspace_id argument.

Authentication

Two token types are accepted. Pick the one that matches the client.

OAuth 2.1

Interactive clients that want a user-consent flow, for example Claude Desktop, Cursor, VS Code, Claude Code, or Codex. Supports Dynamic Client Registration, so no pre-provisioning is needed.

API token

Server-to-server, CI, or CLI use. Generate a capi_... token under Workspace menu > API (click your workspace name in the top-left of the sidebar) and paste it into the client’s bearer-token field.

OAuth 2.1

Conduit’s MCP server advertises itself as an OAuth 2.1 protected resource per RFC 9728. When a client first POSTs to the MCP endpoint without a token, the server responds with 401 and a WWW-Authenticate header pointing at the resource metadata document. Any spec-compliant client will discover the rest automatically. Dynamic Client Registration (RFC 7591) is enabled, so clients register themselves on first connect. You sign in with your Conduit account in the browser window the client opens, pick which workspaces to grant access to, and the client caches the resulting access and refresh tokens.

API tokens

API tokens start with the capi_ prefix and carry either read-only or read/write access. Write tools (send_conversation_message, patch_contact, create_agent, etc.) require a read/write token. Rotate or revoke tokens under Workspace menu > API at any time.

Connect a Client

Add Conduit as a Custom Connector.
  1. Open Settings > Connectors in Claude Desktop
  2. Click Add custom connector
  3. Name: Conduit, URL: https://api.conduit.ai/v1/mcp
  4. Click Connect and complete the OAuth flow in your browser
Once connected, the Conduit tools show up under the plug icon in any chat.

Production Setup

Four practices that keep MCP usage safe and predictable in real workflows.

Pin a workspace at the start of each session

Almost every tool requires a workspace_id. Open each session by anchoring the model to one workspace:
The model holds onto that ID in context. Subsequent prompts don’t need to repeat it. Without this anchor, the model may guess at workspace IDs or call list_workspaces repeatedly.

Keep approvals on for write tools

Read tools are safe to pre-approve in clients that support it. Write tools — anything starting with send_, patch_, create_, update_, or delete_ — should always prompt. Each Conduit tool advertises a destructiveHint annotation; well-behaved clients surface it on the approval dialog. A misfired model decision against an allow-listed send_conversation_message ships a real message to a real customer. Don’t allow-list it.

Pass an idempotency key on every send

Every write tool accepts an idempotency_key input (or Idempotency-Key HTTP header). Pass a stable UUID per logical send. Clients retry on transient failures, and without a key a retry double-sends.
Either tell the model to generate one per send, or set it as a project rule that gets injected into every session.

Use least-privilege API tokens

For non-interactive use cases (CI, server-to-server, scripts), generate a read-only capi_ token and use it everywhere reads are sufficient. Only generate a read_write token for the specific session that needs writes, and rotate it after. Tokens are revoked under Workspace menu > API and take effect immediately.

Example Prompts

Generic starting points that work in any MCP-enabled client. Swap names and IDs for your own.
Uses list_helpdesk_tickets, get_helpdesk_ticket, list_ticket_messages. All read-only — no approval prompts if those tools are pre-approved.
Useful in terminal-based clients (Claude Code, Codex) where you can immediately jump from the conversation into the relevant code path.
The “don’t send” constraint is the safety belt while iterating. Drop it when you’re ready and the model will call send_conversation_message, which prompts for approval before anything ships.
Pair with a follow-up that calls update_knowledge_node (write tool, prompts for approval) once you’ve reviewed the list.

Rate Limits and Errors

By default, MCP tool calls are limited to 120 requests per minute per workspace and share the same workspace-level budget as REST API requests. A 429 response includes a Retry-After header. Error responses follow the MCP spec: content[0].text holds the error message and isError: true is set on tool results. See Rate Limits for details.

Tool Reference

The tool list is authoritative inside the server itself. A client that has completed initialize and tools/list will receive every tool, its input schema, and its annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint). Common tools, grouped by surface: The operator_* tools manage the Operator’s skills (the knowledge cards the Operator assistant uses), which are separate from the regular agent skills managed by *_skill. They read and write operatorSettings.skills with the same workspace scoping and Manage AI Settings permission as the Operator settings screen in the app, and they are MCP-only (there is no matching REST route). Every operator_* tool takes a required workspace_id; writes need a read/write token and the Manage AI Settings permission. See the REST API reference for the underlying resource shapes. MCP tools share the same schemas. To author a custom tool over MCP, call list_custom_tool_runtimes first. It returns the entrypoint signature, required return shape, and available dependencies for Python and JavaScript, so the model writes code that passes validation on the first try. See the Custom Tools overview for the full contract.

Troubleshooting

The OAuth access token expired and the client does not have a refresh token. Disconnect and reconnect the server. If you’re using an API token, it may have been rotated or revoked. Check Workspace menu > API.
The token is valid but not scoped to any workspace. For OAuth, remove the Conduit connector in your client and reconnect, making sure to grant at least one workspace during consent. For API tokens, confirm the token is attached to the right workspace.
API tokens default to read-only. Create a new token with read/write access, or use an OAuth client where you consented to the mcp:write scope.
Some clients do not support Dynamic Client Registration or do not follow the WWW-Authenticate resource metadata pointer. In that case, use an API token instead, or point the client directly at the authorization server URLs in the Authentication section.
The connection succeeded but the client hasn’t refreshed its tool list. Disconnect and reconnect, or restart the client. In Claude Code, run /mcp to force a reconnect.