Skip to main content
Glama

Runs: test draft

runs_test_draft
Destructive

Tries out a neonloops workflow before it goes live: runs the whole draft of a workflow that is not published right now in simulate mode, where every step executes and the ones that act outside neonloops (sending, posting, writing) are neutralized, then waits briefly and reports how it went. Use it after building or editing with workflows_edit and before workflows_publish; a published workflow is refused, and a person runs it from the app's Run button. Simulate cannot be turned off, and the run is real otherwise: it calls models, spends the workspace's budget and is recorded as a run. It is often still running when the call returns, which is normal: read the outcome with runs_get using the id. At most 10 test runs per 5 minutes per token.

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": {
      "workflow_id": "<workflow_id>"
    },
    "name": "runs_test_draft"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputsNoValues for the Start step's declared input fields, by name. Omit for a Start with none. A File field takes { "$file": "<id>" } of a file you uploaded; ids of files uploaded by others are refused.
workflow_idYesThe workflow whose draft to run; it must not be published right now. The ids are in workflows_list.
start_node_idNoWhich Start step fires, on a draft with more than one; required in that case.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / inputs / description
      Previous value: -"Values for the Start node's declared input fields, by name. Omit for a Start with none. A File field takes { \"$file\": \"<id>\" } of a file YOU uploaded; ids of files uploaded by others are refused."New value: +"Values for the Start step's declared input fields, by name. Omit for a Start with none. A File field takes { \"$file\": \"<id>\" } of a file you uploaded; ids of files uploaded by others are refused."
    • changedInput schema / properties / start_node_id / description
      Previous value: -"Which Start node fires, on a draft with more than one. Required in that case."New value: +"Which Start step fires, on a draft with more than one; required in that case."
    • addedInput schema / properties / workflow_id / description
      Added value: +"The workflow whose draft to run; it must not be published right now. The ids are in workflows_list."
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only flag destructive/openWorld; the description adds the context that matters: external actions are neutralized, simulate cannot be disabled, the run still calls models and spends the workspace budget, it is recorded as a run, it often returns before completion, and there is a 10-per-5-minutes-per-token limit. That is exactly the beyond-annotation disclosure this dimension rewards.

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?

Dense and front-loaded – purpose first, then sequencing, then behavioral caveats, then rate limit. A couple of clauses are long and chained, but no sentence is filler and the most decision-relevant facts come first.

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?

No output schema exists, and the description compensates by explaining the asynchronous return ('often still running when the call returns') and pointing to runs_get for the outcome. Combined with the refusal condition and rate limit, an agent has everything needed to call it and interpret the result.

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

Parameters3/5

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

Schema coverage is 100% and each parameter already carries a description (workflow_id source, start_node_id multi-start case, inputs/file handling), so the description's job here is minimal. It mentions draft-only workflow ids but adds no syntax or format detail beyond the schema; baseline 3 applies.

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 ('runs the whole draft of a workflow that is not published right now in simulate mode') and immediately bounds the scope: drafts only, simulate only. It is clearly distinct from runs_get/runs_list (which read runs) and from workflows_publish (which goes live).

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 ordering ('after building or editing with workflows_edit and before workflows_publish'), an explicit exclusion ('a published workflow is refused'), an alternative path ('a person runs it from the app's Run button'), and the follow-up tool ('read the outcome with runs_get using the id').

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources