Skip to content
AADM
MCP

▸ 24 typed tools · five lanes · all return structured JSON

Every tool. Every contract.
One catalog.

Authoritative source

This page mirrors the hosted server's published surface. After you connect, tools/list and inputSchema on your running MCP are the final word.

AADM exposes a small, deliberate set of tools. Each one is named so a human reviewer can read the call log and understand what just happened. None of them edit your repo — your agent does that.

This catalog is the concrete answer to “what may the agent do.” For why bounding that surface is the job rather than a constraint on it, see agentic engineering.

Connect production agents Read the standard

▸ Entry points · what to call first

Pick the lane. Call one tool.

AADM frames and routes — it does not scan your repo. These are the first MCP tools to invoke; pass/fail stays with your tests and CI.

You say · Investigate

Investigator

defect

First call

debug_defect

You say · Navigate

Navigator

delivery

First call

map_feature

You say · Prism

Fact frame

pre-lane

First call

prism_frame

You say · Assure

Sentinel

assurance

First call

assurance_run

Default flow

  1. 1

    Symptom unclear?

    prism_frame route_lane

    Contradictory UI vs server · not sure which lane owns it

  2. 2

    Lane obvious?

    route_lane

    Then the lane primary tool — delivery · defect · assurance

  3. 3

    Long thread?

    orchestrator_anchor

    Re-anchor after compaction — don't replay the full brief

  4. 4

    Which tool next?

    standard_brief suggest_aadm_tools

    Routing snapshot only — avoid response_scope: full unless you need the catalog

Quick cheat sheet

You're trying to… → open with this tool first.

CallMcpTool · server user-aadm

You're trying to… Open with
Fix a bug / 404 / wrong behavior debug_defect
Registry ↔ client ↔ server wiring drift cross_surface_check
Design or implement a feature map_feature · plan_delivery
Fix UX on one screen / tab ux_surface_pass
Audit / prove before ship assurance_run · sentinel_closure
Contradictory or muddy symptom prism_frame
Lost in a long thread orchestrator_anchor
Know lane · need playbook route_lane
Framework jargon in the bug vocabulary_crosswalk

TL;DR · four entry points + one pre-step

  • 01 Muddy fact → prism_frame
  • 02 Bug → debug_defect
  • 03 Feature → map_feature or plan_delivery
  • 04 Prove before ship → assurance_run
  • + Lane known · need playbook → route_lane (+ optional stack when you know mutation / projection / guidance)

00

Orchestration

Routing · session anchors · the host's branching map

Tools the host calls first. They tell the agent what kind of work is on the table and how to branch.

  • standard_brief 01
    Orchestration

    One call loads workflow parity, orchestrator contract, follow-on catalog, and Sentinel assurance JSON hosts branch on.

    When to call

    First call in a session — gives the host its branching map before any specific work begins.

  • route_lane 02
    Orchestration

    When intent is already delivery, defect, or assurance, return deterministic routing metadata — no keyword roulette.

    When to call

    When you already know the lane and want a stable handoff to the next tool.

  • orchestrator_anchor 03
    Orchestration

    Long-running jobs get a stable checklist · what to persist outside MCP, session notes, when to refresh the brief.

    When to call

    Sessions that span hours — anchors the orchestrator so it doesn't drift.

I

Navigator

Delivery · building something new

Turn a vague ask into layer-aware slices with authorization, ownership, and acceptance criteria baked in.

  • plan_delivery 01
    Navigator

    Turn a task into UDALI-shaped delivery handoffs with doctrine-backed scope and integrator-ready language.

    When to call

    New feature, structural change, or material improvement — before any code is written.

  • map_feature 02
    Navigator

    Seed layer and AUTH-XX hints from a short feature description — explicitly suggestive until your architecture confirms.

    When to call

    Quick recon on where a feature would land in your stack before sizing it.

II

Investigator

Defect · something is broken

Evidence-first. Recon classifies the failure; remediation is gated until proof crosses the router.

  • debug_defect 01
    Investigator

    Gated defect machine · Path A recon, Path B only after proof, execution-control appendix, troubleshooter response gates.

    When to call

    Anything broken vs expected — the canonical defect entry point.

  • debug_bundle 02
    Investigator

    Advanced hosts send a full integrated troubleshooter payload when they need the bundled diagnosis shape.

    When to call

    Hosts that already know they want the full integrated payload — not for general use.

  • debug_hint 03
    Investigator

    Lightweight recon-vs-diagnose hint before you commit to a full debug_defect turn.

    When to call

    When you're not sure yet whether the issue is real or a misread.

  • classify_bug 04
    Investigator

    Classify ownership and routing early so the right lane — not the loudest symptom — owns the next step.

    When to call

    Intake · before assigning the issue or starting investigation.

  • triage_bug 05
    Investigator

    Map a rough symptom to suggested AUTH topics and stack band for intake before deeper debugging.

    When to call

    Earliest triage · noisy symptom, unclear which subsystem owns it.

  • fix_pack 06
    Investigator

    After evidence and gates pass, emit an authorized fix prompt pack sized for coding agents — no premature refactor stories.

    When to call

    Only after CLASSIFIED · the bridge from diagnosis to executable fix.

III

Sentinel

Assurance · proving alignment

Audit programs scope seams. Evidence binds per crossing. Closure tiers come back in VERT/HORI language.

  • audit_interview 01
    Sentinel

    Step through vertical depth and horizontal seams until scope is confirmable; then merge into outline-shaped intake.

    When to call

    Audit prep · when scope is fuzzy and you need a structured interview to pin it down.

  • audit_outline 02
    Sentinel

    Produce the assurance scaffold · sections, checklist pointers, coder requests, human-editable confirmation.

    When to call

    When scope is confirmed and you need the audit document scaffold.

  • audit_run 03
    Sentinel

    Plain-language “run an audit” asks become a program-aware intake plus top-findings brief for a repo-connected agent.

    When to call

    When a stakeholder says “run an audit” and you need that to become structured work.

  • sentinel_programs 04
    Sentinel

    Snapshot every bundled Sentinel audit program template without pulling the full standard_brief payload.

    When to call

    Browsing available audit programs without the cost of a full brief.

  • sentinel_program 05
    Sentinel

    Fetch one audit program row by id when hosts only need that template's rigor spine and evidence expectations.

    When to call

    You know which audit program applies and just need its template.

  • sentinel_attestation_examples 06
    Sentinel

    Shipped seam-tier examples so teams see how depth and boundaries translate to must-prove vs latent seams.

    When to call

    Teaching a team how attestation depth maps to real seams in their stack.

  • sentinel_closure 07
    Sentinel

    Resolve closure tiers from attestation depth, vertical claim, and horizontal seams — deterministic seam language.

    When to call

    Reporting an audit's outcome in language an auditor will accept.

  • sentinel_stage_guide 08
    Sentinel

    Gate helper for one assurance stage of a chosen program — keeps humans oriented inside the three-stage spine.

    When to call

    Mid-audit · when humans need to know where they are and what's next.

  • sentinel_handoff_hint 09
    Sentinel

    After a sentinel_audit_exit_kind, get deterministic wording for staying in assurance or opening Navigator or Investigator.

    When to call

    When an audit surfaces a gap and you need to route it to delivery or defect work.

  • sentinel_canonical_refs 10
    Sentinel

    Curated resources/read URIs for delivery and assurance lanes so hosts wire doctrine without hunting the catalog.

    When to call

    Wiring a new host integration · the canonical resources to load first.

IV

Doctrine

Reference · canonical text from the standard

Pull canonical AUTH controls, SEAM archetypes, and role doctrine straight from the standard — verbatim, not paraphrased.

  • fetch_auth 01
    Doctrine

    Pull the official markdown for a numbered AUTH control so prompts cite governance text, not paraphrase.

    When to call

    Any time AUTH-XX is in scope — never let the agent invent what a control says.

  • fetch_seam 02
    Doctrine Sentinel

    Load a SEAM-00–15 handoff archetype — scope for trace/assurance (normalization, dispatch, persistence).

    When to call

    Anything that crosses a boundary · pair with the seam-check worksheet resource.

  • role_guide 03
    Doctrine

    Slice UDALI agent doctrine (Unifier, Designer, Adapter, Logician, Integrator) for the role and task you are in.

    When to call

    When the role behind the task is unclear and you want the right doctrine slice.

This page is a mirror. Your server is the truth.

The catalog above tracks the hosted AADM MCP's published surface. After you connect, tools/list and inputSchema on your running server are authoritative — versions, parameter shapes, and new tools land there first.

Discover the running server 
curl -X POST https://mcp.aadm.io/mcp \
  -H "Accept: application/json, text/event-stream" \
  -H "Authorization: Bearer <your token>" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

What you'll see

A JSON array of tools with name, description, and inputSchema. The same tools listed here, plus any newer additions your server may already expose.

Don't have a token? Get access.

Connect production agents Why these tools, vs raw loops
Catalog · 24 tools
Lanes · 5
Authoritative · tools/list on your server