Skip to main content
Glama

rigor_execute

Execute a structured workflow end-to-end. Call rigor_plan first (free) to preview the step sequence and cost estimate before committing credits. Classifies the task, selects the optimal tool sequence, and executes each step with the right LLM model. Returns a complete deliverable — solution designs, competitive analyses, governance documents, and more. Supports SSE streaming for real-time progress, webhook callback, or polling. For atomic work — classification, scoring, ranking, entity extraction, query parsing — set preferences.execution to 'direct' and declare preferences.output_contract to get validated JSON records from a single call, routed to the cheapest model that holds the schema.

Input Schema

NameRequiredDescriptionDefault
contextNoAdditional context for the workflow.
deliveryNoDelivery method. Default: polling (MCP clients typically can't handle SSE).
task_typeNoOptional hint to bypass automatic classification. Passing it also removes the slowest classification tiers from the critical path, so send it whenever you know the shape. Multi-step deliverable types: solution_design, requirements_analysis, code_implementation, code_review, bug_fix, root_cause_analysis, incident_response, deployment_execution, competitive_scan, financial_analysis, research_task, documentation, governance_change, compliance_audit, data_security_assessment, performance_optimization, user_story_definition, implementation_prompt_generation. Atomic single-call types, which auto-select direct execution: tag, score, rerank, compose, extract_entities, parse_query, quick_research, quick_classification, quick_extraction, quick_scoring. Call GET /api/rigor/task-types for the full vocabulary with each type's shape.
preferencesNoOptional workflow preferences.
context_fieldsNoOptional, with prior_workflow_id: the fields to carry over. Pass ["full_step_results"] for every step output in full.
task_descriptionYesNatural language description of the task, at most 4,000 characters. Be specific — include what you want produced, constraints, and context. Example: 'Design a caching layer for our API gateway with Redis integration.'
prior_workflow_idNoOptional: the workflow_id (wr_…) of a finished workflow in your workspace to build on. Its results are passed to this run as context. It is charged as a new run at the normal quote.

Output Schema

NameRequiredDescriptionDefault
okNo
statusNo
poll_urlNo
executionNoPresent with value 'direct' when direct execution ran. Absent for standard multi-call execution.
task_typeNo
value_classNo
workflow_idNo
delivery_modeNo
available_modesNo
estimated_creditsNo
execution_fallbackNoTrue when you explicitly requested direct execution and it could not be honoured — the workflow ran as standard multi-call instead. Never set for an auto-selected attempt, since you did not ask.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / context_fields
      Added value: +{
      +  "description": "Optional, with prior_workflow_id: the fields to carry over. Pass [\"full_step_results\"] for every step output in full.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / preferences / properties / execution / description
      Previous value: -"Set to 'direct' to compose the plan's content frameworks into a single LLM call and route cost-first, using a per-task-type model floor that moves when a cheaper model earns the work. Research steps, process steps (classification-verify, review protocol, synthesis) and the quality review each remain separate calls, so this is not a one-call-per-workflow guarantee: for atomic task types, which have a single content framework, the call count matches standard execution and the saving is the model. Supplying output_contract replaces the quality-review call with deterministic validation, which is one fewer call. No intermediate outputs. Available at every tier. Auto-selected for atomic task types when no execution preference is given. Falls back to standard execution when combined with require_approval or interactive mode, or when the plan exceeds the composition size limit. Attachments and prior_workflow_id chaining are NOT applied — use standard execution for those."New value: +"Set to 'direct' to compose the plan's content frameworks into a single LLM call and route cost-first, using a per-task-type model floor that moves when a cheaper model earns the work. Research steps, process steps (classification-verify, review protocol, synthesis) and the quality review each remain separate calls, so this is not a one-call-per-workflow guarantee: for atomic task types, which have a single content framework, the call count matches standard execution and the saving is the model. Supplying output_contract replaces the quality-review call with deterministic validation, which is one fewer call. No intermediate outputs. Available at every tier. Auto-selected for atomic task types when no execution preference is given. Falls back to standard execution when combined with require_approval or interactive mode, or when the plan exceeds the composition size limit. With attachments or prior_workflow_id, the workflow runs as standard execution instead, so the attachments and the earlier results are applied."
    • addedInput schema / properties / prior_workflow_id
      Added value: +{
      +  "description": "Optional: the workflow_id (wr_…) of a finished workflow in your workspace to build on. Its results are passed to this run as context. It is charged as a new run at the normal quote.",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / task_description / description
      Previous value: -"Natural language description of the task. Be specific — include what you want produced, constraints, and context. Example: 'Design a caching layer for our API gateway with Redis integration.'"New value: +"Natural language description of the task, at most 4,000 characters. Be specific — include what you want produced, constraints, and context. Example: 'Design a caching layer for our API gateway with Redis integration.'"
  3. Changed1 schema field changed
    • changedInput schema / properties / preferences / properties / max_budget_usd / description
      Previous value: -"Maximum budget in USD."New value: +"Spending ceiling in USD. If the plan's quote is still above it after Rigor fits the plan (cheaper models, optional steps dropped), rigor_plan returns a max_budget_exceeded warning and rigor_execute refuses with 402 max_budget_exceeded before anything runs or is charged."
  4. Changed1 schema field changed
    • changedInput schema / properties / task_type / description
      Previous value: -"Optional hint to bypass automatic classification. Passing it also removes the slowest classification tiers from the critical path, so send it whenever you know the shape. Multi-step deliverable types: solution_design, requirements_analysis, code_implementation, code_review, bug_fix, root_cause_analysis, incident_response, deployment_execution, competitive_scan, financial_analysis, research_task, documentation, governance_change, compliance_audit, data_security_assessment, performance_optimization, user_story_definition, implementation_prompt_generation. Atomic single-call types, which auto-select direct execution: tag, score, rerank, extract_entities, parse_query, quick_research, quick_classification, quick_extraction, quick_scoring. Call GET /api/rigor/task-types for the full vocabulary with each type's shape."New value: +"Optional hint to bypass automatic classification. Passing it also removes the slowest classification tiers from the critical path, so send it whenever you know the shape. Multi-step deliverable types: solution_design, requirements_analysis, code_implementation, code_review, bug_fix, root_cause_analysis, incident_response, deployment_execution, competitive_scan, financial_analysis, research_task, documentation, governance_change, compliance_audit, data_security_assessment, performance_optimization, user_story_definition, implementation_prompt_generation. Atomic single-call types, which auto-select direct execution: tag, score, rerank, compose, extract_entities, parse_query, quick_research, quick_classification, quick_extraction, quick_scoring. Call GET /api/rigor/task-types for the full vocabulary with each type's shape."
  5. Changed5 schema fields changed
    • addedInput schema / properties / preferences / properties / execution
      Added value: +{
      +  "description": "Set to 'direct' to compose the plan's content frameworks into a single LLM call and route cost-first, using a per-task-type model floor that moves when a cheaper model earns the work. Research steps, process steps (classification-verify, review protocol, synthesis) and the quality review each remain separate calls, so this is not a one-call-per-workflow guarantee: for atomic task types, which have a single content framework, the call count matches standard execution and the saving is the model. Supplying output_contract replaces the quality-review call with deterministic validation, which is one fewer call. No intermediate outputs. Available at every tier. Auto-selected for atomic task types when no execution preference is given. Falls back to standard execution when combined with require_approval or interactive mode, or when the plan exceeds the composition size limit. Attachments and prior_workflow_id chaining are NOT applied — use standard execution for those.",
      +  "enum": [
      +    "direct"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / preferences / properties / output_contract
      Added value: +{
      +  "description": "Only read when execution is \"direct\". Declares the JSON shape you want back, so the answer is generated against your schema and validated against it before return, instead of returned as prose you have to parse. A conforming run also skips the quality-review call, costing 1 LLM call rather than 2. The schema is closed: a record carrying an undeclared key is rejected exactly like one missing a required key.",
      +  "properties": {
      +    "count": {
      +      "description": "Bounds on the number of entries. Only read when shape is \"array\".",
      +      "properties": {
      +        "max": {
      +          "type": "number"
      +        },
      +        "min": {
      +          "type": "number"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "fields": {
      +      "description": "The schema for 1 record.",
      +      "items": {
      +        "properties": {
      +          "description": {
      +            "description": "Passed to the model as the field's description.",
      +            "type": "string"
      +          },
      +          "enum": {
      +            "description": "Restricts a string field to a fixed set of values.",
      +            "items": {
      +              "type": "string"
      +            },
      +            "type": "array"
      +          },
      +          "maximum": {
      +            "description": "Upper bound for a numeric field.",
      +            "type": "number"
      +          },
      +          "minimum": {
      +            "description": "Lower bound for a numeric field.",
      +            "type": "number"
      +          },
      +          "name": {
      +            "description": "The JSON key.",
      +            "type": "string"
      +          },
      +          "required": {
      +            "description": "Defaults to true. Set false for a field that may be absent.",
      +            "type": "boolean"
      +          },
      +          "type": {
      +            "description": "The value's type.",
      +            "enum": [
      +              "string",
      +              "number",
      +              "integer",
      +              "boolean",
      +              "array",
      +              "object"
      +            ],
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "name",
      +          "type"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "selection": {
      +      "description": "Use when you want the model to over-generate candidates and Rigor to sort, threshold, and cap them before the count bounds are checked.",
      +      "properties": {
      +        "maxCount": {
      +          "type": "number"
      +        },
      +        "minCount": {
      +          "type": "number"
      +        },
      +        "minScore": {
      +          "type": "number"
      +        },
      +        "scoreField": {
      +          "type": "string"
      +        }
      +      },
      +      "type": "object"
      +    },
      +    "shape": {
      +      "description": "\"object\" for 1 record, \"array\" for 1 entry per input item.",
      +      "enum": [
      +        "object",
      +        "array"
      +      ],
      +      "type": "string"
      +    },
      +    "task_type": {
      +      "description": "Your own label for the work. Echoed into telemetry. Not read as a framework name and does not change routing.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "task_type",
      +    "shape",
      +    "fields"
      +  ],
      +  "type": "object"
      +}
    • changedInput schema / properties / task_type / description
      Previous value: -"Optional hint to bypass automatic classification. Values: solution_design, requirements_analysis, code_implementation, code_review, bug_fix, root_cause_analysis, incident_response, deployment_execution, competitive_scan, financial_analysis, research_task, documentation, governance_change, compliance_audit, data_security_assessment, performance_optimization, user_story_definition, implementation_prompt_generation."New value: +"Optional hint to bypass automatic classification. Passing it also removes the slowest classification tiers from the critical path, so send it whenever you know the shape. Multi-step deliverable types: solution_design, requirements_analysis, code_implementation, code_review, bug_fix, root_cause_analysis, incident_response, deployment_execution, competitive_scan, financial_analysis, research_task, documentation, governance_change, compliance_audit, data_security_assessment, performance_optimization, user_story_definition, implementation_prompt_generation. Atomic single-call types, which auto-select direct execution: tag, score, rerank, extract_entities, parse_query, quick_research, quick_classification, quick_extraction, quick_scoring. Call GET /api/rigor/task-types for the full vocabulary with each type's shape."
    • addedOutput schema / properties / execution
      Added value: +{
      +  "description": "Present with value 'direct' when direct execution ran. Absent for standard multi-call execution.",
      +  "type": "string"
      +}
    • addedOutput schema / properties / execution_fallback
      Added value: +{
      +  "description": "True when you explicitly requested direct execution and it could not be honoured — the workflow ran as standard multi-call instead. Never set for an auto-selected attempt, since you did not ask.",
      +  "type": "boolean"
      +}
  6. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "available_modes": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "delivery_mode": {
      +      "type": "string"
      +    },
      +    "estimated_credits": {
      +      "type": "number"
      +    },
      +    "ok": {
      +      "type": "boolean"
      +    },
      +    "poll_url": {
      +      "type": "string"
      +    },
      +    "status": {
      +      "type": "string"
      +    },
      +    "task_type": {
      +      "type": "string"
      +    },
      +    "value_class": {
      +      "type": "string"
      +    },
      +    "workflow_id": {
      +      "type": "string"
      +    }
      +  },
      +  "type": "object"
      +}
  7. Changed5 schema fields changed
    • removedInput schema / properties / preferences / properties / quality_level
      Removed value: -{
      -  "description": "minimum | standard | maximum.",
      -  "type": "string"
      -}
    • addedInput schema / properties / preferences / properties / rigor_level
      Added value: +{
      +  "description": "quick | standard (default) | thorough. Controls analysis depth and cost.",
      +  "type": "string"
      +}
    • removedInput schema / properties / preferences / properties / tool_scope
      Removed value: -{
      -  "description": "mandatory | recommended | all.",
      -  "type": "string"
      -}
    • changedInput schema / properties / task_description / description
      Previous value: -"Natural language description of the task. Be specific."New value: +"Natural language description of the task. Be specific — include what you want produced, constraints, and context. Example: 'Design a caching layer for our API gateway with Redis integration.'"
    • changedInput schema / properties / task_type / description
      Previous value: -"Optional classification hint."New value: +"Optional hint to bypass automatic classification. Values: solution_design, requirements_analysis, code_implementation, code_review, bug_fix, root_cause_analysis, incident_response, deployment_execution, competitive_scan, financial_analysis, research_task, documentation, governance_change, compliance_audit, data_security_assessment, performance_optimization, user_story_definition, implementation_prompt_generation."
  8. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover only the safety profile (readOnly=false, idempotent=false, openWorld=true, destructive=false); the description goes well beyond by disclosing the credit/billing model (prior_workflow_id 'is charged as a new run at the normal quote'), the 402 max_budget_exceeded refusal that fires before anything runs or is charged, delivery semantics (SSE/webhook/polling, with polling the MCP default), and the execution-mode fallbacks. These are the operational traits an agent most needs and none are in the 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?

Front-loaded with the action, then the rigor_plan prerequisite, then the direct-execution branch — a sensible ordering. However, the execution-mode sentence is a very long run-on packing several edge cases, and the direct/output_contract guidance largely duplicates what the schema fields already say, so a bit of it does not earn 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?

With an output schema present the description needn't explain return values, and it correctly spends its length on routing, cost, delivery, and refusal behavior instead. Annotations, a fully documented 7-param schema, and this description together leave nothing an agent needs missing before invocation.

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 7 parameters, including the nested output_contract and delivery objects. The description restates the same guidance (direct execution, output_contract validation, delivery methods) rather than adding syntax, formats, or defaults the schema lacks. Baseline 3 applies when the schema does the heavy lifting.

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?

The opening states a specific verb+resource ('Execute a structured workflow end-to-end') and immediately scopes what the tool produces (solution designs, competitive analyses, governance documents) and how it routes work (classifies the task, selects a tool sequence, executes each step). It also distinguishes itself from the sibling rigor_plan by naming it as the free preview step. An agent can separate this from rigor_status/rigor_workflows 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 Guidelines5/5

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

Explicitly instructs to call rigor_plan first to preview sequence and cost before committing credits, and gives an explicit branch: for atomic work set preferences.execution='direct' with an output_contract. It also states fallback conditions (attachments or prior_workflow_id force standard execution). This is when-to-use, when-not, and alternative-selection guidance all in one.

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