Architect Agent Framework MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JEV_API_KEY | No | Optional live judge API key, configured via .env or ~/.architect-framework/.env. | |
| ARCHITECT_PYTHON | No | Set to the prepared environment's interpreter. Otherwise the launcher probes its current interpreter and uses `uv`, when available, to provide missing dependencies in an isolated environment. The MCP and hook manifests require a Python 3.10+ command named `python` on the host's PATH, including native Windows. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| architect_sdd_initB | Initialize a new SDD workspace in the target directory (supports solo-author and governed-team presets and existing source files). |
| architect_sdd_extractB | Extract source requirements, ADRs, scenarios, and conflict records into .architect-build/harvest.json (auto-discovers sources when omitted). |
| architect_sdd_materializeC | Materialize the target architecture document tree, ledgers, wave micro-batches, and frozen basis_digest. |
| architect_sdd_prepare_checkB | Run the built-in post-processing pipeline (strip , tighten lines, repair frontmatter, STE-80 style fix, stamp depth_witnesses, freeze digest). |
| architect_execute_standaloneC | Execute a single Domain x Task skill pair in standalone mode (UC-05) without requiring sdd-workspace.yml. |
| architect_candidate_reviewA | Review an exact candidate: checks, semantic judge and all-document language evidence. live=true explicitly permits configured paid calls within the shared budget. Never accepts. |
| architect_language_reviewA | Record revision-bound per-rule language findings. live=true sends complete context to configured Jev; false runs local checks. No qualification or approval authority. |
| architect_language_repairB | Propose a targeted host-authored repair under an accepted grant. Preserves facts and live files; at most two repair attempts per document lineage. Candidate still needs review. |
| architect_capabilitiesB | Read supported host actions, coverage and authority boundaries. |
| architect_doctorC | Read bounded redacted diagnostics without modifying run state. |
| architect_style_checkB | Check declared STE-inspired subset for one exact registered revision; incomplete rules stay unknown. No approval authority. |
| architect_sdd_readC | Read a bounded registered artifact slice with its exact live or candidate revision. |
| architect_runs_startC | Start a bounded, revision-bound core task plan; human decisions remain separate. |
| architect_runs_observeA | Read durable core events and task snapshots; starts no work. |
| architect_runs_controlC | Pause, resume, cancel or retry scheduling; no approval authority. |
| architect_task_claimC | Claim a ready core task and its private attempt lease. |
| architect_task_heartbeatC | Renew the exact active attempt lease. |
| architect_task_completeC | Submit scoped proposal operations; never accepts or publishes documents. |
| architect_sdd_checkC | Read deterministic checks, regression readiness and freshness without accepting or changing state. |
| architect_sdd_proposeC | Create an isolated candidate under a configured skill grant and expected live snapshot. Never accepts. |
| architect_runtime_planB | Preview a revision-bound task plan and gates without creating a run. |
| architect_runtime_startB | Start a run in harness mode: the host agent is the executor. Returns what waits. |
| architect_runtime_statusC | Run state, per-agent lifecycle state and every pending wait. |
| architect_runtime_nextC | What to do now: jobs to execute (with brief and allowed paths) and what waits for a human. |
| architect_runtime_tickC | Continue |
| architect_runtime_recheckB | Re-read the ledgers after a human decided. Carries no authority: an unapproved wait just waits again. |
| architect_runtime_scorecardC | Read the current core task summary; document acceptance is separate. |
| architect_runtime_skillsA | The skill slots this workspace needs: which have content, which are empty, what fills the empty ones (pack, price, store) and how to install a bought zip. Same JSON as |
| architect_console_urlA | The current workbench link for task gates and document acceptance. Hand it to the user; they read and sign there with a passkey. Read-only: no tool decides. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 29 tools
The tool set has many similarly named lifecycle phases, especially architect_runs_start vs architect_runtime_start/plan, architect_sdd_check vs architect_style_check vs architect_candidate_review, and architect_runtime_status vs architect_runs_observe. Descriptions do clarify most boundaries, but an agent could still misselect among the runtime/run/review/check tools without careful reading.
Most tools follow an architect_<domain>_<action> snake_case pattern, with clear groupings for sdd, runtime, runs, task, and language. There are minor deviations such as architect_capabilities, architect_doctor, architect_console_url, and noun-first review names, but the overall convention is predictable.
With 29 tools, the surface is heavy and exceeds the typical well-scoped range. The domain is complex, but several tools cover narrow runtime phases or review/check states, making the overall set cumbersome for an agent to navigate.
The surface covers the SDD lifecycle from init and extraction through materialization, proposal, review, runtime execution, task leasing, diagnostics, and human handoff via the console URL. Minor gaps exist around explicit installation or broader workspace administration, but core workflows and human acceptance boundaries are represented.