Skip to main content
Glama

Meta Council

by com.meta-council
OverviewDiscussionsAdmin

Run Workflow

run_workflow

Start a multi-step workflow pipeline and return its session id and definition_sha immediately by default — the fingerprint of the definition this run resolved, comparable against the one plan_workflow reported. Poll get_workflow_session for each step's model/provider and output. synthesis. Steps run on YOUR configured provider keys, so a pipeline can chain models across providers. If a step is a human checkpoint, returns the session id to advance. Requires authentication.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesThe input to run the pipeline on. Be specific, e.g. 'Analyze NVDA as an investment'.
workflowYesThe workflow slug (from list_workflows), e.g. 'live_market_pipeline', 'due_diligence', 'coding_tdd'.
parametersNoValues for the workflow's declared parameters, as a flat name-to-value object, e.g. {"region": "EU"}. Omitted names use their declared defaults. Workflows that declare no parameters take none.
step_modelsNoPer-run model choices, keyed by zero-based step index, exactly as supplied to plan_workflow. IDs are catalog-validated; existing key, tier and platform fallback rules still apply. These choices must also match when recovering a start with an idempotency key.
wait_secondsNoOptional synchronous wait; default 0 returns immediately.
idempotency_keyNoCaller-supplied key: sending the same key again returns the run that already exists instead of starting a second, paid run. Use a stable key derived from your own request so an uncertain retry converges. Max 120 chars, [A-Za-z0-9._:-].

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": false,
-  "properties": {
-    "text": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "text"
-  ],
-  "type": "object"
-}New value: +null
  2. Changed1 schema field changed
    • addedInput schema / properties / step_models
      Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "description": "Per-run model choices, keyed by zero-based step index, exactly as supplied to plan_workflow. IDs are catalog-validated; existing key, tier and platform fallback rules still apply. These choices must also match when recovering a start with an idempotency key.",
+  "type": "object"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / parameters
      Added value: +{
+  "description": "Values for the workflow's declared parameters, as a flat name-to-value object, e.g. {\"region\": \"EU\"}. Omitted names use their declared defaults. Workflows that declare no parameters take none.",
+  "type": "object"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "description": "Caller-supplied key: sending the same key again returns the run that already exists instead of starting a second, paid run. Use a stable key derived from your own request so an uncertain retry converges. Max 120 chars, [A-Za-z0-9._:-].",
+  "type": "string"
+}
  5. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already mark this as non-read-only and non-idempotent, and the description adds meaningful behavioral context: immediate return by default, asynchronous polling model, execution on the user's configured provider keys, human checkpoint behavior, and authentication requirements. 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loads the core return behavior before explaining polling and provider execution. It earns its sentences, but the awkward 'output. synthesis.' fragment and the dense em-dash clause keep it from being perfectly polished.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by specifying the returned identifiers and directing the agent to get_workflow_session for step-level details. For a six-parameter async workflow tool, this is sufficient for a first call, though it doesn't address error handling, retries, or explicit advancement steps.

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 description coverage is 100%, so the schema already documents all six parameters well. The description adds useful context about return behavior and workflow execution, but it does not add significant parameter-level meaning beyond what the input schema provides.

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 uses a specific verb ('start') and object ('multi-step workflow pipeline') and names the distinct artifacts returned (session id, definition_sha). It explicitly distinguishes itself from plan_workflow by calling out the fingerprint comparison, making the tool's role clear.

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 clear context: run_workflow starts the pipeline, get_workflow_session is the polling tool for step outputs, and plan_workflow is the source of the definition fingerprint to compare. However, it doesn't explicitly give when-not-to-use conditions or name adjacent tools like retry_workflow or advance_workflow.

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

All Meta Council toolsInspect
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