MCP Server

Expose any Fruxon integration as a Model Context Protocol server so external LLM clients can call its tools

Every Fruxon integration can be exposed as an MCP server. External LLM clients — Claude Desktop, Cursor, your own SDK code, another agent platform — connect over the Model Context Protocol and call the integration's tools directly, with the same auth, sandboxing, and observability they'd get inside a Fruxon agent.

This is the inverse of the MCP tool type: instead of consuming external MCP servers from inside a Fruxon agent, you're publishing a Fruxon integration as an MCP server for outside consumers.

When to use it

You want Claude Desktop or Cursor to use your configured Salesforce / HubSpot / Postgres integration with its existing credentials and tool definitions — without rebuilding the integration on the client side.
You're embedding agentic behavior in an external product and want to reuse Fruxon's integration catalog, simulator, and credential vault as the tool layer.
You're running evals against an MCP-compatible harness and want a deterministic sandbox endpoint.

How it works

Each integration has a single MCP configuration with these fields:

Field	Purpose
`enabled`	Turns the MCP server on or off for this integration.
`configId`	Which published integration config to back the server with (credentials, base URLs, etc.).
`exposedToolIds`	Allow-list of tools to surface. Omit to expose every tool on the integration.
`description`	Free-form description returned to MCP clients during handshake.
`apiKeyId`	The Fruxon API key clients must present. Scopes who can reach this server.

Once enabled, two JSON-RPC endpoints become available on the integration:

POST …/mcp:call — production. Tool calls hit real APIs using the published config.
POST …/mcp:test — sandbox. Tool calls are routed through the integration simulator — useful for evals, CI, and client-side development without touching prod data.

Both speak standard MCP JSON-RPC, so any MCP-compatible client works without Fruxon-specific code.

Configuring an MCP server

Pick the integration config you want to expose. Tools, credentials, and base URLs all come from this config — including its sandbox mode when callers use the :test endpoint.

Create a Fruxon API key scoped to whoever should be able to reach the MCP server. This is the credential MCP clients will present.

Update the integration's MCP settings via PATCH /v1/tenants/{tenant}/integrations/{integration}/mcp — set enabled: true, the configId, the apiKeyId, and optionally an exposedToolIds allow-list.

Point your MCP client at the :call or :test URL with the API key in the Authorization header.

Production vs. sandbox

The split mirrors the rest of Fruxon. Use :call when you want real side effects, :test when you don't.

Endpoint	Backed by	Side effects	Typical use
`mcp:call`	The published config's live credentials	Yes — real API traffic, real writes	Production agent traffic from external MCP clients
`mcp:test`	The integration simulator (or the config's `sandboxMode`)	No	Evals, CI, local development against the MCP surface

Switching between them is a URL change on the client. No reconfiguration of the server.

API reference

The MCP endpoints live under API › Integrations › MCP:

Get MCP settings — read current configuration.
Update MCP settings — enable, set exposed tools, rotate the API key.
MCP JSON-RPC (production) — mcp:call.
MCP JSON-RPC (sandbox) — mcp:test.

Tools & Skills — using external MCP servers as tools inside a Fruxon agent (the opposite direction).
Sandbox Mode — how mcp:test routes calls without hitting real APIs.
Integrations — the underlying catalog of tools you're exposing.