Wazza

Start a run

start_run

Starts a run of a tool, a model or a workflow and returns AT ONCE with the run (id, status queued or running). Runs take seconds to minutes: call get_run with the run id until status is succeeded, failed or cancelled, then read its outputs (signed links) and report. A workflow run also lists its steps, each with its own status and credits. The credits are held when the run starts and settled when it ends. Give one of tool, model and workflow, and the inputs; files are https URLs or file ids from upload_file.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "start_run"
  }
}

Input Schema

Name	Required	Description
`tool`	No	A tool id from list_tools.
`model`	No	A model id from list_models.
`inputs`	No	The inputs, as list_tools, list_models or list_workflows describe them.
`workflow`	No	A workflow id from list_workflows.
`idempotency_key`	No	Optional. Retrying with the same key and the same request within 24 hours returns the first answer instead of doing it twice.
`keep_outputs_seconds`	No	How long the outputs are kept after the run ends, 600 to 604800 seconds. Default: the key's setting, else 7 days.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Adds substantial behavior beyond the annotations: the call is explicitly asynchronous and returns a queued/running run rather than a result, typical latency is seconds to minutes, output links are signed, workflow runs enumerate per-step status and credits, and credits are held at start and settled at end. That credit-hold/settlement detail is real financial-behavior disclosure an agent could not infer from readOnlyHint=false or destructiveHint=false.

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?

Four tight sentences, front-loaded with the return-immediately semantic that governs correct use, followed by the polling loop and then the credit/file constraints. No filler and no repetition of enum values already listed in the schema.

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, yet the description supplies the return shape (id, status queued/running), the terminal states to poll for, and where the outputs appear (signed links). For a six-parameter async creation tool with a nested inputs object, nothing an agent needs to call it and follow through 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 description coverage is 100%, so the baseline is 3, but the description still adds meaning the schema does not: only one of tool/model/workflow should be supplied, and files in inputs are https URLs or file ids from upload_file. The idempotency and retention parameters are left to their (already thorough) schema descriptions.

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 ("Starts a run of a tool, a model or a workflow") and immediately delimits scope by contrasting with the polling sibling get_run. An agent can distinguish this create-a-run tool from get_run/list_runs without opening any 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?

Gives a clear operating pattern: this call returns at once, then call get_run with the returned id until status is succeeded/failed/cancelled, then read outputs. It also constrains the request shape ("give one of tool, model and workflow, and the inputs"). It stops short of naming when NOT to use it (e.g. estimate_run to price first, cancel_run to abort), so it is not a full when/when-not routing statement.

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

All Wazza 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.