ToolForte

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.

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations present, the description fully carries the behavioral burden. It discloses credit accounting, sequential execution with first-failure stopping, what the result reports, the important substitutions warning, and API key authentication details. This goes far beyond a minimal description.

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 longer than average but every sentence earns its place: purpose, prerequisites, cost behavior, failure behavior, substitution warning, and authentication. It is front-loaded with the core purpose and keeps details logically ordered 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?

Given there is no output schema and no annotations, the description covers what is needed to invoke the tool correctly: how to identify the workflow, what inputs are expected, how costs work, what happens on failure, the meaning of substitutions, and the required auth mechanism. No obvious operational gap remains.

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 covers both parameters with 100% semantic coverage. The description adds value by explaining that ids and input keys come from workflow_list and by warning that substituted values mean the run may have succeeded on values not sent. That is meaningful beyond schema-only documentation.

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.' This is unambiguous and distinguishes workflow_run from the sibling workflow_list by explicitly pointing there for ids and input keys.

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 usage context: obtain the workflow id and input keys from workflow_list, and requires an API key. It could have explicitly stated 'use workflow_list to discover workflows' or listed when not to use this tool, but the prerequisite is clear enough.

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

Disambiguation4/5

Most tools have clearly distinct purposes, but some pairs could be confused: html_to_pdf vs url_to_pdf both produce PDFs, read_page vs url_screenshot both fetch a URL, and generate_test_bsn vs generate_brp_test_data both generate Dutch test data. Detailed descriptions mitigate most ambiguity, so agents can usually select correctly.

Naming Consistency5/5

All tool names follow a consistent snake_case convention with predictable verb_noun patterns (e.g., generate_*, validate_*, memory_*, url_*). The naming is uniform and makes each tool's function easily inferable from its name.

Tool Count2/5

35 tools is a heavy surface for any MCP server, even a general-purpose toolbox. The large number of niche Dutch-specific tools (BRP, UPA, BSN, holidays) may overwhelm agents and increase selection complexity. The server could benefit from splitting into smaller, focused servers.

Completeness3/5

The server covers a wide range of utilities, but there are notable gaps: no hash generation, no json_to_csv counterpart, and the workflow sub-domain only offers list/run without create/delete. Core utilities are present, but some obvious counterparts and lifecycle operations are missing.

Resources

Need Help?