Skip to main content

MCP gateway

The MCP gateway lets external AI agents (Claude, Cursor, your own agents) call some of your workspace's workflows and connector operations as Model Context Protocol tools. Nothing is exposed until you opt it in and publish it, every call needs a token you created, and every call passes your action policies and is recorded.

The gateway lives in the workflow module's Settings screen (/workflows/settings), on the MCP tab. See Settings.

Expose tools​

  • A workflow. Open the workflow's settings and switch on Expose this workflow as an MCP tool. The tool runs the workflow's active version in production. Its arguments are the fields the workflow's When Executed by Another Workflow trigger declares (one name:type per line); a workflow that accepts any data takes any object.
  • A connector operation. In Tools, enter a tool name, the node type (for example store/stripe), the operation and the connection it should use. Operations that only read (get, list, search, ...) can be exposed as they are. An operation that changes data is exposed only when you tick Allow this tool to change data for that tool.

Tool names use lowercase letters, digits, _ and -.

Publish a version​

Clients never see your edits directly. Publish tool set freezes the enabled tools and their arguments into the next numbered version (v1, v2, ...). A published version never changes, so a client built against v3 keeps working until you deprecate v3. Publishing an unchanged list does not create a new version, and tools that cannot be published (for example a workflow with no active version) are listed with the reason.

If a workflow's declared fields change after a version was published, calls to that tool are refused until you publish again, so a client never sends arguments the workflow no longer expects.

Create a token​

Under MCP tokens, give the token a name, choose the tools it may call (or All tools), optionally pin it to one published version, and choose when it expires. The key and secret are shown once: copy them into your MCP client's configuration. Revoke a token from the same list.

A token is an app credential of your workspace. Your MCP client exchanges the key and secret for an app token (authenticateAPIKey) and a workspace token (issueWorkspaceToken), then calls:

POST https://<your workspace gateway>/mcp/fluidgrids/<workspace id>
Authorization: Bearer <app token>
X-Workspace-Authorization: Bearer <workspace token>
Accept: application/json, text/event-stream

The endpoint speaks MCP Streamable HTTP (JSON responses). Add ?version=N to use an older published version.

Revoking a key stops it being exchanged for new tokens; an app token already issued from it lasts until it expires. To cut a client off immediately, deactivate its app or withdraw its workspace access.

Policies and approvals​

Every tool call is checked against your workspace's action policies before it runs, in production:

  • a workflow tool is the action type mcp:workflow with the tool name as the operation, plus the workflow's tags;
  • a connector tool is checked as its own node type, operation and connection provider, so the policies that govern that connector inside workflows govern it here too.

A Deny policy refuses the call. A Require approval policy holds it: the call appears in the Call log as waiting for approval, a workspace admin approves or declines it there, and the client then repeats the same call. An approval covers exactly those arguments, once.

Call log​

The Call log lists every call, including refused ones: the tool and version, the calling app, the decision (and the policy that made it), the status, the run it started, how long it took and a fingerprint of its arguments (the arguments themselves are not stored). Calls also appear in the workspace activity log as agent.tool.called under the calling app.

Each tool call counts as one workflow run against your plan's monthly runs.

Last updated on