Skip to main content
A Jinba Flow workspace can expose selected published flows as tools through a Streamable HTTP MCP server. Configure the flows in the workspace’s MCP settings, then connect an MCP client using the endpoint and workspace API key shown there.
Workspace MCP settings for configuring flows as MCP tools

Workspace MCP settings show the flows configured as tools and the client connection details

Prepare a flow

Publish the flow you want to make available. Add an INPUT_* step for each value the client should provide. An input step’s ID becomes the parameter name, so use a clear ID and description. For example, this flow accepts a name and returns a greeting:
In workspace MCP settings, select the published flow and add a description that helps the client decide when to use it. The configured flow is exposed as an MCP tool.

Tool annotations

The configuration dialog of each MCP tool also has two annotations that are sent to the AI client together with the tool:
  • Read-only Tool — mark a flow that only checks or reads state and has no side effects such as creating, modifying or sending. Clients treat such a tool as safe to re-run; for example, Jinba App Neo’s wait_for_flow only accepts tools marked read-only.
  • Destructive Action Warning — mark a flow that deletes, modifies or makes irreversible changes. Clients prompt the user to confirm before running it. A read-only tool is never destructive, so this option is unavailable while read-only is on.

Connect an MCP client

Copy the client configuration from the workspace’s MCP settings. It contains the current endpoint and connection method. A Streamable HTTP client configuration has this shape:
Replace YOUR_TOKEN with a workspace API key or a personal API key (sk-user-…) created in your profile settings. Personal key owners must be members of the target workspace and have permission to run flows. Frozen and archived workspaces cannot be accessed with personal keys. With a personal key, runs are attributed to the key owner, and flows use that owner’s personal secrets. Credits are charged to the organization that owns the flow’s workspace. A personal key can access multiple workspaces, so do not share it with others. Revoking the key or leaving the workspace blocks subsequent requests. If the client cancels a request while a tool is still running, the flow run behind it is cancelled as well and shows as cancelled in the run history. The workspace API key grants access to that workspace’s MCP server. Keep it private; do not commit it or paste it into a public prompt.

Verify the connection

  1. Connect the client with the configuration from Jinba Flow.
  2. Refresh or list the available tools in the client.
  3. Confirm the configured flow appears, then call it with a safe test input.
If the client connects but shows no tools, check that the flow is published and selected in workspace MCP settings. If authentication fails, copy the current workspace API key and endpoint from those settings. Choose a test flow whose actions are safe to run; an MCP call executes the flow.

Request limits

The MCP endpoint rejects requests that exceed these limits:
  • A request body larger than 4 MiB is rejected with HTTP 413. This includes the tool arguments of a tools/call.
  • A JSON-RPC batch with more than 32 messages is rejected with HTTP 400.
  • An Mcp-Session-Id that Jinba Flow did not issue is answered with HTTP 404, so the client starts a new session. Standard MCP clients reuse the session ID the server returns from initialize and are not affected.