# AI Design Blueprint (remote · aidesignblueprint.com)

Public agentic AI doctrine tools plus authenticated architecture, design, and spec validators.

- Trust score: 69/100 (medium)
- Change this week: +8
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-08-03

## Components

- remote · `aidesignblueprint.com`: 69/100 (this document), [markdown](https://verifymcp.io/servers/com-aidesignblueprint-blueprint/aidesignblueprint.md), [page](https://verifymcp.io/servers/com-aidesignblueprint-blueprint/aidesignblueprint)

## Channel facts

- Endpoint: `https://aidesignblueprint.com/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `1.6.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-08-03.

- **Endpoint Security**: 74/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - No authorisation is required to call this server. Every tool declares its destructiveHint and none is destructive, so open access doesn't expose one.
  - HTTPS is enforced; there's no plaintext access path.
  - HSTS check failed: the Strict-Transport-Security header is absent.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 54/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 14492 tokens (~499/item across 29 items; 29 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 27/100
  - Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

## Install

### Claude

```bash
claude mcp add --transport http com-aidesignblueprint-blueprint https://aidesignblueprint.com/mcp
```

### Codex

```toml
[mcp_servers.com-aidesignblueprint-blueprint]
url = "https://aidesignblueprint.com/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "com-aidesignblueprint-blueprint": {
      "type": "remote",
      "url": "https://aidesignblueprint.com/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add com-aidesignblueprint-blueprint --url https://aidesignblueprint.com/mcp --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  com-aidesignblueprint-blueprint:
    url: "https://aidesignblueprint.com/mcp"
```

### Other

```json
{
  "mcpServers": {
    "com-aidesignblueprint-blueprint": {
      "type": "http",
      "url": "https://aidesignblueprint.com/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-08-02 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-31 (score 68, +3)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-30 (score 65, +1)

- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-29 (score 64, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-07-28 (score 63, +2)

- [functional] Schema quality: good → excellent

### 2026-07-27 (score 61, 0)

- [functional improvement] Stability: unverified → 0.03
- [functional] We updated how we score, so this day's move reflects our rubric, not a change to the server

### 2026-07-26 (score 61)

First indexed and scored.

## MCP tools (29)

### `principles.list` (~217 tokens)

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.

Input parameters:

- `cluster`: Cluster slug to filter by (e.g. 'delegation', 'visibility', 'trust', 'orchestration'). Omit to return all principles.
- `lens` (string): Which public doctrine: 'architecture' = the 10 agentic principles (default), 'surface' = the 8 experience-design laws, 'spec' = the 8 spec-quality laws.

### `clusters.list` (~57 tokens)

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.

### `principles.get` (~213 tokens)

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.

Input parameters:

- `lens` (string): Which public doctrine the slug belongs to: 'architecture' (10 principles, default), 'surface' (8 design laws), or 'spec' (8 spec laws).
- `slug` (string, required): Stable slug of the principle (e.g. 'establish-trust-through-inspectability').

### `clusters.get` (~254 tokens)

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.

Input parameters:

- `slug` (string, required): Stable slug of the principle cluster (e.g. 'delegation', 'visibility', 'trust', 'orchestration').

### `examples.get` (~210 tokens)

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.

Input parameters:

- `slug` (string, required): Stable slug of the curated example (e.g. 'agents-building-blocks-5-control').

### `principles.search` (~184 tokens)

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. NOTE: search currently covers the 10 agentic principles only; for the 8 experience-design laws or the 8 spec-quality laws use principles.list(lens='surface') / principles.list(lens='spec') until search spans all three lenses.

Input parameters:

- `limit` (integer): Maximum number of results to return. Capped at server maximum.
- `query` (string, required): Free-text search query matched against principle title, definition, rationale, and cluster.

### `examples.search` (~349 tokens)

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.

Input parameters:

- `difficulty`: Filter by difficulty level.
- `library`: Filter by library or framework name (e.g. 'langgraph', 'openai', 'anthropic').
- `limit` (integer): Maximum number of results to return. Capped at server maximum.
- `pattern_family`: Filter to one agentic-pattern family. Implies patterns only, since no upstream cookbook example carries a family.
- `principle_ids`: Filter to examples that cover these principle IDs.
- `query` (string, required): Free-text search query matched against example title, summary, and metadata.

### `assets.list` (~220 tokens)

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.

### `guides.list` (~72 tokens)

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.

### `guides.get` (~106 tokens)

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.

Input parameters:

- `slug` (string, required): Stable slug of the application guide (e.g. 'security-application', 'observable-evaluation').

### `guides.search` (~110 tokens)

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.

Input parameters:

- `limit` (integer): Maximum number of results to return. Capped at server maximum.
- `query` (string, required): Free-text search query matched against all guide content including section answers and action items.

### `signals.report` (~759 tokens)

Report Value Event

Pro/Teams — 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 captures event_type, surface_used (mcp/web/cli), perceived_value (1-5), and an optional brief_context — structured fields only, NO prompts or code stored. 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: Bearer <token>, Pro or Teams plan required. UK/EU residency. Do NOT include proprietary code, prompt content, or PII in brief_context — it surfaces in admin AI-visibility dashboards. Expect a 1-line acknowledgment in the response; the structured feedback is then aggregated server-side.

Input parameters:

- `brief_context`: 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 ch…
- `event_type` (string, required): 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 r…
- `perceived_value`: 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.
- `surface_used`: 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…
- `team_size`: If the user mentions their team size during the session, record it here. Do not ask for it explicitly — only capture if volunteered.
- `workflow_stage`: Infer from what the user was doing: 'exploring' — reading doctrine, browsing principles; 'designing' — planning architecture or agent flows; 'implementing' — writing or refactoring code; 'reviewing'…
- `would_recommend`: 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.

### `signals.feedback` (~591 tokens)

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), single insert into UserFeedback. UK/EU residency. 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.

Input parameters:

- `contact_email`: 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.
- `permission_to_follow_up` (boolean): Set to true only if the user explicitly said they want a follow-up. Must be confirmed before storing contact_email.
- `rating_clarity`: 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.
- `rating_usefulness`: 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.
- `surface`: 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 th…
- `task_type`: 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`: 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`: Ask the user: 'What was missing or could be improved?' Record their answer verbatim or paraphrased. Max 1000 chars.
- `would_use_again`: 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.

### `architect.validate` (~2487 tokens)

Validate Agent Architecture

Pro/Teams — first-pass doctrine review of agentic code/workflow against the 10-principle Agentic AI Blueprint. 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 20-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, tie…

Input parameters:

- `example_limit` (integer): Maximum number of curated examples to include in recommendations.
- `files`: List of file paths relevant to the implementation context.
- `focus_area`: Narrow the evaluation to a specific principle cluster or slug (e.g. 'delegation', 'visibility', 'establish-trust-through-inspectability').
- `goals`: Specific safety or quality goals to evaluate against (e.g. 'prevent irreversible actions', 'explicit approvals').
- `implementation_context` (string, required): 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…
- `language`: Programming language of the code being evaluated (e.g. 'python', 'typescript').
- `private_session` (boolean): Set to true to disable logging AND prior-run anchoring AND run_id recovery for this call. Use for private one-shots that don't participate in the iteration arc. Default false.
- `repository`: 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…
- `session_id`: 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 befor…
- `task`: What the agent or workflow is trying to accomplish. Adds evaluation context.

### `design.validate` (~1093 tokens)

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…

Input parameters:

- `files`: File paths relevant to the artefact, for context.
- `goals`: Specific craft/UX goals to weight (e.g. 'WCAG 2.2 AA', 'one primary action per screen').
- `implementation_context` (string, required): 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…
- `private_session` (boolean): Set true to disable persistence AND run_id recovery for this call (a private one-shot that does not appear in the dashboard). Default false.
- `repository`: 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' dimen…
- `session_id`: 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 befor…
- `task`: What this surface is for (e.g. 'the closed-beta apply form'). Adds evaluation context.

### `spec.validate` (~1059 tokens)

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_blo…

Input parameters:

- `files`: File paths relevant to the spec, for context.
- `goals`: Specific quality goals to weight (e.g. 'ready for an agent to build unattended', 'tight scope').
- `implementation_context` (string, required): 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…
- `private_session` (boolean): Set true to disable persistence AND run_id recovery for this call (a private one-shot that does not appear in the dashboard). Default false.
- `repository`: 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`: 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 befor…
- `task`: What this spec is for (e.g. 'the closed-beta apply flow rework'). Adds evaluation context.

### `architect.validate_consensus` (~989 tokens)

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 =…

Input parameters:

- `example_limit` (integer): Max curated examples per child run.
- `files`: List of file paths relevant to the implementation.
- `focus_area`: Optional: narrow the review to a principle cluster or slug.
- `goals`: Specific safety or quality goals to evaluate against.
- `implementation_context` (string, required): The artifact under review. SEND FULL FILE CONTENTS VERBATIM — same constraint as architect.validate. Truncation produces hallucinated findings on code that isn't there.
- `language`: Programming language of the code (e.g. 'python').
- `n` (integer): 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).
- `repository`: 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 `architec…
- `task`: What the agent or workflow is trying to accomplish.

### `architect.certify` (~1685 tokens)

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 20-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 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 20 min, ~5× observed…

Input parameters:

- `code` (string): 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…
- `run_id` (string, required): 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_his…

### `team.summarize` (~240 tokens)

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>, Pro or Teams plan. UK/EU residency.

Input parameters:

- `days_back` (integer): Number of days of usage history to include in the summary.
- `private_session` (boolean): Set to true to skip logging this summary call.

### `me.learning_path` (~155 tokens)

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.

### `me.coaching_context` (~176 tokens)

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.

### `me.add_evidence` (~302 tokens)

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). UK/EU residency. 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 parameters:

- `course_slug` (string, required): Slug of the course the stage belongs to (e.g. 'agentic-fundamentals').
- `note` (string, required): Evidence note to append to the delegation boundary notes for this stage.
- `stage_id` (string, required): ID of the stage to append the evidence note to.

### `me.sessions` (~258 tokens)

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: Bearer <token>. Pro or Teams plan required.

Input parameters:

- `session_id`: 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.

### `me.session_event` (~626 tokens)

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 cockpit-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 cockpit 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); ste…

Input parameters:

- `actor` (string, required): Who acted: pm | engineer | designer | system (`human` is reserved for the cockpit channel)
- `event_type` (string, required): handoff | pushback | plan_preview | gate | ack (ack = started working on a steer; `steer` itself is cockpit-only and refused on this channel)
- `session_id` (integer, required): The Governed Session to post to. Must be YOURS and have team_agents enabled; list sessions via me.sessions.
- `summary` (string, required): One-to-two sentence event summary (truncated to 500 chars) — a decision or transition, not a chat message.

### `me.await_steer` (~487 tokens)

Wait for the Next Cockpit Steer (long-poll)

Pro/Teams. BLOCK until the session owner posts the next `steer` event to a Governed Session from the AIDB Studio cockpit, 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: Bearer <token>, Pro/Teams plan.

Input parameters:

- `after_event_id` (integer): 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 delive…
- `session_id` (integer, required): The Governed Session to watch. Must be YOURS and have team_agents enabled; list sessions via me.sessions.
- `timeout_s` (integer): 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 ra…

### `me.validation_history` (~443 tokens)

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: Bearer <token>. Pro or Teams plan required.

Input parameters:

- `limit` (integer): Maximum number of runs to return when scoped to a single repository. Capped at 50. Ignored when `run_id` is provided.
- `repository`: 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 passe…
- `run_id`: 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…

### `handoffs.operator` (~373 tokens)

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). UK/EU residency. Response confirms ticket id + topic so the user can reference it.

Input parameters:

- `agent_name` (string): Name of the agent or client triggering the handoff.
- `agent_platform`: Platform or runtime the agent is running on (e.g. 'claude-code', 'cursor', 'copilot').
- `locale` (string): Response locale for the handoff acknowledgment.
- `page_url`: URL of the page or context where the handoff was triggered.
- `reason` (string, required): Clear description of why a human operator review is needed.
- `topic` (string): Topic category for routing (e.g. 'agent', 'billing', 'access', 'general').
- `trace_summary`: Optional summary of the agent's recent actions or trace for operator context.

### `handoffs.partnership` (~324 tokens)

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). UK/EU residency. Response confirms the ticket id + audience so the user can reference it.

Input parameters:

- `agent_name` (string): Name of the agent or client triggering the handoff.
- `agent_platform`: Platform or runtime the agent is running on.
- `locale` (string): Response locale for the handoff acknowledgment.
- `organization`: Name of the organization or company making the partnership inquiry.
- `reason` (string, required): Clear description of the partnership opportunity or inquiry.
- `role`: Role or title of the person submitting the partnership inquiry.
- `topic` (string): Partnership topic category.
- `trace_summary`: Optional agent trace summary for operator context.
- `website`: Website of the organization for additional context.

### `handoffs.agency` (~383 tokens)

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). UK/EU residency. Response confirms the ticket id + scope so the user can reference it.

Input parameters:

- `agent_name` (string): Name of the agent or client triggering the handoff.
- `agent_platform`: Platform or runtime the agent is running on.
- `company`: Company or team name submitting the agency inquiry.
- `locale` (string): Response locale for the acknowledgment.
- `reason` (string, required): Description of the engagement need: workflow sprint, proof-of-concept, pilot support, or advisory.
- `role`: Role or title of the person submitting the agency inquiry.
- `support_type`: Type of support needed.
- `trace_summary`: Optional agent trace summary for operator context.
- `website`: Website or relevant URL for the team or project.
- `workflow_stage`: Current workflow stage.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/com-aidesignblueprint-blueprint/aidesignblueprint#diagnostics

## Score history

- 2026-08-03: 69
- 2026-08-02: 69
- 2026-08-01: 68
- 2026-07-31: 68
- 2026-07-30: 65
- 2026-07-29: 64
- 2026-07-28: 63
- 2026-07-27: 61
- 2026-07-26: 61

## Links

- Remote endpoint: https://aidesignblueprint.com/mcp
- Repository: https://github.com/Michelangelo-Z/ai-design-blueprint
- Website: https://aidesignblueprint.com/en/for-agents
- Changelog RSS feed: https://verifymcp.io/servers/com-aidesignblueprint-blueprint/aidesignblueprint/changelog.xml
- Changelog JSON feed: https://verifymcp.io/servers/com-aidesignblueprint-blueprint/aidesignblueprint/changelog.json
- HTML version of this page: https://verifymcp.io/servers/com-aidesignblueprint-blueprint/aidesignblueprint