QA Orchestrator

Overview Schema Source Related Servers Discussions Admin

advance_qa_orchestration

Complete the current QA review step or record an early stop, returning the next action so an orchestrated review run can proceed.

Instructions

Complete the active review step or mark an early stop; return the next action.

Pass current_step as completed_step; stale or out-of-order steps are rejected. Malformed arguments, incompatible signals, and unknown or expired run_ids return errors without advancing the run. This call is non-idempotent: if a successful response is lost, inspect get_qa_orchestration before continuing; replaying the prior step is rejected.

Completed triage requires exactly one of selected_bundle or selected_profile; omit both when stopping early.
After each completed primary review, send current_profile as completed_profile. On the final profile, also send risk_signals ({} if none apply); omit both on an early stop.
An early stop records partial or blocked but still needs finish_qa_orchestration with the same outcome. After synthesis, use finish_qa_orchestration for the host's final outcome.

Input Schema

TableJSON Schema

Name	Required	Description
`run_id`	Yes	Session identifier returned by start_qa_orchestration: qar- followed by 32 lowercase hexadecimal characters. Reuse it for this session; do not invent or transform it.
`status`	Yes	Use completed after the active step succeeds. Use partial or blocked to stop early; then finalize with the same outcome using finish_qa_orchestration.
`risk_signals`	No	Required with the final completed primary-review profile. Send an empty object when no evidence-based fixed escalation signals apply; do not send on earlier profiles or on the synthesis transition.
`completed_step`	Yes	Active step returned in current_step and completed by this call: triage, primary_review, deep_review, or synthesis. When current_step is awaiting_host_outcome, call finish_qa_orchestration instead.
`selected_bundle`	No	For completed triage, choose one allowed fixed bundle for a broad or cross-concern review. It is mutually exclusive with selected_profile; recommended_bundles is only a shortlist.
`selected_profile`	No	For completed triage, choose one allowed profile for a narrow, low-risk review. It is mutually exclusive with selected_bundle.
`completed_profile`	No	After each successful primary-review step, submit exactly the current_profile returned by the previous advance_qa_orchestration call. Omit for other steps or an early stop.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`run_id`	Yes
`status`	Yes
`read_only`	No
`task_type`	Yes
`expires_at`	Yes
`next_action`	Yes
`current_step`	Yes
`model_policy`	No
`allowed_bundles`	No
`current_profile`	No
`deep_assessment`	No
`review_profiles`	No
`selected_bundle`	No
`allowed_profiles`	No
`deep_reason_code`	No
`selected_profile`	No
`completed_profiles`	No
`host_owns_decisions`	No
`recommended_bundles`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 schema fields changedv0.1.1Sep 29, 2026

addedInput schema / properties / completed_profile / description

Added value: +"After each successful primary-review step, submit exactly the current_profile returned by the previous advance_qa_orchestration call. Omit for other steps or an early stop."

addedInput schema / properties / completed_step / description

Added value: +"Active step returned in current_step and completed by this call: triage, primary_review, deep_review, or synthesis. When current_step is awaiting_host_outcome, call finish_qa_orchestration instead."

changedInput schema / properties / completed_step / enum

Previous value: -[
-  "triage",
-  "primary_review",
-  "deep_review",
-  "synthesis",
-  "awaiting_host_outcome"
-]New value: +[
+  "triage",
+  "primary_review",
+  "deep_review",
+  "synthesis"
+]

changedInput schema / properties / risk_signals / description

Previous value: -"Required with the final completed primary-review profile. Send an empty object when no signals apply."New value: +"Required with the final completed primary-review profile. Send an empty object when no evidence-based fixed escalation signals apply; do not send on earlier profiles or on the synthesis transition."

addedInput schema / properties / run_id / description

Added value: +"Session identifier returned by start_qa_orchestration: qar- followed by 32 lowercase hexadecimal characters. Reuse it for this session; do not invent or transform it."

addedInput schema / properties / selected_bundle / description

Added value: +"For completed triage, choose one allowed fixed bundle for a broad or cross-concern review. It is mutually exclusive with selected_profile; recommended_bundles is only a shortlist."

addedInput schema / properties / selected_profile / description

Added value: +"For completed triage, choose one allowed profile for a narrow, low-risk review. It is mutually exclusive with selected_bundle."

addedInput schema / properties / status / description

Added value: +"Use completed after the active step succeeds. Use partial or blocked to stop early; then finalize with the same outcome using finish_qa_orchestration."

First observedv0.1.0Sep 28, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare non-idempotency (idempotentHint=false), but the description goes further by spelling out the consequence: a lost successful response must be recovered via get_qa_orchestration because replaying the prior step is rejected. It also discloses validation behavior (malformed args, incompatible signals, unknown/expired run_ids error without advancing) and state mutation (early stop records partial/blocked), all consistent with 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?

The summary is front-loaded in the first sentence, followed by an ordered bullet list of transition rules. It is dense but each bullet carries a distinct rule; sizing is slightly heavy but justified by the workflow complexity, with no pure filler.

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?

An output schema exists so return shape needn't be described, and the description covers the remaining gaps: step sequencing, mutual exclusivity, escalation-signal timing, and recovery after a lost response. Nothing an agent needs to drive this multi-step orchestration correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even with 100% schema coverage, the description adds cross-parameter conditional logic the schema cannot express: exactly one of selected_bundle or selected_profile on completed triage (omit both on early stop), completed_profile on every primary-review step, and risk_signals only on the final profile with {} when none apply. This sequencing semantics materially exceeds the per-field schema text.

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 precise verb+resource ('Complete the active review step or mark an early stop; return the next action') and immediately clarifies it is the step-advancing tool. It explicitly contrasts with siblings by naming finish_qa_orchestration and get_qa_orchestration and the conditions under which each applies, so an agent can disambiguate 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?

It states explicit routing rules: use finish_qa_orchestration when current_step is awaiting_host_outcome, and use it again for the host's final outcome after synthesis. It also covers when-not scenarios (stale or out-of-order steps rejected, early stop still requires finish_qa_orchestration) with concrete alternative conditions.

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

Deploy Server