architect-anything-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| aa_startB | Prepare a catch-up or focused investigation workspace. Does not analyze the target. |
| aa_statusB | Read an investigation's checklist, depth, lens, and report validation state. |
| aa_checklistB | Record the answer to one investigation checklist item (status plus a concrete note). |
| aa_citeC | Build a hashed evidence record for a local file; append=true adds it to the working report. |
| aa_upsert_claimB | Add or update a claim in the working report with immediate reference validation. |
| aa_upsert_sectionC | Add or update a report section, automatically pruning replaced scaffold placeholders. |
| aa_upsert_diagramC | Add or update a diagram in the working report with immediate structural validation. |
| aa_set_run_metaC | Set working report title, subtitle, target name, run status, coverage, limitations, changes, or tools. |
| aa_finishB | Check collection state and publish the authored report as an immutable snapshot. |
| aa_validateB | Validate a report model, optionally checking cited local files and hashes. |
| aa_renderC | Publish an authored report model without an investigation workspace. |
| aa_inventoryC | Fingerprint selected local files into a new JSON file. |
| aa_compareC | Compare two inventories or two reports. |
| aa_schemaC | Return a machine-readable contract: report, investigation or commands. |
| aa_rea_statusB | Probe an existing REA CLI. Does not prove providers are ready or MCP is connected. |
| aa_rea_runC | Run one REA CLI operation, retaining output and a receipt at a new path. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| catch-up | Catch up on a repository or product and publish an evidence-backed architecture report. |
| explain-feature | Trace a specific feature, subsystem, or design question end-to-end with citations and diagrams. |
| extract-mechanism | Extract the portable, product-neutral formula behind a mechanism without cloning the product. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Architect Anything Report Schema v1 | JSON Schema contract for report.json |
| Architect Anything Investigation Manifest Schema v1 | JSON Schema contract for investigation.json |
| Lenses and Companion Report Packs Guide | Overview of available investigation lenses and optional emit packs |
TDQS
Scored across 16 tools
Most tools target distinct resources or lifecycle stages: investigation setup, checklist, citations, claims, sections, diagrams, validation, publishing, inventories, comparison, schema, and REA CLI operations. The main ambiguity is between aa_finish and aa_render, since both publish reports, though their descriptions distinguish workspace-backed vs workspace-free publishing. aa_status and aa_rea_status are also close in naming but clearly separate investigation status from REA CLI probing.
All tools share the aa_ prefix and use readable snake_case, with a predictable verb_noun pattern for most operations such as aa_upsert_claim and aa_set_run_meta. Minor deviations appear in noun-only names like aa_status, aa_checklist, aa_inventory, and aa_schema, but the overall convention remains consistent.
Sixteen tools are slightly over the typical comfortable range, but the server covers several related workflows: investigation setup, report authoring, validation/publishing, inventory comparison, schema introspection, and REA CLI integration. Each tool appears to have a concrete role rather than being redundant padding.
The surface covers the main lifecycle from investigation setup through checklist tracking, evidence citation, report authoring, validation, and publishing, plus inventory/comparison and REA CLI helpers. Minor gaps exist around explicit deletion or listing of existing investigations/reports and removing individual report elements, but core workflows are well supported.