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 free key at https://toolforte.com/developers and send it on the MCP connection as the header Authorization: Bearer tf_...

Input Schema

TableJSON 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

TableJSON 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. Dates show when Glama detected each change.

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.7/5.0

Behavior5/5

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

The description adds substantial behavioral detail beyond the annotations: each step costs credits, the call's credit counts as the first step's cost, steps run in order and stop at the first failure, the result reports the stopping step and spend, and the substitutions field warns when values were replaced. It also discloses the API key requirement and authentication mechanism, which is significant for a non-read-only tool.

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

Conciseness5/5

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

The description is dense but every sentence carries operational value: purpose, prerequisites, cost model, execution order, failure behavior, substitution warning, and auth. It is front-loaded with the core purpose and then layers essential details without fluff.

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?

For a complex execution tool, the description covers the critical non-obvious aspects: where to get identifiers, credit accounting, stopping conditions, substitution semantics, and API key requirements. Since an output schema exists, it does not need to describe return values, and nothing essential for an agent to call this tool correctly appears missing.

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?

The input schema already provides 100% description coverage for both parameters. The description adds meaningful sourcing guidance by telling the agent to get workflowId and input keys from workflow_list, which helps the agent know where to discover valid values. This goes slightly above the baseline for fully schema-covered parameters.

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?

The description opens with a specific verb and resource: 'Run one saved workflow by id and return what every step produced.' It clearly distinguishes workflow_run from the related workflow_list by telling the agent to get ids and input keys from workflow_list, so the agent understands workflow_run executes a saved workflow rather than listing one.

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?

The description gives clear context for using the tool: obtain the id and input keys from workflow_list, and understand the credit cost and failure behavior before invoking it. It does not explicitly state when not to use this tool or name an alternative for executing workflows, but with only workflow_list as a related sibling, the intended usage is adequately conveyed.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0

Disambiguation5/5

Every tool targets a distinct resource or action, and the detailed descriptions clearly separate near neighbors like generate_test_bsn versus generate_brp_test_data, read_page versus url_screenshot versus url_to_pdf, and image_compress/convert/resize. Even with 40 tools, there is no real boundary-blurring overlap.

Naming Consistency3/5

All names are snake_case and readable, but the set mixes conventions: verb_noun (generate_*, validate_*), noun_verb (pdf_merge, image_resize), conversion-style names (csv_to_json, html_to_pdf), and bare nouns (base64, qr_code_png). The groups are recognizable, but there is no single predictable pattern.

Tool Count2/5

Forty tools is an oversized surface for an agent to consider on every call, well above the point where tool selection cost starts to hurt. The broad purpose explains the count, but many one-off utilities could be grouped or exposed selectively.

Completeness3/5

The server covers many domains—encoding, Dutch test data, image/PDF handling, memory, and workflows—but several categories are partial: there are no reverse conversions like json_to_csv or html_to_markdown, no PDF text extraction, and no workflow create/update/delete tools. Agents can work around some gaps, but notable operations are missing.

Resources

Need Help?