archprint
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| archprint_scanA | List the architecture rules this TypeScript repo already follows, with the evidence: each rule stated in plain words, whether it is AUTO (clears the confidence gate) or SUGGEST (short of it), its adoption ("enforce": archprint init or generate writes a rule for it, which archprint wire connects to the linter, and public-API rules need dependency-cruiser; "review": held for a human to review, not enforced by default; "report-only": the code follows it but archprint writes no rule for it), how many files conform vs. break it, the files that break it, and the confidence. Read-only. |
| archprint_recommendA | Recommend an architecture rule set for this repo from its evidence and detected stack: what to enforce now, what the code already follows that archprint reports but does not write a rule for yet (reportOnly), what to review before enforcing, and what comparable repos commonly adopt that this repo does not yet. Read-only. |
| archprint_explainA | Explain one rule from archprint_scan in depth, by its label (e.g. AP-002, env-access, or "lib !-> app"): its statement, gate status, adoption (enforce, review, or report-only, as in archprint_scan), observed conformance and confidence floor, and every file that breaks it (scan lists only a few). For the forbidden-import rules (AP-001, AP-002) it also returns each confidence-gate condition with its value and threshold, how to fix a violation, and when not to adopt the rule. Read-only. |
| archprint_checkA | Check the current change, including uncommitted edits, against the rules this repo adopted with archprint init or generate, and report only the violations the change introduces (file, line, rule, and the evidence for the rule), plus those it fixed and any exceptions allowed with a reason in .archprint/config.json. Use it before finishing a change. Compares with |
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 4 tools
Each tool has a distinct role: check validates a change, scan lists rules, explain details one rule, and recommend proposes a rule set. There is mild overlap among the three read-only rule tools (scan and explain both report violating files), but descriptions make the boundaries clear enough to select correctly.
All four tools follow an identical archprint_<verb> pattern (check, explain, recommend, scan) with consistent snake_case and clear verb-based naming.
Four tools is slightly lean but each covers a distinct phase of the rule lifecycle (discover, understand, propose, validate). It is not bloated, though the small surface leaves little room for the write-side operations the domain implies.
The server covers reading rules, explaining them, recommending them, and checking changes, but has no tool to actually adopt/write rules even though archprint init, generate, and wire are referenced repeatedly in descriptions. An agent can recommend and validate but cannot complete the adoption lifecycle, a notable gap.