Skip to main content
Glama
Sign In
QA Orchestrator

QA Orchestrator

by Rbkmen
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Read bundle review checklists

prepare_qa_orchestration_bundle
Read-onlyIdempotent

Returns all fixed ReviewRoute checklists and ordered execution waves for a selected QA bundle, enabling standalone lookup or recovery when triage results are unavailable.

Instructions

Return every fixed ReviewRoute checklist and execution wave for one bundle.

Use for standalone bundle lookup or to recover checklists when the successful triage response is unavailable. In a session, the triage advance response includes the selected checklists and execution_groups. Run execution_groups in order; profiles in one group are independent and may run concurrently when the host supports it. For session transitions, follow advance_qa_orchestration's group-reporting rules. For a single profile, use prepare_qa_orchestration. This stateless lookup reads bundled definitions; it does not execute reviews, create a session, or call models.

Input Schema

NameRequiredDescriptionDefault
bundleYesSelected fixed multi-profile bundle. The tool returns every checklist and its ordered execution_groups. Profiles in the same group may run concurrently; for one profile, use prepare_qa_orchestration.

Output Schema

NameRequiredDescriptionDefault
bundleYesFixed bundle whose profile checklists are returned.
routesYesDetailed checklists in the selected route's declared profile order. Each route is a fixed, read-only checklist; it does not execute a review.
execution_groupsYesOrdered execution waves whose flattened profile IDs exactly match routes. Run the groups in order; profiles in the same group are independent and may be reviewed concurrently by the host. Wait for every profile in a group before reporting it with one completed_profiles call in the declared order. Older hosts may report each completed_profile separately.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.20
    • changedOutput schema / properties / execution_groups / items / items / enum
      Previous value: -[
-  "pr_test_analyzer",
-  "code_reviewer",
-  "security_reviewer",
-  "silent_failure_hunter",
-  "code_explorer",
-  "typescript_reviewer",
-  "react_reviewer",
-  "ruby_reviewer",
-  "python_reviewer",
-  "mobile_reviewer",
-  "omission_auditor"
-]New value: +[
+  "pr_test_analyzer",
+  "code_reviewer",
+  "security_reviewer",
+  "silent_failure_hunter",
+  "code_explorer",
+  "typescript_reviewer",
+  "react_reviewer",
+  "ruby_reviewer",
+  "python_reviewer",
+  "mobile_reviewer"
+]
    • changedOutput schema / properties / routes / items / properties / profile / enum
      Previous value: -[
-  "pr_test_analyzer",
-  "code_reviewer",
-  "security_reviewer",
-  "silent_failure_hunter",
-  "code_explorer",
-  "typescript_reviewer",
-  "react_reviewer",
-  "ruby_reviewer",
-  "python_reviewer",
-  "mobile_reviewer",
-  "omission_auditor"
-]New value: +[
+  "pr_test_analyzer",
+  "code_reviewer",
+  "security_reviewer",
+  "silent_failure_hunter",
+  "code_explorer",
+  "typescript_reviewer",
+  "react_reviewer",
+  "ruby_reviewer",
+  "python_reviewer",
+  "mobile_reviewer"
+]
  2. Changed2 schema fields changedv0.2.16
    • changedOutput schema / properties / execution_groups / items / items / enum
      Previous value: -[
-  "pr_test_analyzer",
-  "code_reviewer",
-  "security_reviewer",
-  "silent_failure_hunter",
-  "code_explorer",
-  "typescript_reviewer",
-  "react_reviewer",
-  "ruby_reviewer",
-  "python_reviewer",
-  "mobile_reviewer"
-]New value: +[
+  "pr_test_analyzer",
+  "code_reviewer",
+  "security_reviewer",
+  "silent_failure_hunter",
+  "code_explorer",
+  "typescript_reviewer",
+  "react_reviewer",
+  "ruby_reviewer",
+  "python_reviewer",
+  "mobile_reviewer",
+  "omission_auditor"
+]
    • changedOutput schema / properties / routes / items / properties / profile / enum
      Previous value: -[
-  "pr_test_analyzer",
-  "code_reviewer",
-  "security_reviewer",
-  "silent_failure_hunter",
-  "code_explorer",
-  "typescript_reviewer",
-  "react_reviewer",
-  "ruby_reviewer",
-  "python_reviewer",
-  "mobile_reviewer"
-]New value: +[
+  "pr_test_analyzer",
+  "code_reviewer",
+  "security_reviewer",
+  "silent_failure_hunter",
+  "code_explorer",
+  "typescript_reviewer",
+  "react_reviewer",
+  "ruby_reviewer",
+  "python_reviewer",
+  "mobile_reviewer",
+  "omission_auditor"
+]
  3. Addedv0.2.5

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the readOnlyHint/idempotentHint annotations, the description states it is a stateless lookup that does not execute reviews, create a session, or call models, and it discloses execution semantics — run execution_groups in order, with same-group profiles being concurrency-safe. That is meaningful behavioral context the annotations alone do not convey.

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?

Purpose and usage are front-loaded in the first two sentences, and the closing sentence cleanly bounds side effects. However, the concurrency rule for same-group profiles is stated twice (once in the body, once in the parameter description) and the terminology drifts between 'execution wave' and 'execution_groups'.

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, return values need not be explained, and the description still covers selection, alternatives, ordering/concurrency of execution groups, and the absence of side effects. Nothing an agent needs in order to call this correctly is missing.

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 the single enum parameter already lists all bundle values and explains same-group concurrency. The description only restates that the tool returns checklists and ordered groups for one bundle, adding little semantic detail the schema does not already carry, so the 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?

The opening sentence gives a specific verb and resource — returning every fixed ReviewRoute checklist plus execution groups for exactly one bundle — and immediately scopes it with 'one bundle'. It also names the sibling that handles the single-profile case (prepare_qa_orchestration), so an agent can distinguish it without opening the 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?

Explicit when-to-use cases are given: standalone bundle lookup, or recovering checklists when the triage response is unavailable. It also routes session transitions to advance_qa_orchestration's group-reporting rules and single-profile work to prepare_qa_orchestration, covering both alternatives and exclusions.

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

Deploy Server

Other Tools