QA Orchestrator
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| QA_ORCHESTRATOR_DATA_DIR | No | Directory for QA Orchestrator data. | ~/.qa-orchestrator |
| QA_ORCHESTRATOR_MODEL_POLICY_PATH | No | Path to the model policy JSON file. | ~/.qa-orchestrator/model-policy.json |
| QA_ORCHESTRATOR_SESSION_STORE_PATH | No | Optional local SQLite file path to restore unfinished orchestration state after restart; disabled when unset. | |
| QA_ORCHESTRATOR_ORCHESTRATION_TTL_SECONDS | No | TTL in seconds for orchestration sessions. | 1800 |
| QA_ORCHESTRATOR_ORCHESTRATION_MAX_SESSIONS | No | Maximum number of active orchestration sessions. | 100 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| resolve_git_review_inputA | Resolve two locally available Git refs into immutable commits and diff metadata. The repository path is on the server host. This compares the resolved commits directly; choose the merge base explicitly when a merge-base comparison is required. It does not fetch refs, inspect uncommitted changes, or construct the evidence packet. Unresolvable refs fail; both refs must resolve to different commits with a nonempty diff. |
| prepare_qa_orchestrationA | 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.
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. |
| prepare_qa_orchestration_bundleA | 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. |
| get_qa_orchestration_catalogA | Read the static profile/bundle catalog: specialists, review scopes, and execution schedules. Use before creating a session or choosing its triage route; no session or arguments required. Task-type recommendations are shortlists, not restrictions. Choose a bundle for broad work or a single profile for a narrow concern using changed files and confirmed stack.
Available routes come from the installed server's bundled definitions; active sessions and configured models do not change this catalog. |
| get_qa_orchestration_model_policyA | Read the server-wide model policy used to create new sessions. The mode is either host_default (use the host's configured model and reasoning) or configured (use the returned per-stage provider, model IDs, and reasoning). Use to inspect the policy loaded for new sessions; takes no arguments.
Reads the loaded in-memory snapshot, not the current policy file; restart the server connection after file changes. No session is created and no provider is contacted; the result does not verify which model the host executed. |
| start_qa_orchestrationA | Create a QA session and bind code reviews to one immutable review input. Before calling for ordinary_review or widget_review, complete review preflight: resolve the authoritative task/MR, pin exact base_sha and head_sha for Git input, or use input_kind=diff with no Git revisions for a standalone unified diff; inspect the exact diff, build the host-owned Evidence Packet and stable refs, compute diff_sha256 and evidence_packet_sha256, and provide input_manifest.schema_version=2 with source_inventory_status and source_conflict_status. A task or MR URL alone is not enough. If an exact repository, required Git revisions, diff, or packet identity cannot be pinned, do not start; resolve it or tell the user what is missing. Record unavailable requirement/spec sources with partial or unknown manifest statuses. Every call creates a separate session. Use prepare_qa_orchestration for a stateless profile
checklist.
|
| advance_qa_orchestrationA | Record one active QA step's result; return updated state and next_action instructions for the host. After completed triage, the response also includes selected_review_routes with the exact selected checklists and execution_groups, avoiding a separate preparation tool call. For finalization, use finish_qa_orchestration at awaiting_host_outcome; after early stops, match the recorded outcome.
|
| renew_qa_orchestrationA | Extend an active session's TTL while host review work is running. Pass the retained run_id and, optionally, the latest session revision as expected_revision; a stale revision fails without renewing. Before expires_at, active primary/deep/synthesis and awaiting-host-outcome sessions may be renewed. Terminal or expired sessions cannot be revived. Only the lease changes: no workflow revision advances and no worker or model is launched. Use advance_qa_orchestration to record progress and finish_qa_orchestration for the outcome. |
| get_qa_orchestrationA | Read one retained run_id's state, audit trace, bound context and structured reports. Use run_id on the server retaining that session to resume or reconcile a lost
advance_qa_orchestration response. Reads do not extend expires_at. Errors For all-stage server policy, use get_qa_orchestration_model_policy(); for review progress or final outcome, use advance_qa_orchestration or finish_qa_orchestration, respectively. Local stdio access requires no additional credentials. |
| list_qa_orchestrationsA | List non-expired QA session identifiers and brief metadata, including bound review identity. Recover a lost run_id by matching task type, route, and stage; confirm if several match. Call get_qa_orchestration(run_id) for full state and next action, or get_qa_orchestration_model_policy() for server policy. Takes no arguments.
|
| delete_qa_orchestrationA | Delete one QA session from memory and configured recovery storage. To retain a final QA outcome, use finish_qa_orchestration. run_id selects one session at any stage; no prior advance or finish required. Recover a lost ID via list_qa_orchestrations(), matching task type, route, and stage; confirm the target if several entries match.
Host tasks and model executions are unaffected. |
| finish_qa_orchestrationA | Finalize the QA run and store its structured report when the session is review-bound. After normal synthesis or an eligible clean single-profile fast path, use the retained run_id at awaiting_host_outcome to choose completed, partial, or blocked. After an early stop recorded by advance_qa_orchestration, outcome must match its partial/blocked status.
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Most tools have clearly distinct lifecycle roles: start, advance, finish, renew, get, list, delete, prepare, and static policy/catalog lookups. The main possible confusion is among the three static/preparation tools (catalog, single-profile prepare, and bundle prepare), but their descriptions give enough guidance to distinguish them.
The tools overwhelmingly follow a snake_case verb_noun pattern, mostly centered on qa_orchestration. Minor deviations include prepare_qa_orchestration vs. prepare_qa_orchestration_bundle, get_qa_orchestration_catalog/model_policy, list_qa_orchestrations plural form, and resolve_git_review_input outside the qa_orchestration prefix.
Twelve tools are well-scoped for a QA orchestration lifecycle covering session creation, state advancement, finalization, deletion, renewal, listing, preparation, policy, catalog, and Git input resolution. Each tool appears to earn its place without excessive fragmentation.
The surface covers the full session lifecycle and supporting operations: start, advance, finish, renew, get, list, delete, plus static catalog/model-policy lookup and review-input preparation. It also handles stateless checklist preparation and Git diff resolution, leaving no obvious lifecycle gap.