Skip to main content
Glama

Read bundle review checklists

prepare_qa_orchestration_bundle
Read-onlyIdempotent

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

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. After every profile in the group finishes, record the complete group once in bundle order with completed_profiles. Older hosts may continue using completed_profile one at a time. 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

TableJSON 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

TableJSON 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. Addedv0.2.5

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/no-open-world, but the description adds operational semantics: stateless lookup, no session creation, no model calls, and the ordering/concurrency rules for execution_groups. It does not cover error behavior or pagination, but the added workflow context is substantial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

Purpose and usage are front-loaded, but the middle block about recording completed groups with completed_profiles vs completed_profile describes the advance tool's workflow rather than this read tool, which is scope bleed in an otherwise tight definition.

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 need not explain return values; it covers purpose, usage conditions, the alternative tool, and execution semantics. Nothing an agent needs 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 description coverage is 100% with an enum, so the schema already fully documents the single 'bundle' parameter. The description's note that it returns checklists and ordered execution_groups adds only marginal meaning beyond the enum list.

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: 'Return every fixed ReviewRoute checklist and execution wave for one bundle.' It explicitly distinguishes itself from prepare_qa_orchestration (single profile) and implicitly from advance/triage flows, so an agent can route without opening schemas.

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?

Gives concrete when-to-use conditions ('standalone bundle lookup or to recover checklists when the successful triage response is unavailable') and names the alternative for the single-profile case. Nothing about selection is left to inference.

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