QA Orchestrator

Overview Schema Source Related Servers Discussions Admin

Read specialist review checklist

prepare_qa_orchestration

Read-onlyIdempotent

Return one specialist's fixed ReviewRoute checklist: profile, display_name, focus, required_sections, constraints, and escalation_signals.

Instructions

Return one specialist's fixed ReviewRoute checklist: profile, display_name, focus, required_sections, constraints, and escalation_signals.

Use before reviewing one scoped concern when no session is active, or to recover a checklist when the triage response is unavailable; no session is required.

Standalone review: use get_qa_orchestration_catalog() to match profile focus to changed files and confirmed stack.
Session primary_review: use selected_review_routes returned by the successful triage advance call. It contains every selected checklist and execution_group; do not make a separate preparation call for the same session.

This local lookup reads bundled definitions, without executing reviews or calling models. Use advance_qa_orchestration to apply a session route. Results depend only on agent_profile. Invalid values fail input validation; retry with a listed enum value.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agent_profile`	Yes	Choose one fixed specialist profile: code_explorer maps execution and evidence; code_reviewer reviews implementation; pr_test_analyzer reviews coverage; security_reviewer and silent_failure_hunter target security and silent failures; ruby_reviewer, python_reviewer, typescript_reviewer, react_reviewer, and mobile_reviewer target their named stacks. Choose from changed files and confirmed stack.

Output Schema

TableJSON Schema

Name	Required	Description
`focus`	Yes	The profile's review boundary and primary responsibility.
`profile`	Yes
`read_only`	No
`constraints`	Yes	Shared limits for this read-only review profile.
`display_name`	Yes
`required_sections`	Yes	Profile-specific output sections; use these instead of a generic template.
`escalation_signals`	No	Conditions to assess against evidence. A listed condition is not itself a deep-review trigger; set risk_signals only when the corresponding evidence-based condition applies.
`host_owns_decisions`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.12Sep 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover readOnly/idempotent/openWorld, but the description adds real context beyond them: it is a local lookup of bundled definitions that executes no reviews or models, needs no session, is deterministic on agent_profile, and fails input validation on invalid enums. It does not, however, describe anything about the returned checklist structure beyond naming the fields, and no output schema detail is referenced.

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-loads the core purpose, then uses tight bullets for the two usage scenarios before closing with two short operational notes. Slightly long with some restatement of the session distinction, but every section carries information.

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 a single enum parameter, full schema coverage, existing annotations, and an output schema covering return values, the description supplies everything else needed: usage routing, no-session behavior, local-only execution, and error recovery. Nothing an agent needs to invoke it 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% and the enum values are already fully documented in the schema itself, so the baseline is 3. The description adds only marginal value: 'Results depend only on agent_profile' and the retry-with-listed-enum guidance, which is behavioral rather than semantic.

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?

Opens with a concrete verb and resource: 'Return one specialist's fixed ReviewRoute checklist', then names the exact payload fields (profile, display_name, focus, required_sections, constraints, escalation_signals). It is clearly distinguishable from siblings like advance_qa_orchestration, get_qa_orchestration_catalog, and prepare_qa_orchestration_bundle.

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 explicit when-to-use branches: standalone review uses get_qa_orchestration_catalog to match profile to changed files, while session primary_review should use selected_review_routes from triage instead. It also states the exclusion plainly – 'do not make a separate preparation call for the same session' – and notes no session is required.

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

Deploy Server