Botverse

Submit Workflow

submit_workflow

Idempotent

Submit a multi-step workflow to the Botverse workflow engine. Steps execute in dependency order; parallel branches (multiple steps with the same depends_on) run simultaneously. Returns a workflow_id immediately — poll get_workflow_status every 5–10 seconds until terminal. INTER-STEP REFERENCES: pass a prior step's output into a later step with the string "$.steps..output_key" (e.g. a docx→pdf chain: step to_pdf has depends_on: ["to_docx"] and inputs {"source_url": "$.steps.to_docx.output_key", "output_format": "pdf"} using tool convert_from_url — no input_format needed here, it's inferred from the source file extension; input_format is only required by convert_content, which has no filename to infer from). Workflow params are referenced as "$.params.". No other template syntax (${...} etc.) is supported. BILLING: convert-only workflows run on wallet balance ($0.05/step). Workflows containing transcode or transcribe steps require auto-refill to be enabled at botverse.cloud/dashboard/billing (their cost scales with source duration). Workflow definition uses BWDL (Botverse Workflow Definition Language) — schema at botverse.cloud/schemas/workflow/v1.json.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`definition`	Yes	BWDL workflow definition. Must include workflow_id (string) and steps (array). Each step needs id, tool, and inputs.

Output Schema

TableJSON Schema

Name	Required	Description
`status`	Yes	Initial status: QUEUED or PROCESSING.
`step_count`	No	Number of steps in the workflow.
`workflow_id`	Yes	Unique workflow identifier. Pass to get_workflow_status.
`already_exists`	No	True if this workflow_id was already submitted — idempotent resubmit.

Schema Changelog

Changes observed during successful MCP inspections.

AddedMay 26, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already signal mutation/idempotency, and the description adds valuable behavior beyond that: immediate workflow_id return, polling cadence, dependency execution, billing/auto-refill requirements, and strict reference template constraints. No contradiction with annotations.

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?

Long but organized into clear labeled sections (INTER-STEP REFERENCES, BILLING) with front-loaded purpose and return behavior. Every sentence carries operational information; the example earns its place by clarifying reference syntax.

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 workflow submission tool, the description covers execution model, reference syntax, billing constraints, and schema location. Output schema exists, so not describing every return field is acceptable; nothing essential for correct invocation is missing.

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

Parameters5/5

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

Schema describes definition as BWDL with workflow_id/steps, and the description greatly expands this with step structure, depends_on semantics, inter-step reference syntax, a worked docx→pdf example, and input_format inference rules. This is far beyond the baseline for 100% schema coverage.

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?

Description opens with a specific verb-resource pair: 'Submit a multi-step workflow to the Botverse workflow engine.' It clearly differentiates from sibling tools by describing workflow-level orchestration (dependency order, parallel branches) rather than single-step conversions or status/cancel operations.

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?

Provides concrete usage context: async polling with get_workflow_status, dependency/parallel semantics, billing prerequisites, and unsupported syntax. Does not explicitly state when to prefer single-step sibling tools over submit_workflow, but the multi-step framing implies it.

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

All Botverse 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?