GoRunner

Workflows as tools

POST /mcp/tools — your published automations become vocabulary the agent has: it calls look_up_order_total, not workflow #7.

POST https://<your-workspace-url>/mcp/tools
Authorization: Bearer grt_…   (needs workflow:run)

This is the surface that makes your automation the agent's capability. A workflow published with the MCP Tool trigger appears to any connected agent as a first-class tool under its own name — look_up_order_total, create_refund, page_oncall — with typed parameters and your own description telling the model when to use it.

Making a workflow a tool

  1. Set the trigger to MCP Tool. Define the tool's name, description and parameters (the same typed field model the Form trigger uses; parameters land on {{trigger.body.<parameter>}}).
  2. Build the flow as usual. End with Return Response if the agent should get a computed answer.
  3. Publish. Publish is the gate: it refuses a tool whose description can't help an agent choose it, and only ACTIVE, published tool-workflows are ever offered.

The contract, precisely

  • Enumeration is the boundary. The listing shows only published MCP-Tool workflows, from the published snapshot — an agent is never offered parameters that differ from what runs. A token needs workflow:run; broad read scopes see zero tools here, deliberately (this surface must never become a definition-reading side door).
  • Arguments are validated — a missing required parameter or an out-of-enum value is refused before any run starts.
  • Calls are synchronous up to ~25s, then answer "still running" with the run id. Because a timeout is a normal outcome, every tool accepts an idempotencyKey argument: the agent's retry with the same key returns the first attempt's run instead of executing twice. (If your parameters include a field literally named idempotencyKey, yours wins.)
  • Attribution is recorded. Runs started here record trigger mcp, filterable and labelled "Agent" — a fact of the run record, not a header a client claims.
  • The catalog is bounded (40 tools per workspace): an agent's tool budget is a shared resource, and no workspace should silently consume all of it.

Why this beats "an agent + a generic HTTP tool"

The workflow carries what an agent shouldn't: your credentials (never exposed to the model), your retry/timeout policy, your approval gates, your audit trail. The agent gets a named capability with a typed signature — and everything it invokes is something a human built, reviewed, versioned and published.

On this page