AI Design Blueprint

Official

Overview Schema Source Related Servers Discussions Admin

architect.validate_consensus

Runs multiple parallel architecture validations and aggregates them into a consensus score with variance metrics, giving an honest unanchored first-pass assessment of agentic code quality.

Instructions

Pro/Teams — N-shot CONSENSUS doctrine review of agentic code. ON CLIENT TIMEOUT — DO NOT RETRY THIS TOOL. Long-running (~80-120s for N=3 parallel LLM calls); MCP clients often close the call before the server returns. Retrying re-runs N × 60-180s LLM calls from scratch and burns N× compute. RECOVERY: same heartbeat pattern as architect.validate — the run_id is emitted in the FIRST progress event at t=0s (before LLM children fire); on timeout, call me.validation_history(run_id='<that-id>') to fetch the persisted consensus envelope. Runs N parallel architect.validate calls with private_session=True, then aggregates them to a per-principle MODE verdict + median severity + per-principle stability + score range/stdev. Returns one ConsensusValidationResponse with the headline median score, the honest variance band, and a representative full ValidationResponse (the child whose score is closest to the median). WHEN TO CALL: the user wants an HONEST first-pass score on agentic code, with the architect's variance surfaced. The single-shot architect.validate re-asserts the prior persisted run's verdict via baseline-anchor injection — same code can score 60/C anchored vs 98/A unanchored. Consensus mode is the unanchored honest read. WHEN NOT TO CALL: when you NEED the iteration delta against a prior run (regressions/improvements panel) — for that, call architect.validate which keeps baseline injection on. CHAIN RESUME: each child runs with private_session=True (no anchor) on purpose, but the CONSOLIDATED outer row IS persisted with lifecycle_status='completed' — the next single-shot architect.validate on the same repository auto-resolves it as prior_run_baseline. Consensus checkpoint becomes the new anchor. See the architect-validation-orchestration skill in the agent-asset pack for the full validate → consensus → certify sequence. BEHAVIOR: N (default 3, max 5) parallel LLM calls run concurrently; wallclock ~80-120s for N=3 (max child latency, not sum). Cost = N × LLM bill. Each child runs with private_session=True so the doctrine prompt's prior-run baseline injection is suppressed (no anchor bias). One CONSOLIDATED UserValidationRun row is written carrying the consensus envelope; the N children themselves do NOT persist (private_session contract). AUTH: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan. Same paid-plan gate as architect.validate. INPUTS: same shape as architect.validate. n is the only extra arg (range 2..5). private_session is implicit (always true for children); the OUTER consolidated row IS persisted unless the tool itself is called inside another private context — but no such wrapper exists today. OUTPUT: response carries score_consensus_median (headline), score_stdev (honest uncertainty), score_range (min, max), mode_stability_min_pct (the cert-eligibility gate's input — ≥ 80% means the consensus is stable), per_principle (mode + distribution + severity median per principle), and representative_response (the closest-to-median child's full ValidationResponse so existing UI components render unchanged). TYPED FAILURES: same as architect.validate (timed_out, rate_limited, dependency_unavailable). Plus consensus-specific: consensus_quorum_failed when fewer than 2 child runs succeeded (≥ 2 required to compute a meaningful median).

Input Schema

TableJSON Schema

Name	Required	Description
`n`	No	Number of parallel child runs. Default 3 (the variance signal is visible at N=3; cost = 3× LLM bill). Capped server-side by Settings.consensus_n_max (default 5).
`task`	No	What the agent or workflow is trying to accomplish.
`files`	No	List of file paths relevant to the implementation.
`goals`	No	Specific safety or quality goals to evaluate against.
`language`	No	Programming language of the code (e.g. 'python').
`focus_area`	No	Optional: narrow the review to a principle cluster or slug.
`repository`	No	Iteration key. Consensus children all run unanchored (`private_session=True`), but the consolidated row IS persisted under this key — discoverable as prior baseline for the next single-shot `architect.validate`. Same value across calls keeps the iteration arc inspectable.
`example_limit`	No	Max curated examples per child run.
`implementation_context`	Yes	The artifact under review. SEND FULL FILE CONTENTS VERBATIM — same constraint as architect.validate. Truncation produces hallucinated findings on code that isn't there.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.2.0Jul 24, 2026

changedInput schema / properties / repository / description

Previous value: -"Repository name or path. Lets the consensus row group into the per-project history view alongside single-shot validate runs."New value: +"Iteration key. Consensus children all run unanchored (`private_session=True`), but the consolidated row IS persisted under this key — discoverable as prior baseline for the next single-shot `architect.validate`. Same value across calls keeps the iteration arc inspectable."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "title": "validate_consensus_agent_architectureDictOutput",
+  "type": "object"
+}

Addedv1.1.1May 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only signal a mutating, non-idempotent call, but the description discloses long-running 80-120s behavior, the do-not-retry rule, run_id emission timing, private_session persistence semantics (children not persisted, consolidated row is), auth/plan gate, and consensus-specific typed failures. This far exceeds annotation coverage.

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 description is long and repeats a few facts (cost, private_session, n cap) across sections, so it is not maximally concise. However, it is well-structured with clear headers and front-loads the most critical operational warning (do not retry on timeout) before details.

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?

For a complex, expensive, long-running operation with an output schema, the description covers inputs, outputs, failure modes, auth, recovery, persistence, and downstream chaining. Nothing an agent needs to invoke or recover from this tool is left unexplained.

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%, so the baseline is 3, but the description adds real value: it identifies n as the only extra arg, notes the server-side cap of 5 despite the schema max of 10, explains repository's role as iteration-key/baseline persistence, and stresses sending full file contents verbatim for implementation_context. It does not individually enrich every parameter, but the schema already covers those.

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 description states a specific mechanism — running N parallel architect.validate calls and aggregating them into a per-principle mode verdict, median severity, stability, and score range/stdev — and names the return type (ConsensusValidationResponse). It also differentiates itself from architect.validate by framing consensus as the unanchored honest read versus single-shot baseline-anchored reassertion.

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?

Provides explicit WHEN TO CALL and WHEN NOT TO CALL sections, including the concrete alternative (architect.validate) for iteration-delta needs. It further gives timeout recovery instructions and the chained validate → consensus → certify sequence, so an agent knows exactly when this tool is appropriate.

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