Paperform

Run workflow

run_workflow

Destructive

Fire one of a workflow's triggers now, starting a real run: its steps execute against real connections (emails sent, records written) and there is no dry run. Fetch the workflow first for its trigger ids and tell the user what the run will do. Confirm with the user before calling this. payload is the trigger's input. A manual trigger is what the editor calls a "Local Component"; its params are its "Component Inputs", and the value written for each is only its default.

Returns { run_id, workflow_id, record }; fetch run_id to follow it.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "trigger_id": "<trigger_id>"
    },
    "name": "run_workflow"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The workflow id.
`payload`	No	The trigger's input. A manual trigger needs none. Any other trigger needs one standing in for the event it would receive: a sample from load_trigger_samples, or a past run's trigger event. A payment or order trigger refuses one.
`trigger_id`	Yes	The trigger to fire, from the workflow's definition.

Output Schema

Name	Required	Description	Default
`record`	No
`run_id`	No
`workflow_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the safety profile is covered; the description still adds real value by spelling out the consequences (emails sent, records written, no dry run, irreversible side effects on live connections). It does not discuss rate limits or what happens on partial step failure, which keeps it below the top mark.

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-loads the destructive consequence before any mechanics, which is the right ordering, and every sentence carries information. The editor-terminology sentence is dense and slightly tangential but is genuinely useful for resolving trigger ids and inputs, so it earns its place.

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?

An output schema exists, and the description still orients the agent by naming the return shape ({ run_id, workflow_id, record }) and telling it to fetch run_id to follow the run. Combined with the confirm-first requirement and payload sourcing rules, nothing essential for a correct invocation is 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?

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by mapping editor terminology onto the parameters (manual trigger = "Local Component", its params = "Component Inputs", and the written value is only that param's default) — context the schema does not convey. Much of the payload guidance, however, restates the schema's own payload description almost verbatim.

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 and resource ("Fire one of a workflow's triggers now, starting a real run") and immediately scopes it as a live execution against real connections. The clause "there is no dry run" implicitly separates it from the test_action sibling, so an agent can distinguish the two without opening either schema.

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

Usage Guidelines5/5

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

Gives explicit preconditions and ordering: fetch the workflow first for trigger ids, tell the user what the run will do, and confirm with the user before calling. It also names load_trigger_samples as the source for a valid payload, which is a concrete alternative route rather than a vague hint.

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

All Paperform tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?