Loading ToolBench
Architectural memory engine — answers 'does this concept already exist, what is canonical, and what is the evidence' for any codebase. Deterministic; AI is a client, never a component.
Archietect exposes 28 tools via STDIO MCP with reasonable naming (verb-first: concept, intent, plan, impact, imports, guard, doctor, tour, duplicates, verify_edit, owner, init, hook, uninstall, help_json, history, seed, history_archive, ci, mutations, laws, watch, serve, mcp). However, critical gaps undermine usability: (1) Input schemas are present but sparse, most tools lack detailed parameter descriptions explaining constraints, formats, or dependencies. (2) Tool descriptions are domain-specific and moderately detailed (50-150 chars), but many lack actionable guidance on WHEN to call them vs. similar tools (e.g., concept vs. concept_at, plan vs. intent). (3) Output schemas are not documented, LLMs cannot predict what fields to expect, forcing exploratory calls. (4) Error handling is absent from descriptions, no guidance on retryability, user-fixable vs. fatal errors, or recovery paths. (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY, WRITE, REVERSIBLE). (6) Parameters like 'text' (array of strings) lack format/length constraints. Average tool description ~100 chars (below 194-char baseline); zero tools document return types.
CI gate: pipe a diff in, get an exit code out. `git diff main... | archietect ci`
Does this concept exist? Which implementation is canonical?
Episodic replay: what this concept looked like at a past ARCHITECTURE version. Only ever has data for a project where `archietect watch` has actually run and observed a concept-set change.
Repository summary for someone who just cloned it (the intern's view)
Suspected duplicate BUSINESS LOGIC — two functions in different files/languages sharing no name but independently encoding the same rule, evidenced by shared literal string values.
Suspected duplicate concepts (name-token overlap — risk, not proof)
THE LAW: check text for CREATE TABLE that duplicates an existing concept
No output schemas documented. LLMs cannot predict response structure, forcing exploratory calls and context waste. Every tool should document return type (object fields, array items, pagination).
Parameter descriptions lack actionable constraints. 'text' (array of strings) has no length/format guidance; 'version' (integer) has no range; 'port' (integer) has no min/max. LLMs pass invalid values without validation hints.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite explicit risk levels (READ_ONLY, WRITE, REVERSIBLE). Agents cannot distinguish safe reads from destructive writes without parsing descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Dump every subcommand, its description, and its exit codes as JSON. Machine-readable help for AI agents and tooling — generated from the same dispatch table the binary runs, so it can never drift.
The architectural timeline: what changed, when, and what the engine said about it — Git knows files changed; this knows ARCHITECTURE did
Move events older than a cutoff out of the live archietect.db into a permanent, append-only archive file (.archietect/history-archive.db) — never deletes a record, only relocates it.
Install or remove the local pre-commit architectural gate.
What is affected if this concept changes?
What does this file exactly, unambiguously import — and what imports it? Only exact relative-import resolutions are reported; an external package or an ambiguous match is correctly reported as nothing, not a guess.
Scan the repository and persist the index (archietect.db)
From a stated intent to the smallest correct change
The law registry: every rule the engine obeys, with the wrong answer that taught it and the regression test that enforces it forever
MCP server mode — same read-only engine, MCP protocol transport
Observe structural mutations in a Git diff without applying policy.
Who owns a concept: the directory that declares it
One-call architectural plan: canonical locations, owners, decisions, impact — the composition an agent would need five calls for
Cold-start fix: scan README.md for constraint/decision-shaped bullet points and propose them as `[[decision]]` entries, VERBATIM — no LLM, no rephrasing. Dry-run by default (prints candidates, writes nothing); --write appends new ones to archietect.toml.
REST API (127.0.0.1, read-only) — GUI and CI become clients of the same engine; no business logic lives in any transport
Summary of what the index knows — and what it admits it cannot see
Onboarding tour: important concepts, ignorable ones, and the mistakes the ontology already knows people will make — zero generated prose
Remove Archietect-managed local integration points. Project data stays.
Every declared concept bucketed by verdict (ACTIVE vs DECLARED_ONLY) instead of querying one name at a time.
Pre-write AST validation gate — checks proposed file content in memory before it touches disk. Catches Rust syntax errors (via syn) and duplicate top-level symbol declarations (via the structural extractor) in <5ms. Exits 0 if clean, 2 if broken.
Daemon mode: watch the tree, keep archietect.db warm, emit unprompted findings as JSON lines. Observation and notification — never action.
Descriptions lack WHEN-to-use guidance. 'concept' vs 'concept_at' distinction unclear; 'plan' vs 'intent' unclear. LLMs waste reasoning cycles choosing between similar tools.
No error handling guidance in descriptions. Tools like 'guard', 'ci', 'verify_edit' have exit codes (0, 2) but no description of what they mean or how to recover. LLMs cannot self-correct on failures.