MCP Server
AI Design Blueprint
com.aidesignblueprint/blueprint
What this MCP does
Provides agent architecture, experience design, and specification doctrine, validators, examples, guides, learning paths, and governed validation sessions.
Capabilities
Tools
29
tools
architect.certify
Certify Production-Ready Architecture
Pro/Teams: second-pass adversarial certification of an architect.validate run that scored production_ready (A or B first-pass tier). ON CLIENT TIMEOUT: DO NOT RETRY THIS TOOL. **RECOVERY FIRST**: the run_id is emitted in the FIRST notifications/progress event at t=0s (BEFORE the LLM call begins). Capture it. On timeout, call `me.validation_history(run_id='<that-id>')` to fetch the persisted cert verdict; the server-side run completes independently within a 6-minute budget. This is the canonical recovery path. Use it before considering any retry. Long-running LLM call (60-180s typical; exceeds Claude Code's ~60s idle budget); MCP clients commonly close the call before the server returns. Retrying re-runs the LLM call AND burns one of your 3 cert retry-budget attempts. Mints the certified production_ready badge when both reviewers sign off; caps the run to C/emerging when the second pass surfaces a missed production_blocker. MANDATORY DOCTRINE RULE (load-bearing): the badge certifies the EXACT code that produced the validate run_id, NOT 'this codebase' in general. If you modify, fix, or iterate the code between architect.validate and architect.certify, even by a single character, cert rejects with code_fingerprint_mismatch. Fixing the code voids the run. The recovery path is always: edit code → architect.validate → fresh run_id → architect.certify on the fresh run. Do NOT cert from a stale run_id after iteration; ask the user to re-validate first. WHEN TO CALL: only after architect.validate returned tier=production_ready AND the user wants the certified badge AND the code has not been touched since the validate run. NOT for tier=draft/emerging/not_applicable runs (typed rejections fire, see below). NOT idempotent across attempts: each call is one of the 3 attempts in the retry budget. BEHAVIOR: atomic one-shot single LLM call, ~60-180s server-side at high reasoning effort (small payloads finish faster; observed p99 ~250s; server-side budget is 6 min, above the observed range). Exceeds typical MCP-client tool-call idle budget (~60s in Claude Code), so the FIRST notifications/progress event fires at t=0 carrying the run_id. The run is atomic by contract: no in_progress lifecycle, no cancellation, no resume. Updates the persisted run's result_json (public review URL + me.validation_history(run_id=...) reflect the cert outcome). ELIGIBILITY GATE (typed rejection enum on failure): caller must own the run, tier=production_ready, less than 24h old, not already certified, within cert retry budget (max 3 attempts), no other cert call in flight for the same run_id, code fingerprint must match the validated code, AND the submitted payload must be cert-payload-complete (see Payload Completeness below; cert rejects pre-LLM with `payload_incomplete` when an imported module's surface isn't visible in the validate payload that produced this run_id). Rejection reasons (typed Literal): auth_required, paid_plan_required, run_not_found, not_run_owner, not_eligible_tier, not_agentic_component (tier=not_applicable runs), already_certified, certification_age_exceeded, retry_budget_exhausted, code_fingerprint_mismatch, code_fingerprint_missing, code_not_on_file (caller omitted `code` argument AND the 24h cert-retry hold for this run has expired or was never written. Recovery: re-run architect.certify from the same MCP session that ran architect.validate, passing the code explicitly; a standard production_ready run holds the code for 24 hours only, then an automatic clean-up deletes it), payload_incomplete (submitted/validated payload imports modules whose contents aren't visible; cert refuses pre-LLM to prevent a false-precision downgrade. Recovery: re-validate with verbatim public-surface stubs for every imported module, then re-cert on the fresh run_id. Empirically validated: PR #157 iter8/iter9 cert rejections were exactly this class: code on disk was correct, the submitted payload merely omitted module visibility), cert_consensus_score_below_threshold (consensus_median<75, consensus runs only), cert_consensus_unstable_blocker (any principle mode_stability<80%, consensus runs only), run_state_corrupt, cert_persistence_failed, cert_in_flight (a prior architect.certify call on this run_id is still running. Poll me.validation_history for the verdict; do not retry until it resolves). PAYLOAD COMPLETENESS (load-bearing for cert eligibility): the cert reviewer reads the EXACT payload that produced the validate run_id. Imported modules whose surface isn't present in the payload cause pre-LLM `payload_incomplete` refusal. Avoidance: when validating with intent to cert, bundle public-surface stubs for every imported module: `from sqlalchemy.exc import SQLAlchemyError` → include a stub class; `from app.db import models` → include a `class models:` namespace stub with the columns/methods you reference; module-level imports of `dataclass`, `Literal`, `json`, `datetime`, `timezone` MUST also be in the payload (cert correctly catches when they're omitted, as the code would NameError on import). 'Submit Like Production': the payload should be the code as it would actually run, not a compressed sketch. The stubs cover IMPORTED dependencies only; the certified code's own enforcement branches (approval gates, policy checks, recovery paths) must be present in full. A `# ...` placeholder reads as an ABSENT control and is graded against you, not as shorthand for one that exists. PRE-LLM REJECTION AUDIT TRAIL: when cert rejects before the LLM call (payload_incomplete, code_fingerprint_mismatch, etc.), `certification_attempts=[]` on the response: no attempt landed in the retry budget, no LLM hop occurred. The rejection envelope's `rejection_reason` + `guidance` are the actionable surface. (Audit-trail UI surfacing of pre-LLM rejections is tracked in the platform self-audit set as anomaly #5; out of scope for the cert tool itself.) INPUTS: re-send the SAME code that produced the run_id (the stored run keeps findings and recommendations; a production_ready standard run also holds the code for 24 hours, after which it can no longer be used and an automatic clean-up deletes it). Server compares the submitted code's SHA-256 fingerprint to the stored fingerprint and rejects mismatches. Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan. Data at rest in the UK (europe-west2, London). Code processed transiently by OpenAI (no-training-on-API-data) and dropped; payloads JSON-escaped + delimited as inert untrusted data: prompt-injection inside code is ignored. If the cert call fails outright (provider error, persistence error), a fresh architect.certify is the recovery path; the eligibility gate enforces the 3-attempt retry budget. For long-running cert workflows the answer is to re-validate, not to make this tool stateful. OUTCOMES: certification_status ∈ {confirmed_production_ready (badge mints), downgraded_to_emerging (cert review surfaced a missed production_blocker, tier capped at C/emerging), unavailable_provider_error (LLM call failed, retry within budget)}. Cert findings + summary + attempt history surfaced on the persisted run for full inspectability.
Open world
Input schema
{'type': 'object', 'title': 'architect_certify_runArguments', 'required': ['run_id'], 'properties': {'code': {'type': 'string', 'title': 'Code', 'default': '', 'description': 'The same code that was sent to architect.validate to produce this run_id. Sent verbatim: the cert reviewer needs the actual code to surface production_blockers the first pass missed. May be omitted (empty string) when the prior validate stored the code under the 24h cert-retry hold; in that case the server reuses the stored code automatically. Sent under the same enterprise-safety envelope as architect.validate (transient processing, no training, JSON-escaped + delimited).'}, 'run_id': {'type': 'string', 'title': 'Run Id', 'description': "The run_id from a prior architect.validate call. Returned in the validate response when persistence_status='saved'. Must be owned by the caller (per-user authorisation, same gate as me.validation_history)."}}}
Output schema
{'type': 'object', 'title': 'architect_certify_runDictOutput', 'additionalProperties': True}
architect.validate
Validate Agent Architecture
Pro/Teams: first-pass doctrine review of agentic code/workflow against the 10-principle AI Design Blueprint doctrine. ON CLIENT TIMEOUT: DO NOT RETRY THIS TOOL. Long-running LLM call (60-180s typical); MCP clients commonly close the call before the server returns. Retrying re-runs the 60-180s LLM call from scratch and burns compute. RECOVERY: the run_id is emitted in the FIRST notifications/progress event at t=0s (before the LLM call begins), capture it. On timeout, call `me.validation_history(run_id='<that-id>')` to fetch the persisted result; the server-side run completes independently within a 6-minute budget. Edge case: if the transport dropped before the first progress notification (very rare; sub-second window), call `me.validation_history(repository='<same value you passed here>')` to find your most recent run. TASK-AUGMENTED INVOCATION (MCP 2025-11-25, SEP-1686): clients that advertise the `tasks` capability can task-augment this call by including `task: {ttl: <ms>}` inside the JSON-RPC request's `params` (NOT as a tool argument; alongside `arguments`, `_meta`, etc.). The server returns a `CreateTaskResult` immediately (taskId equals the run_id above) and runs the validation in the background. Spec-correct long-running pattern: poll via `tasks/get` for state, fetch the terminal payload via `tasks/result`, listen for `notifications/tasks/status` for push updates, and cancel via `tasks/cancel`. `_meta.progressToken` from the original request stays valid for the entire task lifetime. Sync (non-augmented) calls behave exactly as before, backwards-compatible by construction. The me.validation_history(run_id=...) recovery path remains the canonical recovery handle for clients that don't yet advertise the tasks capability. Returns code_classification (autonomous_agentic_workflow vs non_agentic_component), per-principle findings (verdict, severity_score 0-100, severity_class, code-cited evidence, recommendation), severity-weighted readiness (score|null, grade|null, tier ∈ {production_ready, emerging, draft, not_applicable}), recommended examples, reproducibility envelope (model, seed, doctrine_fingerprint, prompt_template_fingerprint), persistence_status with shareable run_id/badge_url/review_url. Those two URLs 404 until the run's owner publishes it: runs are private by default. Read `public_review` in the response before embedding either one. WHEN TO CALL: the user wants a governance audit, readiness score, or production_ready badge on an agent/workflow they just built or changed. WHEN NOT TO CALL: non-agentic plumbing (math utilities, type aliases, event-loop helpers, single-shot request/response handlers) returns tier=not_applicable with score=null/grade=null, that's not a failure, the doctrine simply doesn't grade non-agentic code, and architect.certify will refuse with not_agentic_component. Submit the OWNING agentic workflow instead. BEHAVIOR: long-running LLM call (~60-180s typical at high reasoning effort, single-pass; server-side budget 6 min). Mints run_id at t=0; first notifications/progress event carries run_id as recovery handle; keepalive every 30s. Persists ValidationRun + UserValidationRun + AIValidationRunLog + LLMUsageLog atomically; on rollback, badge/review URLs are stripped. Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan. Data at rest in the UK; OpenAI (US) processing (no-training); prompt-injection in code is inert. INPUTS: send FULL file contents verbatim as `implementation_context` (NO truncation, NO `...` placeholders, NO comment removal, the architect treats your `...` as literal code and hallucinates bugs that don't exist). If too large, split into MULTIPLE calls scoped by file/module; never truncate one call. Pass repository="<name>" to group runs into a project trend. Pass private_session=true to skip the stored run (persistence + recovery disabled); operational security + cost logs are still kept. focus_area narrows scope; unmatched focus_area fails explicitly rather than silently widening. PAYLOAD COMPLETENESS (load-bearing if you intend to architect.certify this run): the validate first-pass is permissive, it scores on doctrine alignment + structural patterns visible in the submitted code. Cert's adversarial second-pass is rigorous: it scores on cert-payload-completeness as well as code correctness. A run that scores 100/A at validate can cert-reject pre-LLM with `payload_incomplete` when imported modules' surfaces aren't visible. To validate with INTENT TO CERT, also bundle verbatim public-surface stubs for every imported module: `from sqlalchemy.exc import SQLAlchemyError` → include a stub class; `from app.db import models` → include a `class models:` namespace stub with the columns/methods the code references; module-level imports of `dataclass`, `Literal`, `json`, `datetime`, `timezone` MUST also be in the payload (cert correctly catches when they're omitted, the module would NameError on import as submitted). 'Submit Like Production': the payload should be the code as it would actually run. TWO COMPLETENESS AXES. (1) IMPORTS: stub the public surface of every dependency (above). (2) ENFORCEMENT BRANCHES: the code under cert itself (approval gates, policy checks, recovery paths) must be the REAL logic, fully written. A placeholder body (`# ... execute approved action ...`, `pass # TODO`, a bare `...`) is graded as a MISSING control, not shorthand; cert scores what would actually run. Never sketch the agent you are certifying. Empirically reconfirmed PR #157 iter8 → iter9 cert downgrades. SCORE VARIANCE DISCLOSURE (anomaly #10: empirically documented): validate scores are POINT ESTIMATES with an observed empirical variance band of ~20-67 pts on BYTE-IDENTICAL input. Runs against the same repository, same code, same deterministic seed (the seed is derived from input: same input → same seed) can produce materially different scores AND different top-blocker rankings, because OpenAI's reasoning models at reasoning_effort=high are not strictly deterministic even with the seed parameter pinned. The `reproducibility_mode='best_effort'` field on every response is the platform's honest disclosure of this property. For decisions where stability matters more than speed, call `architect.validate_consensus` (N=3-5 aggregated, median verdict + per-principle stability metrics) instead: collapses the variance, surfaces unstable principles explicitly. A single validate run is a single roll; consensus is the right tool when one score isn't enough. ITERATION LOOP: repository keying. Pass the SAME `repository` value across calls to chain iteration rounds; the validator auto-resolves the most recent prior run on (user, repository, scope) as `prior_run_baseline` and the LLM grades the new submission with iteration context (per-principle severity deltas surface in the response). Changing the `repository` string between calls, even subtly with an `iter-2` suffix, silently severs the chain and yields a fresh blind first-shot. Round numbering belongs in `task` or commit messages, never in `repository`. See the `architect-validation-orchestration` skill in the agent-asset pack for the full validate → consensus → certify sequence. VERIFICATION LAYERS (the two-layer doctrine this platform practices on itself): validate verifies DOCTRINE ALIGNMENT against the 10-principle Blueprint, design patterns, hand-off explicitness, operational-state inspectability, race/blocker handling at the architectural level. validate does NOT guarantee runtime correctness. cert verifies PAYLOAD COMPLETENESS and runs an adversarial second pass over the submitted code: catches production_blockers the first pass missed, name-errors on import, missing module surfaces, etc. cert does NOT verify runtime correctness either. Passing validate is a NECESSARY condition for production_ready, not a sufficient one. Runtime correctness (does this actually execute and behave?) is verified at the THIRD layer: your tests, types, walks. The platform's own recursive-integrity practice: every PR runs validate against its own primitives, then cert. Real bugs surfaced via this practice in PR #157, NULL-UUID false-positive (iter3) and tie-breaker mismatch (iter5), that 25 unit tests had missed. Two-layer verification is the discipline, not 'either/or'. TYPED FAILURES: timed_out, rate_limited, dependency_unavailable, schema_mismatch (each carries retryable + next_action). NEXT STEP: if tier=production_ready (A or B grade), the response carries certification_status='not_evaluated', call architect.certify(run_id, code) to mint the certified production_ready badge (separate ~60-150s adversarial review, eligibility-gated). See Payload Completeness above for the common pre-cert pitfall.
Open world
Input schema
{'type': 'object', 'title': 'validate_agent_architectureArguments', 'required': ['implementation_context'], 'properties': {'task': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Task', 'default': None, 'description': 'What the agent or workflow is trying to accomplish. Adds evaluation context.'}, 'files': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Files', 'default': None, 'description': 'List of file paths relevant to the implementation context.'}, 'goals': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Goals', 'default': None, 'description': "Specific safety or quality goals to evaluate against (e.g. 'prevent irreversible actions', 'explicit approvals')."}, 'language': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Language', 'default': None, 'description': "Programming language of the code being evaluated (e.g. 'python', 'typescript')."}, 'focus_area': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Focus Area', 'default': None, 'description': "Narrow the evaluation to a specific principle cluster or slug (e.g. 'delegation', 'visibility', 'establish-trust-through-inspectability')."}, 'repository': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Repository', 'default': None, 'description': 'Iteration key. SAME value across calls auto-resolves the most recent prior run as `prior_run_baseline` for iteration-aware grading (per-principle severity deltas, regressions/improvements). CHANGING the value (even subtly with an `iter-2` suffix) silently severs the chain and yields a fresh blind first-shot. Round numbering belongs in `task`, not here. Empirical evidence of why anchoring matters: PR #157 iter1 33/F vs iter2 100/A on byte-identical baseline-race primitives (+67 spread); invoice-payment-manager #158 38/F vs #159 74/C (+36 spread), same code, score variance from non-deterministic LLM at reasoning_effort=high; the baseline anchor collapses this onto a stable arc.'}, 'session_id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Session Id', 'default': None, 'description': "Optional Governed Session to attach this run to (GEP-M2). Must reference a session YOU own (list via me.sessions; sessions are created in the web app at /app/sessions): foreign ids are refused before any model call. The run then appears on the session's timeline alongside the other lenses. With private_session=true no run is stored so nothing attaches, but the ownership check still runs FIRST: a session id you don't own fails the call either way."}, 'example_limit': {'type': 'integer', 'title': 'Example Limit', 'default': 3, 'minimum': 1, 'description': 'Maximum number of curated examples to include in recommendations.'}, 'private_session': {'type': 'boolean', 'title': 'Private Session', 'default': False, 'description': "Set to true to skip the stored run AND prior-run anchoring AND run_id recovery for this call. Operational security and cost logs are still kept, per the Privacy Policy. The request is also not persisted in the model provider's response store; the provider's abuse-monitoring retention still applies. Use for private one-shots that don't participate in the iteration arc. Default false."}, 'implementation_context': {'type': 'string', 'title': 'Implementation Context', 'description': "The artifact under review. SEND FULL FILE CONTENTS VERBATIM: the architect cites per-line evidence (identifiers, branch ordering, structural choices); any compression destroys evidence and produces hallucinated findings on code that isn't there. CONCRETE DON'TS: do NOT replace docstrings/comments with `...`; do NOT condense multi-line statements; do NOT replace dict/set comprehensions with `{...}`; do NOT remove explanatory comments to save tokens. If the file is large, split into MULTIPLE architect.validate calls scoped by file/module: never truncate one call. Architecture summaries (high-level prose) accepted ONLY for greenfield (no code yet); never as a substitute for code that already exists."}}}
Output schema
{'type': 'object', 'title': 'validate_agent_architectureDictOutput', 'additionalProperties': True}
architect.validate_consensus
Validate Agent Architecture (Consensus Mode)
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).
Open world
Input schema
{'type': 'object', 'title': 'validate_consensus_agent_architectureArguments', 'required': ['implementation_context'], 'properties': {'n': {'type': 'integer', 'title': 'N', 'default': 3, 'maximum': 10, 'minimum': 2, 'description': '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': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Task', 'default': None, 'description': 'What the agent or workflow is trying to accomplish.'}, 'files': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Files', 'default': None, 'description': 'List of file paths relevant to the implementation.'}, 'goals': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Goals', 'default': None, 'description': 'Specific safety or quality goals to evaluate against.'}, 'language': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Language', 'default': None, 'description': "Programming language of the code (e.g. 'python')."}, 'focus_area': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Focus Area', 'default': None, 'description': 'Optional: narrow the review to a principle cluster or slug.'}, 'repository': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Repository', 'default': None, 'description': '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': {'type': 'integer', 'title': 'Example Limit', 'default': 3, 'minimum': 1, 'description': 'Max curated examples per child run.'}, 'implementation_context': {'type': 'string', 'title': 'Implementation Context', 'description': "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
{'type': 'object', 'title': 'validate_consensus_agent_architectureDictOutput', 'additionalProperties': True}
assets.list
List Agent Assets
Public: list downloadable doctrine and agent asset artifacts (skill packs, rule packs, MCP setup snippets) the user can drop into their AI coding tool to import the Blueprint as native skill/rule files. Returns a list of assets with name, format (one of: zip / md / markdown / mdc / json / toml / text, the full vocabulary), pack_version, download_url, and platform target (Claude Code, Cursor, Codex, Gemini, Qwen). The response also carries `count` (length of `assets`) for symmetry with principles.list / clusters.list / guides.list. WHEN TO CALL: the user asks how to bring the Blueprint into their coding agent, or wants to install it as a local skill/rule file. WHEN NOT TO CALL: for the live MCP tools themselves, those are already available through this server. For doctrine content, prefer principles.list/get and guides.list/get. BEHAVIOR: read-only, idempotent, no auth required. Asset artefacts are regenerated on every deploy from the canonical doctrine.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'list_agent_assetsArguments', 'properties': {}}
Output schema
{'type': 'object', 'title': 'list_agent_assetsDictOutput', 'additionalProperties': True}
clusters.get
Get Cluster
Get one principle cluster by stable slug. Returns the cluster definition, shared rationale, and the full set of member principles (slug + title) so the caller can pivot into principles.get without a second list call. WHEN TO CALL: the user has already named a specific cluster (e.g. 'delegation', 'visibility', 'trust', 'orchestration') OR you have a slug from a prior clusters.list / principles.list response and need its full definition + member principles. The response embeds member principle slugs + titles already, so DO NOT loop principles.get over each member to get a cluster overview: read the response. WHEN NOT TO CALL: the user is describing a topic, failure mode, or keyword in natural language (call principles.search instead); the user wants to discover which clusters exist (call clusters.list); the user wants the definition of one specific principle (call principles.get directly). Idempotent + cacheable per slug. Returns 404-shaped error_payload on unknown slug: the slug must match exactly the value emitted by clusters.list, with no normalization.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_clusterArguments', 'required': ['slug'], 'properties': {'slug': {'type': 'string', 'title': 'Slug', 'description': "Stable slug of the principle cluster (e.g. 'delegation', 'visibility', 'trust', 'orchestration')."}}}
Output schema
{'type': 'object', 'title': 'get_clusterDictOutput', 'additionalProperties': True}
clusters.list
List Clusters
List all principle clusters with their stable slugs and linked principle titles. Use this to discover which clusters exist before drilling in with clusters.get or filtering principles.list by cluster. Prefer clusters.get when you already know the cluster slug and need full detail.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'list_clustersArguments', 'properties': {}}
Output schema
{'type': 'object', 'title': 'list_clustersDictOutput', 'additionalProperties': True}
design.validate
Validate Experience Design
Pro/Teams: first-pass surface-craft review of a FRONTEND artefact (component, screen, or flow) against the 8 laws of the Experience Design Blueprint. The surface-craft companion to architect.validate: where architect.validate scores agentic ARCHITECTURE against the 10 agentic principles, design.validate scores the PERCEPTIBLE SURFACE, what the user sees, taps, scans, and remembers (Jakob's familiarity, Hick's choice load, Fitts's targets + the accessibility floor, Miller's working-memory budget, Aesthetic-Usability, Peak-End, Tesler's irreducible complexity, the Mental-Model gap). ON CLIENT TIMEOUT: DO NOT RETRY. Long-running LLM call (~60-180s at high reasoning effort, single-pass). The server mints a run_id, emits it in the FIRST progress event at t=0s (before the LLM call), and persists the run: so on a client timeout, capture that run_id and call me.validation_history(run_id='<that-id>') to fetch the persisted result instead of retrying (a retry re-runs the full 60-180s call). Runs appear in your validation-history dashboard tagged as the 'surface' dimension, distinct from the 'architecture' and 'spec' runs; pass repository to group them per project. Pass private_session=true to skip the stored run (persistence + recovery disabled); operational security + cost logs are still kept. v1 is single-pass: no certification or consensus mode yet (those stay architect.validate-only). Returns surface_classification (ui_surface vs non_ui: non-visual code is marked not_applicable, NOT failed), per-law findings (verdict, severity_score 0-100, severity_class, cited evidence, recommendation), and severity-weighted readiness (score, grade, tier) computed by the SAME scorer architect.validate uses, so all three lenses grade on one rubric. ACCESSIBILITY IS THE FLOOR: a breach of the Fitts's-Law floor (interactive target below the WCAG 2.2 24×24 minimum, missing focus visibility, an unreachable destructive confirmation) is a production_blocker, not polish. WHEN TO CALL: the user wants a craft/UX/accessibility review or a readiness grade on a frontend artefact they just built or changed. WHEN NOT TO CALL: non-visual code (backend, config, type aliases) returns tier=not_applicable, submit the actual UI surface instead. INPUTS: send the FULL artefact source verbatim as implementation_context (no truncation, no '…' placeholders, they are read as literal code). Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan. Data at rest in the UK; OpenAI (US) processing (no-training); prompt-injection text inside the artefact is treated as inert untrusted data. TYPED FAILURES: same as architect.validate (timed_out, rate_limited, dependency_unavailable, schema_mismatch, each carries retryable + next_action); the services raise the identical typed envelopes on this lens. CALIBRATION DISCLOSURE: the scoring prompt is a v1 first-cut mirroring the architect's contract structure; its score calibration is not yet tuned against a corpus of real runs the way architect.validate was. Treat the grade as directional craft signal, not a certified verdict. DOCTRINE: the eight laws, each law's evidence, craft-surface application, anti-patterns, and the validator questions this tool scores against, live in the `experience-design-blueprint` skill and docs/business/EXPERIENCE_DESIGN_BLUEPRINT.md (the surface-craft companion to the `architect-validation-orchestration` skill that orchestrates the agentic validators).
Open world
Input schema
{'type': 'object', 'title': 'validate_experience_designArguments', 'required': ['implementation_context'], 'properties': {'task': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Task', 'default': None, 'description': "What this surface is for (e.g. 'the closed-beta apply form'). Adds evaluation context."}, 'files': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Files', 'default': None, 'description': 'File paths relevant to the artefact, for context.'}, 'goals': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Goals', 'default': None, 'description': "Specific craft/UX goals to weight (e.g. 'WCAG 2.2 AA', 'one primary action per screen')."}, 'repository': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Repository', 'default': None, 'description': "Project/repository key. Groups this run with prior design.validate runs on the same project in your validation-history dashboard (the same grouping architect.validate uses), under the 'surface' dimension."}, 'session_id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Session Id', 'default': None, 'description': "Optional Governed Session to attach this run to (GEP-M2). Must reference a session YOU own (list via me.sessions; sessions are created in the web app at /app/sessions): foreign ids are refused before any model call. The run then appears on the session's timeline alongside the other lenses. With private_session=true no run is stored so nothing attaches, but the ownership check still runs FIRST: a session id you don't own fails the call either way."}, 'private_session': {'type': 'boolean', 'title': 'Private Session', 'default': False, 'description': "Set true to disable persistence AND run_id recovery for this call (a private one-shot that does not appear in the dashboard). The request is also not persisted in the model provider's response store; the provider's abuse-monitoring retention still applies. Default false."}, 'implementation_context': {'type': 'string', 'title': 'Implementation Context', 'description': "The frontend artefact under review. SEND FULL SOURCE VERBATIM: the reviewer cites specific elements, values, and structure; any compression destroys evidence and produces findings on code that isn't there. Do NOT replace markup/styles with '…'; do NOT condense multi-line JSX/CSS. If large, split into MULTIPLE calls scoped by component: never truncate one call."}}}
Output schema
{'type': 'object', 'title': 'validate_experience_designDictOutput', 'additionalProperties': True}
examples.get
Get Example
Get one curated example by stable slug. Returns title, summary, source-code links, principle coverage (the principle slugs the example demonstrates), difficulty, library/framework, and implementation notes. Use this when you already have the slug from examples.search, a principles.get response, or a guide cross-link; prefer examples.search when filtering by topic / principle / difficulty / library; prefer guides.get when the caller wants a full walkthrough rather than a single reference example. Returns error_payload on unknown slug. Some entries are first-party agentic patterns (entry_kind='pattern') rather than upstream cookbook examples: those additionally return pattern_slug, pattern_family, when_to_use, doctrine_relations (each {principle_id, relation, note, code_ref} where relation is one of structural / default_gap / depends), prior_art, and doctrine_binding_basis. Every other row omits those seven keys.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_exampleArguments', 'required': ['slug'], 'properties': {'slug': {'type': 'string', 'title': 'Slug', 'description': "Stable slug of the curated example (e.g. 'agents-building-blocks-5-control')."}}}
Output schema
{'type': 'object', 'title': 'get_exampleDictOutput', 'additionalProperties': True}
examples.search
Search Examples
Search curated examples by free-text query, ranked by relevance, with optional filters: principle_ids (only examples covering those principles), difficulty (beginner/intermediate/advanced), library (e.g. 'langgraph', 'openai'). Returns each match's slug, title, summary, principle coverage, difficulty, library, and source-code link: slug is the handle examples.get hydrates. Default limit 5, capped server-side. Use this when the user describes a use case, technique, or library and wants matching examples; prefer examples.get when you already have the slug; prefer guides.search when the user wants a full walkthrough; prefer principles.search when the user wants doctrine guidance, not an implementation. Results may include first-party agentic patterns (entry_kind='pattern') carrying an explicit doctrine binding, see examples.get. Filter to one family with pattern_family, which implies patterns only. Patterns take a small relevance preference over generic examples when otherwise equally relevant; that preference never outranks a genuine failing-principle match, and a pattern whose only relation to a failing principle is 'depends' receives no such match at all.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'search_examplesArguments', 'required': ['query'], 'properties': {'limit': {'type': 'integer', 'title': 'Limit', 'default': 5, 'minimum': 1, 'description': 'Maximum number of results to return. Capped at server maximum.'}, 'query': {'type': 'string', 'title': 'Query', 'description': 'Free-text search query matched against example title, summary, and metadata.'}, 'library': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Library', 'default': None, 'description': "Filter by library or framework name (e.g. 'langgraph', 'openai', 'anthropic')."}, 'difficulty': {'anyOf': [{'enum': ['beginner', 'intermediate', 'advanced'], 'type': 'string'}, {'type': 'null'}], 'title': 'Difficulty', 'default': None, 'description': 'Filter by difficulty level.'}, 'principle_ids': {'anyOf': [{'type': 'array', 'items': {'type': 'integer'}}, {'type': 'null'}], 'title': 'Principle Ids', 'default': None, 'description': 'Filter to examples that cover these principle IDs.'}, 'pattern_family': {'anyOf': [{'enum': ['tools-actions', 'reasoning-reflection', 'retrieval', 'memory', 'sampling-search', 'multi-agent', 'safety-routing', 'specialty'], 'type': 'string'}, {'type': 'null'}], 'title': 'Pattern Family', 'default': None, 'description': 'Filter to one agentic-pattern family. Implies patterns only, since no upstream cookbook example carries a family.'}}}
Output schema
{'type': 'object', 'title': 'search_examplesDictOutput', 'additionalProperties': True}
guides.get
Get Application Guide
Get a full application guide by its stable slug (e.g. 'security-application', 'observable-evaluation'). Returns sections, action items, and linked principles. Use this when you already have the guide slug from guides.list or guides.search. Prefer guides.search when the user describes a topic in natural language; prefer guides.list when you need the full inventory.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_application_guideArguments', 'required': ['slug'], 'properties': {'slug': {'type': 'string', 'title': 'Slug', 'description': "Stable slug of the application guide (e.g. 'security-application', 'observable-evaluation')."}}}
Output schema
{'type': 'object', 'title': 'get_application_guideDictOutput', 'additionalProperties': True}
guides.list
List Application Guides
List application guides that show how Blueprint principles apply to engineering challenges (security, evaluation, observability, etc.). Use this to discover which guides exist before drilling in. Prefer guides.search when the user describes a topic or failure mode in natural language. Prefer guides.get when you already know the guide slug and need full detail.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'list_application_guidesArguments', 'properties': {}}
Output schema
{'type': 'object', 'title': 'list_application_guidesDictOutput', 'additionalProperties': True}
guides.search
Search Application Guides
Search application guides by free-text query, matched against section answers and action items. Use this when the user describes an engineering challenge (security review, evaluation harness, observability) and wants matching guides. Prefer guides.get when you already have the guide slug; prefer guides.list when you need the full inventory.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'search_application_guidesArguments', 'required': ['query'], 'properties': {'limit': {'type': 'integer', 'title': 'Limit', 'default': 5, 'minimum': 1, 'description': 'Maximum number of results to return. Capped at server maximum.'}, 'query': {'type': 'string', 'title': 'Query', 'description': 'Free-text search query matched against all guide content including section answers and action items.'}}}
Output schema
{'type': 'object', 'title': 'search_application_guidesDictOutput', 'additionalProperties': True}
handoffs.agency
Request Agency Handoff
Authenticated: submit an agency engagement enquiry on behalf of the caller for a founder-led discovery call. Persists an AgencyHandoff row routed to the agency inbox; the user is contacted by the team for a scoped proposal. Engagement scopes: workflow sprint (rapid agentic workflow implementation), proof-of-concept (validate a specific agent design in a bounded timeframe), pilot support (co-design and validate a production-ready pilot), advisory (ongoing architectural guidance across a product team). WHEN TO CALL: the user has identified a paid hands-on expert engagement need beyond self-service learning, and explicitly asks to talk to the team or book a discovery call. ALWAYS confirm with the user before firing: this creates a sales-visible record. WHEN NOT TO CALL: for free training / partnerships discussion (use handoffs.partnership); for support / billing / access (use handoffs.operator); proactively or as a sales push. BEHAVIOR: write-only, single insert, side-effecting. Auth: Bearer <token> (Firebase ID token, any plan). Data at rest in the UK. Response confirms the ticket id + scope so the user can reference it.
Open world
Input schema
{'type': 'object', 'title': 'request_agency_handoffArguments', 'required': ['reason'], 'properties': {'role': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Role', 'default': None, 'description': 'Role or title of the person submitting the agency inquiry.'}, 'locale': {'enum': ['en', 'it'], 'type': 'string', 'title': 'Locale', 'default': 'en', 'description': 'Response locale for the acknowledgment.'}, 'reason': {'type': 'string', 'title': 'Reason', 'description': 'Description of the engagement need: workflow sprint, proof-of-concept, pilot support, or advisory.'}, 'company': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Company', 'default': None, 'description': 'Company or team name submitting the agency inquiry.'}, 'website': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Website', 'default': None, 'description': 'Website or relevant URL for the team or project.'}, 'agent_name': {'type': 'string', 'title': 'Agent Name', 'default': 'mcp-client', 'description': 'Name of the agent or client triggering the handoff.'}, 'support_type': {'anyOf': [{'enum': ['sprint', 'poc', 'pilot', 'advisory'], 'type': 'string'}, {'type': 'null'}], 'title': 'Support Type', 'default': None, 'description': 'Type of support needed.'}, 'trace_summary': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Trace Summary', 'default': None, 'description': 'Optional agent trace summary for operator context.'}, 'agent_platform': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Agent Platform', 'default': None, 'description': 'Platform or runtime the agent is running on.'}, 'workflow_stage': {'anyOf': [{'enum': ['exploring', 'designing', 'implementing', 'reviewing', 'shipping'], 'type': 'string'}, {'type': 'null'}], 'title': 'Workflow Stage', 'default': None, 'description': 'Current workflow stage.'}}}
Output schema
{'type': 'object', 'title': 'request_agency_handoffDictOutput', 'additionalProperties': True}
handoffs.operator
Request Operator Handoff
Authenticated: creates a support handoff record when an agent needs human review, account-specific escalation, or operator follow-up that cannot be resolved with the read-only doctrine tools. Persists a SupportHandoff row (reason, topic, page_url, agent_name, agent_platform, trace_summary, user_email) routed to the support inbox; user is contacted by the team. WHEN TO CALL: user explicitly asks for human help, hits a billing/access issue, or the agent has tried the doctrine tools and the user still needs a human. ALWAYS confirm with the user before firing: this creates a human-visible ticket. WHEN NOT TO CALL: proactively, silently, or to log debugging traces (use diagnostic logs instead); for partnerships/agency enquiries (use handoffs.partnership / handoffs.agency); for content questions answerable by principles.search / guides.search. BEHAVIOR: write-only, single insert, side-effecting (creates a ticket the team will see). Auth: Bearer <token> (any plan). Data at rest in the UK. Response confirms ticket id + topic so the user can reference it.
Open world
Input schema
{'type': 'object', 'title': 'request_operator_handoffArguments', 'required': ['reason'], 'properties': {'topic': {'type': 'string', 'title': 'Topic', 'default': 'agent', 'description': "Topic category for routing (e.g. 'agent', 'billing', 'access', 'general')."}, 'locale': {'enum': ['en', 'it'], 'type': 'string', 'title': 'Locale', 'default': 'en', 'description': 'Response locale for the handoff acknowledgment.'}, 'reason': {'type': 'string', 'title': 'Reason', 'description': 'Clear description of why a human operator review is needed.'}, 'page_url': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Page Url', 'default': None, 'description': 'URL of the page or context where the handoff was triggered.'}, 'agent_name': {'type': 'string', 'title': 'Agent Name', 'default': 'mcp-client', 'description': 'Name of the agent or client triggering the handoff.'}, 'trace_summary': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Trace Summary', 'default': None, 'description': "Optional summary of the agent's recent actions or trace for operator context."}, 'agent_platform': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Agent Platform', 'default': None, 'description': "Platform or runtime the agent is running on (e.g. 'claude-code', 'cursor', 'copilot')."}}}
Output schema
{'type': 'object', 'title': 'request_operator_handoffDictOutput', 'additionalProperties': True}
handoffs.partnership
Request Partnership Handoff
Authenticated: creates a partnerships handoff record for design-partner, ecosystem, training, or advisory conversations needing human review. Persists a PartnershipHandoff row routed to the partnerships inbox; the user is contacted by the team. WHEN TO CALL: user explicitly wants to engage as a design partner, co-marketing/training partner, or evaluate the Blueprint for their org's training programme. ALWAYS confirm with the user before firing: this creates a human-visible partnerships ticket. WHEN NOT TO CALL: for general support / billing / access issues (use handoffs.operator); for paid-engagement enquiries (use handoffs.agency); proactively or as a sales prompt, only when the user has explicitly asked. BEHAVIOR: write-only, single insert, side-effecting (creates a ticket). Auth: Bearer <token> (any plan). Data at rest in the UK. Response confirms the ticket id + audience so the user can reference it.
Open world
Input schema
{'type': 'object', 'title': 'request_partnership_handoffArguments', 'required': ['reason'], 'properties': {'role': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Role', 'default': None, 'description': 'Role or title of the person submitting the partnership inquiry.'}, 'topic': {'enum': ['ecosystem', 'design-partner', 'training', 'advisory'], 'type': 'string', 'title': 'Topic', 'default': 'ecosystem', 'description': 'Partnership topic category.'}, 'locale': {'enum': ['en', 'it'], 'type': 'string', 'title': 'Locale', 'default': 'en', 'description': 'Response locale for the handoff acknowledgment.'}, 'reason': {'type': 'string', 'title': 'Reason', 'description': 'Clear description of the partnership opportunity or inquiry.'}, 'website': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Website', 'default': None, 'description': 'Website of the organization for additional context.'}, 'agent_name': {'type': 'string', 'title': 'Agent Name', 'default': 'mcp-client', 'description': 'Name of the agent or client triggering the handoff.'}, 'organization': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Organization', 'default': None, 'description': 'Name of the organization or company making the partnership inquiry.'}, 'trace_summary': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Trace Summary', 'default': None, 'description': 'Optional agent trace summary for operator context.'}, 'agent_platform': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Agent Platform', 'default': None, 'description': 'Platform or runtime the agent is running on.'}}}
Output schema
{'type': 'object', 'title': 'request_partnership_handoffDictOutput', 'additionalProperties': True}
me.add_evidence
Add Evidence Note
Authenticated: append a free-text evidence note to a specific stage in the caller's active course. Notes record concrete implementation observations, decisions, or artefacts that demonstrate progress through a Blueprint principle (e.g. how a delegation boundary was implemented, what approval flow was chosen and why). Persisted as UserStageEvidence rows scoped to (user_id, course_slug, stage_slug). WHEN TO CALL: AFTER the user has articulated something concrete they have built, observed, or decided, not to capture intent or speculation. Pair with me.coaching_context to close evidence gaps. WHEN NOT TO CALL: to log every conversation turn; to record planning, ideas, or todos; on behalf of another user; without the user's awareness (they should know their progress is being recorded). BEHAVIOR: write-only, single insert. Auth: Bearer <token> (Firebase ID token, any plan). Data at rest in the UK. Notes are visible only to the owning user and are surfaced on me.learning_path / me.coaching_context. Confirms the stage_slug + course_slug pair in the response so the user can see which stage was credited.
Input schema
{'type': 'object', 'title': 'add_evidence_noteArguments', 'required': ['course_slug', 'stage_id', 'note'], 'properties': {'note': {'type': 'string', 'title': 'Note', 'description': 'Evidence note to append to the delegation boundary notes for this stage.'}, 'stage_id': {'type': 'string', 'title': 'Stage Id', 'description': 'ID of the stage to append the evidence note to.'}, 'course_slug': {'type': 'string', 'title': 'Course Slug', 'description': "Slug of the course the stage belongs to (e.g. 'agentic-fundamentals')."}}}
Output schema
{'type': 'object', 'title': 'add_evidence_noteDictOutput', 'additionalProperties': True}
me.await_steer
Wait for the Next AIDB Studio Steer (long-poll)
Pro/Teams. BLOCK until the session owner posts the next `steer` event to a Governed Session from AIDB Studio, then return it. DELIVERY GUARANTEE: the durable cursor read against the session log is authoritative (at-least-once: a lost response is safely re-issuable with the same cursor, and timed_out is only returned after a final confirming read). The in-between wake-up is a best-effort in-process push: usually sub-second, but a steer is never lost if a wake-up is missed; the confirming read catches it. See the after_event_id and timeout_s parameter descriptions for the semantics. THE LOOP: finish a task -> post me.session_event handoff -> call me.await_steer -> on a steer, FIRST post me.session_event event_type=ack ('Started: <steer gist>'), then execute, then handoff, then call me.await_steer again; on `timed_out`, call again with the returned after_event_id. REQUIRES team mode on the session (toggled by the owner in the web app); owner-scoped, so foreign session ids read as not found. Read-only: this tool never writes events. REJECTION CODES (invalid_request): 'Session not found.' (not yours, or no such id); 'Team mode is off for this session.' (owner enables it on the session page). Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'await_steerArguments', 'required': ['session_id'], 'properties': {'timeout_s': {'type': 'integer', 'title': 'Timeout S', 'default': 45, 'maximum': 240, 'minimum': 5, 'description': 'Seconds to wait before returning timed_out. Clamped to 5-240, DEFAULT 45: safe under Claude Code\'s 60-second first-response-byte timer for HTTP servers. Longer waits require the per-server timeout raised in the MCP client config (e.g. "timeout": 300000 in .mcp.json).'}, 'session_id': {'type': 'integer', 'title': 'Session Id', 'description': 'The Governed Session to watch. Must be YOURS and have team_agents enabled; list sessions via me.sessions.'}, 'after_event_id': {'type': 'integer', 'title': 'After Event Id', 'default': 0, 'minimum': 0, 'description': 'Cursor: highest session-event id you have already seen (0 = deliver any existing steer). Pass the value from your previous await_steer result or me.sessions read. Non-destructive at-least-once delivery: re-calling with the same cursor returns the same steers again, so a lost response never loses a steer.'}}}
Output schema
{'type': 'object', 'title': 'await_steerDictOutput', 'additionalProperties': True}
me.coaching_context
Get My Coaching Context
Authenticated: returns stages in the caller's active course where recorded evidence is thin relative to the stage's principle requirements. Each thin stage carries the missing principle slugs + a short diagnostic so the caller can suggest the user record concrete evidence. WHEN TO CALL: when the user asks 'what should I work on next' or 'what's weak in my Blueprint progress'; before suggesting which guide/example to consult. Pair with me.add_evidence to close gaps. WHEN NOT TO CALL: to lecture the user on principles they have already satisfied; on every conversation turn (state changes only when evidence is added). BEHAVIOR: read-only, idempotent. Auth: Bearer <token> (any plan). Returns thin_stages list with stage slug, course slug, missing principles, evidence_count, and a coaching_note.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_my_coaching_contextArguments', 'properties': {}}
Output schema
{'type': 'object', 'title': 'get_my_coaching_contextDictOutput', 'additionalProperties': True}
me.learning_path
Get My Learning Path
Authenticated: returns the caller's Blueprint learning-path state: current course slug, stage progress, certification status (Foundation, Practitioner, Capstone), Capstone track eligibility flags, and the next recommended stage. WHEN TO CALL: the user asks 'where am I', 'what's next', or 'am I Capstone-eligible'; before suggesting next-step coaching content. WHEN NOT TO CALL: as a heartbeat (state changes only when the user completes a stage); to read another user's progress. BEHAVIOR: read-only, idempotent. Auth: Bearer <token> (any plan, including basic). Returns user_email, course_slug, stages list with completion timestamps, certification block, and a next_stage hint.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_my_learning_pathArguments', 'properties': {}}
Output schema
{'type': 'object', 'title': 'get_my_learning_pathDictOutput', 'additionalProperties': True}
me.session_event
Post a Team Event to a Governed Session
Pro/Teams: append a TYPED TEAM EVENT to a Governed Session's timeline (GEP-M6). This is how the user's own harness makes trio work inspectable: handoffs between role lenses, pushbacks, plan previews, gates, and acks land as structured events next to the validation runs, so the session reads as a system, not a transcript. CHANNEL PROVENANCE: this MCP channel posts the AGENT-SIDE vocabulary only. `steer` events and actor `human` are AIDB Studio-originated by contract (the owner posts them from the AIDB Studio session surface) and are REFUSED here, so a timeline entry can never impersonate the human side of the loop. Every event posted here is durably stamped with its channel. REQUIRES team mode: the session must have team_agents enabled (toggled in the web app on the session page); posting to a standalone session is refused so non-team sessions stay byte-identical. Owner-scoped: foreign session ids read as not found. event_type: handoff | pushback | plan_preview | gate | ack. actor: pm | engineer | designer | system. Read events back via me.sessions(session_id=...). WHEN TO CALL: at every role handoff (who -> who, what was passed), when a role pushes back on another's output, when the PM's plan is previewed for the co-planning gate, and when a hard gate blocks on an irreversible side-effect. ack: the IDE agent confirms it STARTED working on a steer. Post it FIRST on receiving a steer (summary like 'Started: <steer gist>'), then execute, then post handoff with the result. WHEN NOT TO CALL: not a chat log: post decisions and transitions, not every message; never to record a steer (steers arrive FROM the AIDB Studio via me.await_steer). REJECTION CODES (invalid_request): 'Session not found.' (not yours, or no such id); 'Team mode is off for this session.' (owner enables it on the session page); 'This session has reached its event limit (500).' (the shared volume brake: start a new session for further team events); 'summary must not be blank.' (empty summaries are refused); steer/human posts are refused with a pointer to AIDB Studio. Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan.
Input schema
{'type': 'object', 'title': 'post_session_team_eventArguments', 'required': ['session_id', 'event_type', 'actor', 'summary'], 'properties': {'actor': {'enum': ['pm', 'engineer', 'designer', 'system'], 'type': 'string', 'title': 'Actor', 'description': 'Who acted: pm | engineer | designer | system (`human` is reserved for AIDB Studio)'}, 'summary': {'type': 'string', 'title': 'Summary', 'description': 'One-to-two sentence event summary (truncated to 500 chars): a decision or transition, not a chat message.'}, 'event_type': {'enum': ['handoff', 'pushback', 'plan_preview', 'gate', 'ack'], 'type': 'string', 'title': 'Event Type', 'description': 'handoff | pushback | plan_preview | gate | ack (ack = started working on a steer; `steer` itself is AIDB Studio-only and refused on this channel)'}, 'session_id': {'type': 'integer', 'title': 'Session Id', 'description': 'The Governed Session to post to. Must be YOURS and have team_agents enabled; list sessions via me.sessions.'}}}
Output schema
{'type': 'object', 'title': 'post_session_team_eventDictOutput', 'additionalProperties': True}
me.sessions
My Governed Sessions
Pro/Teams: list or inspect the authenticated user's Governed Sessions (GEP-M2): durable, owner-scoped containers that group validation runs across lenses (architect.validate → 'architecture', design.validate → 'surface', spec.validate → 'spec') into one timeline for one piece of work. Two modes: (1) No arguments returns every session (id, title, status, repo_url, spec_ref, team_agents, run_count, validators = the lenses seen), newest first. (2) `session_id=<id>` returns that session plus its run timeline (light rows; fetch full results per run via me.validation_history(run_id=...)) and, for team sessions, `events` = the typed team-event log posted via me.session_event. Attach new runs by passing `session_id` to architect.validate, design.validate, or spec.validate. Sessions are created and managed in the web app at /app/sessions. Read-only. Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_my_sessionsArguments', 'properties': {'session_id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Session Id', 'default': None, 'description': "Session id to inspect (returns the session + its run timeline). Owner-scoped: ids you don't own answer 'Session not found.'. Omit to list all your sessions."}}}
Output schema
{'type': 'object', 'title': 'get_my_sessionsDictOutput', 'additionalProperties': True}
me.validation_history
My Validation History (architecture + design + spec)
Pro/Teams: return the authenticated user's validation run history for all three lenses (architect.validate → validator='architecture', design.validate → validator='surface', spec.validate → validator='spec') with the Blueprint Readiness Score (0-100), letter grade (A-F), and tier (draft, emerging, production_ready). Each run carries a `validator` field naming its lens. Three lookup modes: (1) `run_id=<id>` returns a SINGLE run with the full persisted result_json; use this to RECOVER a result when your MCP client tool-call timed out before architect.validate, design.validate, or spec.validate returned. The run completes server-side and persists; the run_id is surfaced in the first progress notification of every validate call so you have the recovery handle even when your client gives up early. (2) `repository=<name>` returns the full per-run trend for that repository plus a regression diff between the latest two runs. (3) No arguments returns one summary per repository the user has validated, sorted by most recent. Use modes (2) or (3) BEFORE re-validating the same repository on either lens: they tell you which principles or laws regressed since the last run, so you can focus the new review on what is actually changing. Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_my_validation_historyArguments', 'properties': {'limit': {'type': 'integer', 'title': 'Limit', 'default': 10, 'minimum': 1, 'description': 'Maximum number of runs to return when scoped to a single repository. Capped at 50. Ignored when `run_id` is provided.'}, 'run_id': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Run Id', 'default': None, 'description': "Single-run lookup by run_id (UUID). Returns the persisted result_json verbatim: the same payload architect.validate would have returned if your client hadn't timed out. Use this to recover a result when your MCP tool-call closed before the server returned. Per-run authorisation: returns only runs owned by the calling user."}, 'repository': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Repository', 'default': None, 'description': 'Repository name or path to scope the history to. Pass the same value you would pass to architect.validate. Omit to get one summary per repository. Mutually exclusive with `run_id`: if both are passed, `run_id` wins.'}}}
Output schema
{'type': 'object', 'title': 'get_my_validation_historyDictOutput', 'additionalProperties': True}
principles.get
Get Principle
Get one doctrine entry by stable slug. The lens selects the doctrine: 'architecture' = one of the 10 agentic principles (default); 'surface' = one of the 8 experience-design laws; 'spec' = one of the 8 spec-quality laws. Returns id, title, cluster, definition, rationale, implications, and risk-if-violated (laws also carry their eponym and validator_questions). Use this when you already have the exact slug from principles.list; prefer principles.search when the user describes a topic or failure mode in natural language; prefer principles.list when you need every entry or every entry within a cluster. Returns error_payload on unknown slug for the lens.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'get_principleArguments', 'required': ['slug'], 'properties': {'lens': {'enum': ['architecture', 'surface', 'spec'], 'type': 'string', 'title': 'Lens', 'default': 'architecture', 'description': "Which public doctrine the slug belongs to: 'architecture' (10 principles, default), 'surface' (8 design laws), or 'spec' (8 spec laws)."}, 'slug': {'type': 'string', 'title': 'Slug', 'description': "Stable slug of the principle (e.g. 'establish-trust-through-inspectability')."}}}
Output schema
{'type': 'object', 'title': 'get_principleDictOutput', 'additionalProperties': True}
principles.list
List Principles
List Blueprint doctrine with stable slugs, titles, and clusters. The lens selects which of the three public doctrines: 'architecture' = the 10 agentic principles (default, the architect.validate rubric); 'surface' = the 8 experience-design laws (the design.validate rubric); 'spec' = the 8 spec-quality laws (the spec.validate rubric). Use this when you need the full inventory or want every entry in one cluster (pass cluster slug to filter). Prefer principles.search when the user describes a topic, failure mode, or keyword in natural language. Prefer principles.get when you already know the exact slug and need full detail.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'list_principlesArguments', 'properties': {'lens': {'enum': ['architecture', 'surface', 'spec'], 'type': 'string', 'title': 'Lens', 'default': 'architecture', 'description': "Which public doctrine: 'architecture' = the 10 agentic principles (default), 'surface' = the 8 experience-design laws, 'spec' = the 8 spec-quality laws."}, 'cluster': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Cluster', 'default': None, 'description': "Cluster slug to filter by (e.g. 'delegation', 'visibility', 'trust', 'orchestration'). Omit to return all principles."}}}
Output schema
{'type': 'object', 'title': 'list_principlesDictOutput', 'additionalProperties': True}
principles.search
Search Principles
Search Blueprint principles by free-text query and return the closest matches ranked by relevance. Use this to find principles related to a specific design challenge, failure mode, or keyword (e.g. 'reversibility', 'approval flow', 'delegation boundary'). Returns principle title, cluster, definition, rationale, and implementation heuristics. Prefer this over principles.list when you have a specific topic in mind rather than wanting all principles. The lens picks the doctrine searched: 'architecture' = the 10 agentic principles (default), 'surface' = the 8 experience-design laws, 'spec' = the 8 spec-quality laws, 'all' = all 26 (each result then names its lens). Laws also match on their eponym (e.g. 'Hick', 'Fitts').
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'search_principlesArguments', 'required': ['query'], 'properties': {'lens': {'enum': ['architecture', 'surface', 'spec', 'all'], 'type': 'string', 'title': 'Lens', 'default': 'architecture', 'description': "Which public doctrine to search: 'architecture' = the 10 agentic principles (default), 'surface' = the 8 experience-design laws, 'spec' = the 8 spec-quality laws, 'all' = all three."}, 'limit': {'type': 'integer', 'title': 'Limit', 'default': 5, 'minimum': 1, 'description': 'Maximum number of results to return. Capped at server maximum.'}, 'query': {'type': 'string', 'title': 'Query', 'description': 'Free-text search query matched against principle title, definition, rationale, and cluster.'}}}
Output schema
{'type': 'object', 'title': 'search_principlesDictOutput', 'additionalProperties': True}
signals.feedback
Submit Feedback
Public: records explicit free-text user feedback about the Blueprint, this tool surface, or a specific principle/example. Captures category (bug, doctrine_critique, missing_example, ergonomics, other), free-text body, and optional contact_email when permission_to_follow_up is true. WHEN TO CALL: ONLY when the user explicitly says they want to give feedback (e.g. 'can you log this as feedback', 'file this critique', 'send a bug report'). Use signals.report instead for value-moment metrics (rating validate's output 1-5). WHEN NOT TO CALL: proactively, silently, or to substitute for signals.report. Never harvest contact info without explicit permission_to_follow_up=true. BEHAVIOR: write-only, no auth required (open to all callers). Stores one feedback record, at rest in the UK. contact_email is stored ONLY when permission_to_follow_up=true, and that fact is confirmed back in the response so the user can see the privacy boundary. When permission_to_follow_up=true AND a valid contact_email is given, and only then, it also opens a support inbox item so a human can reply, and the free-text fields are sent to OpenAI for triage (severity and a short summary). The contact_email field is never part of that request, so keep personal data out of the free text. Separately, feedback linked to an account may appear, pseudonymised and shortened, in our weekly lead-intelligence extract to OpenAI (US). private_session does not apply to this tool: it runs only when the user chooses to give feedback.
Open world
Input schema
{'type': 'object', 'title': 'submit_feedbackArguments', 'properties': {'surface': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Surface', 'default': None, 'description': "Which Blueprint surface the feedback is about. Use 'mcp' if the session was via Claude Code or another MCP client. Use 'principles', 'examples', 'guides', 'coaching', or 'validation' based on what the user interacted with."}, 'task_type': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Task Type', 'default': None, 'description': "What the user was doing when they decided to give feedback. Use plain English: e.g. 'code-review', 'architecture-design', 'agent-setup', 'onboarding', 'validation'. Infer from context."}, 'what_helped': {'anyOf': [{'type': 'string', 'maxLength': 1000}, {'type': 'null'}], 'title': 'What Helped', 'default': None, 'description': "Ask the user: 'What was most helpful?' Record their answer verbatim or paraphrased in plain English. Max 1000 chars. No code snippets, no proprietary content."}, 'what_missing': {'anyOf': [{'type': 'string', 'maxLength': 1000}, {'type': 'null'}], 'title': 'What Missing', 'default': None, 'description': "Ask the user: 'What was missing or could be improved?' Record their answer verbatim or paraphrased. Max 1000 chars."}, 'contact_email': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Contact Email', 'default': None, 'description': 'Only ask for this if the user explicitly says they want a follow-up response. Never prompt for email unprompted. Only stored when permission_to_follow_up=true.'}, 'rating_clarity': {'anyOf': [{'type': 'integer', 'maximum': 5, 'minimum': 1}, {'type': 'null'}], 'title': 'Rating Clarity', 'default': None, 'description': "Ask the user: 'How clear was the Blueprint guidance? Rate 1–5.' 1 = very unclear, 5 = very clear. Only set if the user gives an explicit number."}, 'would_use_again': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'title': 'Would Use Again', 'default': None, 'description': "Ask the user: 'Would you use the Blueprint again for a similar task?' Set true/false based on their answer. Only set if they answer explicitly."}, 'rating_usefulness': {'anyOf': [{'type': 'integer', 'maximum': 5, 'minimum': 1}, {'type': 'null'}], 'title': 'Rating Usefulness', 'default': None, 'description': "Ask the user: 'How useful was the Blueprint for this task? Rate 1–5.' 1 = not useful, 5 = very useful. Only set if the user gives an explicit number."}, 'permission_to_follow_up': {'type': 'boolean', 'title': 'Permission To Follow Up', 'default': False, 'description': 'Set to true only if the user explicitly said they want a follow-up. Must be confirmed before storing contact_email.'}}}
Output schema
{'type': 'object', 'title': 'submit_feedbackDictOutput', 'additionalProperties': True}
signals.report
Report Value Event
Records a value moment (e.g. review_confidence, runtime_risk_found, workflow_clarity) after a successful validate run on any lens (architect.validate, design.validate, or spec.validate) or a doctrine session. Each event stores event_type, surface_used (mcp or the site section), perceived_value (1-5), and an optional short free-text note, brief_context (up to 500 characters). WHEN TO CALL: after architect.validate, design.validate, or spec.validate returns a clearly useful result AND the user has acknowledged the value (or you ask them "would you rate this 1-5?"). Each validator's response carries an explicit next_step instruction telling the agent to OFFER this call; surface that offer to the user. WHEN NOT TO CALL: silently or without the user's awareness; on every validate (only after a clear value moment); to capture intent or speculative value. If the user declines, do not retry within the same session. BEHAVIOR: write-only, single insert into ValueEvent. Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan. Data at rest in the UK. Do NOT include proprietary code, prompt content, or PII in brief_context: it is stored as written, surfaces in admin AI-visibility dashboards, and may appear, pseudonymised, in our weekly lead-intelligence extract to OpenAI (US). Expect a 1-line acknowledgment in the response; the feedback is then aggregated server-side.
Input schema
{'type': 'object', 'title': 'report_value_eventArguments', 'required': ['event_type'], 'properties': {'team_size': {'anyOf': [{'type': 'integer', 'minimum': 1}, {'type': 'null'}], 'title': 'Team Size', 'default': None, 'description': 'If the user mentions their team size during the session, record it here. Do not ask for it explicitly: only capture if volunteered.'}, 'event_type': {'enum': ['workflow_clarity', 'runtime_risk_found', 'agent_setup_success', 'onboarding_helped', 'review_confidence', 'research_time_saved', 'team_alignment', 'other'], 'type': 'string', 'title': 'Event Type', 'description': "Pick the type that best matches what just happened: 'review_confidence': a validator lens (architect.validate / design.validate / spec.validate) returned aligned; 'runtime_risk_found': a validate run found violations; 'workflow_clarity': principles/examples clarified a design decision; 'agent_setup_success': user successfully wired up an agent or MCP tool; 'onboarding_helped': user understood how to start using the Blueprint; 'research_time_saved': user found relevant doctrine faster than expected; 'team_alignment': Blueprint helped align a team on agentic design; 'other': use only if none of the above fit."}, 'surface_used': {'anyOf': [{'enum': ['mcp', 'for-agents', 'integrations', 'principles', 'examples', 'runtime-architecture', 'learn', 'certification', 'coaching', 'other'], 'type': 'string'}, {'type': 'null'}], 'title': 'Surface Used', 'default': None, 'description': "Where the value was experienced. Use 'mcp' when called from Claude Code, Cursor, Windsurf, or any MCP client. Use 'principles' if the user was browsing or searching principles. Use 'examples' if the user was reading implementation examples. Use 'for-agents' if the user came via the /for-agents page. Use 'learn' or 'certification' for course-related sessions."}, 'brief_context': {'anyOf': [{'type': 'string', 'maxLength': 500}, {'type': 'null'}], 'title': 'Brief Context', 'default': None, 'description': "1–2 plain-English sentences summarising what was helpful. Example: 'Validation identified a missing approval gate before email send.' No code snippets, no proprietary content, no user PII. Max 500 chars."}, 'workflow_stage': {'anyOf': [{'enum': ['exploring', 'designing', 'implementing', 'reviewing', 'shipping'], 'type': 'string'}, {'type': 'null'}], 'title': 'Workflow Stage', 'default': None, 'description': "Infer from what the user was doing: 'exploring': reading doctrine, browsing principles; 'designing': planning architecture or agent flows; 'implementing': writing or refactoring code; 'reviewing': running a validator lens on existing code, a surface, or a spec; 'shipping': preparing for production or deployment."}, 'perceived_value': {'anyOf': [{'type': 'integer', 'maximum': 5, 'minimum': 1}, {'type': 'null'}], 'title': 'Perceived Value', 'default': None, 'description': "Ask the user: 'On a scale of 1–5, how valuable was this session?' Map their answer directly: 1=low, 5=high. Do not guess: only set this if the user gave an explicit score."}, 'would_recommend': {'anyOf': [{'type': 'boolean'}, {'type': 'null'}], 'title': 'Would Recommend', 'default': None, 'description': "Ask the user: 'Would you recommend the Blueprint to a colleague?' Set true/false based on their answer. Only set if asked: do not assume."}}}
Output schema
{'type': 'object', 'title': 'report_value_eventDictOutput', 'additionalProperties': True}
spec.validate
Validate Specification Quality
Pro/Teams: first-pass specification-quality review of a WRITTEN SPEC (proposal, design doc, task breakdown, or an OpenSpec-style change bundle) against the 8 laws of the Spec Quality Blueprint. The what-to-build lens of the doctrine trio, applied BEFORE code exists: where architect.validate scores built agentic ARCHITECTURE and design.validate scores the rendered SURFACE, spec.validate scores the written intent the team will build from (outcome framing, scope boundary, testable acceptance, decision trail, handoff completeness, doctrine-upfront, task traceability, risk and reversibility). ON CLIENT TIMEOUT: DO NOT RETRY. Long-running LLM call (~60-180s at high reasoning effort, single-pass). The server mints a run_id, emits it in the FIRST progress event at t=0s (before the LLM call), and persists the run: so on a client timeout, capture that run_id and call me.validation_history(run_id='<that-id>') to fetch the persisted result instead of retrying (a retry re-runs the full 60-180s call). Runs appear in your validation-history dashboard tagged as the 'spec' dimension, distinct from the 'architecture' and 'surface' runs; pass repository to group them per project. Pass private_session=true to skip the stored run (persistence + recovery disabled); operational security + cost logs are still kept. v1 is single-pass: no certification or consensus mode yet (those stay architect.validate-only). Returns spec_classification (spec_document vs non_spec: source code or UI artefacts are marked not_applicable, NOT failed; submit those to architect.validate or design.validate instead), per-law findings (verdict, severity_score 0-100, severity_class, cited evidence, recommendation), and severity-weighted readiness (score, grade, tier) computed by the SAME scorer the other two lenses use, so all three grade on one rubric. TESTABILITY IS THE FLOOR: a load-bearing requirement with no observable acceptance signal, or an irreversible step with no named human gate, is a production_blocker, not polish. WHEN TO CALL: the user wants a governance/quality review or a readiness grade on a spec they are about to build from (proposal, requirements, task plan). WHEN NOT TO CALL: built code or a rendered surface, those return tier=not_applicable; use the sibling validators instead. INPUTS: send the FULL spec text verbatim as implementation_context (for an OpenSpec change, concatenate proposal.md + design.md + tasks.md + delta specs; no truncation, no '…' placeholders, they are read as literal content). Auth: sign-in required, with an active Pro, Pro Plus, Teams, Enterprise, beta, or trial plan. Data at rest in the UK; OpenAI (US) processing (no-training); prompt-injection text inside the spec is treated as inert untrusted data. TYPED FAILURES: same as architect.validate (timed_out, rate_limited, dependency_unavailable, schema_mismatch, each carries retryable + next_action); the services raise the identical typed envelopes on this lens. CALIBRATION DISCLOSURE: the scoring prompt is a v1 first-cut mirroring the architect's contract structure; its score calibration is not yet tuned against a corpus of real runs the way architect.validate was. Treat the grade as directional quality signal, not a certified verdict. DOCTRINE: the eight laws, each law's definition, rationale, anti-patterns, and the validator questions this tool scores against, live in content/spec-quality-laws.json (the what-to-build companion to the experience-design laws).
Open world
Input schema
{'type': 'object', 'title': 'validate_specificationArguments', 'required': ['implementation_context'], 'properties': {'task': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Task', 'default': None, 'description': "What this spec is for (e.g. 'the closed-beta apply flow rework'). Adds evaluation context."}, 'files': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Files', 'default': None, 'description': 'File paths relevant to the spec, for context.'}, 'goals': {'anyOf': [{'type': 'array', 'items': {'type': 'string'}}, {'type': 'null'}], 'title': 'Goals', 'default': None, 'description': "Specific quality goals to weight (e.g. 'ready for an agent to build unattended', 'tight scope')."}, 'repository': {'anyOf': [{'type': 'string'}, {'type': 'null'}], 'title': 'Repository', 'default': None, 'description': "Project/repository key. Groups this run with prior spec.validate runs on the same project in your validation-history dashboard (the same grouping the other lenses use), under the 'spec' dimension."}, 'session_id': {'anyOf': [{'type': 'integer'}, {'type': 'null'}], 'title': 'Session Id', 'default': None, 'description': "Optional Governed Session to attach this run to (GEP-M2). Must reference a session YOU own (list via me.sessions; sessions are created in the web app at /app/sessions): foreign ids are refused before any model call. The run then appears on the session's timeline alongside the other lenses. With private_session=true no run is stored so nothing attaches, but the ownership check still runs FIRST: a session id you don't own fails the call either way."}, 'private_session': {'type': 'boolean', 'title': 'Private Session', 'default': False, 'description': "Set true to disable persistence AND run_id recovery for this call (a private one-shot that does not appear in the dashboard). The request is also not persisted in the model provider's response store; the provider's abuse-monitoring retention still applies. Default false."}, 'implementation_context': {'type': 'string', 'title': 'Implementation Context', 'description': "The specification under review. SEND FULL TEXT VERBATIM: the reviewer cites specific requirements, decisions, and tasks; any compression destroys evidence and produces findings on content that isn't there. For an OpenSpec change, concatenate proposal.md + design.md + tasks.md + delta specs. Do NOT truncate; if very large, split into MULTIPLE calls scoped by document."}}}
Output schema
{'type': 'object', 'title': 'validate_specificationDictOutput', 'additionalProperties': True}
team.summarize
Summarize Team Usage
Pro/Teams: summarises the caller's tool-usage patterns and value signals over a configurable window (default 30 days). Returns tool_call_counts, top principles cited in validate runs, value_event_counts by event_type, and an aggregate readiness trend. WHEN TO CALL: the user asks 'how is the Blueprint helping me/my team', 'what should I explore next', or 'show me my Blueprint usage'. WHEN NOT TO CALL: proactively or on every conversation turn (the summary is an explicit retrospective, not telemetry); to compare users (returns only the caller's own data). BEHAVIOR: read-only, idempotent over the same window. Aggregates from AIToolCallLog + ValueEvent + AIValidationRunLog. Pass private_session=true to bypass server-side logging for this summary call (the underlying historical data still exists; only this read is untracked). Auth: Bearer <token>, Teams plan only; Pro and beta plans are refused. Data at rest in the UK.
Read only
Idempotent
Input schema
{'type': 'object', 'title': 'summarize_team_usageArguments', 'properties': {'days_back': {'type': 'integer', 'title': 'Days Back', 'default': 30, 'minimum': 1, 'description': 'Number of days of usage history to include in the summary.'}, 'private_session': {'type': 'boolean', 'title': 'Private Session', 'default': False, 'description': 'Set to true to skip logging this summary call.'}}}
Output schema
{'type': 'object', 'title': 'summarize_team_usageDictOutput', 'additionalProperties': True}
History
Recent tool changes
Changed
handoffs.agency
Sept. 27, 2026, 2:52 a.m.
Changed
handoffs.partnership
Sept. 27, 2026, 2:52 a.m.
Changed
handoffs.operator
Sept. 27, 2026, 2:52 a.m.
Changed
me.validation_history
Sept. 27, 2026, 2:52 a.m.
Changed
me.await_steer
Sept. 27, 2026, 2:52 a.m.
Changed
me.session_event
Sept. 27, 2026, 2:52 a.m.
Changed
me.sessions
Sept. 27, 2026, 2:52 a.m.
Changed
me.add_evidence
Sept. 27, 2026, 2:52 a.m.
Changed
me.coaching_context
Sept. 27, 2026, 2:52 a.m.
Changed
me.learning_path
Sept. 27, 2026, 2:52 a.m.
Changed
team.summarize
Sept. 27, 2026, 2:52 a.m.
Changed
architect.certify
Sept. 27, 2026, 2:52 a.m.
Changed
architect.validate_consensus
Sept. 27, 2026, 2:52 a.m.
Changed
spec.validate
Sept. 27, 2026, 2:52 a.m.
Changed
design.validate
Sept. 27, 2026, 2:52 a.m.
Changed
architect.validate
Sept. 27, 2026, 2:52 a.m.
Changed
signals.feedback
Sept. 27, 2026, 2:52 a.m.
Changed
signals.report
Sept. 27, 2026, 2:52 a.m.
Changed
assets.list
Sept. 27, 2026, 2:52 a.m.
Changed
examples.search
Sept. 27, 2026, 2:52 a.m.
Changed
clusters.get
Sept. 27, 2026, 2:52 a.m.
Changed
me.await_steer
Sept. 25, 2026, 3:01 a.m.
Changed
me.session_event
Sept. 25, 2026, 3:01 a.m.
Changed
architect.validate_consensus
Sept. 25, 2026, 3:01 a.m.
Changed
spec.validate
Sept. 25, 2026, 3:01 a.m.
Changed
design.validate
Sept. 25, 2026, 3:01 a.m.
Changed
architect.validate
Sept. 25, 2026, 3:01 a.m.
Changed
principles.search
Sept. 25, 2026, 3:01 a.m.
Changed
spec.validate
Sept. 23, 2026, 2:52 a.m.
Changed
design.validate
Sept. 23, 2026, 2:52 a.m.
Discover
Similar MCP servers
Andreax
io.github.moralito311-andr/andreax
Offers pay-per-call AI services for inference, agent and workflow design, OCR and transcription, code generation and review, clas…
IA-QA — 130+ QA & Dev Tools for AI Agents
io.github.JcJamet/ia-qa-toolbox
Provides deterministic QA, evaluation, testing, code analysis, prompt and RAG checks, model comparison, and web security diagnost…
CompletionKit
com.completionkit/evals
Runs prompt evaluation workflows over datasets using deterministic checks and LLM judges, with metrics, scoring runs, agreements,…
Replicate
io.github.pipeworx-io/replicate
Provides access to Replicate models, versions, collections, hardware, predictions, and deployments for running and managing hoste…
Huggingface
io.github.pipeworx-io/huggingface
Provides access to Hugging Face model, dataset, and Space metadata, alongside broader structured research and data-routing tools.
Ai Model Experiments
io.github.pipeworx-io/ai-model-experiments
Runs prompts across multiple AI models and compares their outputs, costs, latency, token usage, and errors.
rubrkit
com.rubrkit/rubrkit
Manages AI evaluation artifacts, rubric audits, eval runs, golden cases, proof reports, and drift monitoring for LLM outputs.
Hipocampo MCP
io.github.carrasquelalex1/hipocampo
Provides bilingual semantic memory, embeddings, graph links, code indexing and search, context preload, deduplication, compressio…