ToolForte

Run a saved workflow

workflow_run

Run one saved workflow by id and return what every step produced. Get the id and the input keys from workflow_list. Each step costs the credits its own tool costs, normally 1 per step, and the credit for this call counts as the first step's rather than being charged on top. Steps run in order and stop at the first failure; the result says which step stopped it and what was spent up to that point. Check the "substitutions" field when it is present: it lists values a step supplied that the tool replaced with its own, which means the run succeeded on a value you did not send. Requires an API key, because a workflow belongs to an account. Get a key in one request with POST https://toolforte.com/api/v1/keys/bootstrap and {"email":"you@example.com"}, which emails it to that address, or create one at https://toolforte.com/developers, and send it on the MCP connection as the header Authorization: Bearer tf_...

Input Schema

Name	Required	Description	Default
`inputs`	No	Values for the workflow's declared inputs, keyed by the input key that workflow_list reports. Omit for a workflow that declares none.
`workflowId`	Yes	The id of a workflow from workflow_list.

Output Schema

Name	Required	Description
`ok`	No	Whether the run completed
`name`	No
`runId`	No
`steps`	No	What each step produced
`output`	No	The final output of the workflow
`result`	No	The result, when it is not an object
`stepsRun`	No
`durationMs`	No
`workflowId`	No
`stepsDefined`	No
`creditsCharged`	No	Credits spent by this call

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 13, 2026

removedInput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

removedOutput schema / $schema

Removed value: -"https://json-schema.org/draft/2020-12/schema"

Changed1 schema field changedSep 7, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "creditsCharged": {
+      "description": "Credits spent by this call",
+      "type": "number"
+    },
+    "durationMs": {
+      "type": "number"
+    },
+    "name": {
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the run completed",
+      "type": "boolean"
+    },
+    "output": {
+      "additionalProperties": {},
+      "description": "The final output of the workflow",
+      "properties": {},
+      "type": "object"
+    },
+    "result": {
+      "description": "The result, when it is not an object"
+    },
+    "runId": {
+      "type": "string"
+    },
+    "steps": {
+      "description": "What each step produced",
+      "items": {},
+      "type": "array"
+    },
+    "stepsDefined": {
+      "type": "number"
+    },
+    "stepsRun": {
+      "type": "number"
+    },
+    "workflowId": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 7, 2026

changedOutput schema / (root)

Previous value: -{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "additionalProperties": {},
-  "properties": {
-    "creditsCharged": {
-      "description": "Credits spent by this call",
-      "type": "number"
-    },
-    "durationMs": {
-      "type": "number"
-    },
-    "name": {
-      "type": "string"
-    },
-    "ok": {
-      "description": "Whether the run completed",
-      "type": "boolean"
-    },
-    "output": {
-      "additionalProperties": {},
-      "description": "The final output of the workflow",
-      "properties": {},
-      "type": "object"
-    },
-    "result": {
-      "description": "The result, when it is not an object"
-    },
-    "runId": {
-      "type": "string"
-    },
-    "steps": {
-      "description": "What each step produced",
-      "items": {},
-      "type": "array"
-    },
-    "stepsDefined": {
-      "type": "number"
-    },
-    "stepsRun": {
-      "type": "number"
-    },
-    "workflowId": {
-      "type": "string"
-    }
-  },
-  "type": "object"
-}New value: +null

Changed1 schema field changedSep 5, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": {},
+  "properties": {
+    "creditsCharged": {
+      "description": "Credits spent by this call",
+      "type": "number"
+    },
+    "durationMs": {
+      "type": "number"
+    },
+    "name": {
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether the run completed",
+      "type": "boolean"
+    },
+    "output": {
+      "additionalProperties": {},
+      "description": "The final output of the workflow",
+      "properties": {},
+      "type": "object"
+    },
+    "result": {
+      "description": "The result, when it is not an object"
+    },
+    "runId": {
+      "type": "string"
+    },
+    "steps": {
+      "description": "What each step produced",
+      "items": {},
+      "type": "array"
+    },
+    "stepsDefined": {
+      "type": "number"
+    },
+    "stepsRun": {
+      "type": "number"
+    },
+    "workflowId": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 1, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations: credit accounting (1 per step, this call counts as first step), fail-fast semantics (stops at first failure, reports stopping step and spend), the 'substitutions' field caveat signaling a run succeeded on a replaced value, and the API key requirement with concrete bootstrap instructions. None of this is derivable from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and cost, then failure behavior, then the auth requirement. The key-bootstrap paragraph is long but earns its place since no call succeeds without it; a small amount of trimming is possible in the substitutions sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists, yet the description still explains the meaningful result semantics (which step failed, spend so far, substitutions). Combined with cost, auth, and prerequisite guidance, an agent has everything needed to invoke this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds cross-tool semantics: the id and input keys come from workflow_list, tying inputs to the workflow's declared set. This is genuinely useful beyond the schema text without being exhaustive.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb, resource, and scope ('Run one saved workflow by id and return what every step produced'), immediately distinguishing it from workflow_list, which only supplies ids. An agent can tell what this does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to workflow_list to obtain the id and input keys, which is exactly the prerequisite needed before calling. It stops short of naming when-not-to-use or contrasting with run_tool for single-tool execution, so it's clear context but not a full decision rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All ToolForte tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?