QA Orchestrator

Overview Schema Source Related Servers Discussions Admin

finish_qa_orchestration

Idempotent

Record the host's chosen QA outcome—completed, partial, or blocked—to finalize a session after synthesis or an early stop; no review step runs.

Instructions

Finalize the host's outcome after synthesis or an early stop; no review step runs here.

Call when advance_qa_orchestration reaches awaiting_host_outcome after synthesis, or after it records an early stop. For an early stop, submit the same partial or blocked outcome.

Repeating the same outcome returns the retained terminal session. A conflicting outcome is rejected with conflicting final outcome and leaves the stored status unchanged.
Retention ends when the configured TTL expires (1800 seconds by default), a terminal session is evicted to free capacity, or the service restarts. After removal, the run_id is unavailable and the outcome can no longer be deduplicated.

This tool records the host's decision; it does not make it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`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.
`outcome`	Yes	Host-selected final session status: completed, partial, or blocked.

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.

Changed1 schema field changedv0.1.6Sep 29, 2026

changedInput schema / properties / outcome / description

Previous value: -"Host-selected final QA outcome: completed after synthesis, or the same partial or blocked outcome already used for an early stop. Conflicting final outcomes are rejected."New value: +"Host-selected final session status: completed, partial, or blocked."

Changed2 schema fields changedv0.1.1Sep 29, 2026

addedInput schema / properties / outcome / description

Added value: +"Host-selected final QA outcome: completed after synthesis, or the same partial or blocked outcome already used for an early stop. Conflicting final outcomes are rejected."

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."

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 declare idempotence and non-destructiveness, and the description goes well beyond them: repeat outcomes return the retained terminal session, conflicts are rejected with a specific error and leave the stored status unchanged, and retention ends on TTL expiry (1800s), eviction, or restart. It also disclaims agency ('it does not make it'). This is unusually rich behavioral disclosure.

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

Conciseness5/5

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

Front-loaded with the one-line purpose, then conditions, then behavioral rules as bullets. Every sentence carries non-redundant information; nothing is padding.

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-value detail is not needed. The description covers the lifecycle (when to call), error semantics, idempotence/dedup, and retention limits — everything needed to invoke and reason about the call correctly.

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

Parameters4/5

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

Schema coverage is 100% and both parameters are documented in the schema (run_id pattern, outcome enum). The description still adds meaning beyond the schema by prescribing which outcome values are valid for the early-stop path, which is value-selection guidance not present in the field descriptions.

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+resource: 'Finalize the host's outcome after synthesis or an early stop.' It also disambiguates against the sibling advance_qa_orchestration by denying scope ('no review step runs here'), so an agent can separate it from the other orchestration tools 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?

Explicit trigger conditions are given: call when advance_qa_orchestration reaches `awaiting_host_outcome` after synthesis, or after it records an early stop. It also states the correct action for the early-stop path (submit the same `partial` or `blocked` outcome). No inference required.

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

Deploy Server