archprint
Related Servers
Alternatives to archprint
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityAmaintenanceExposes four low-token tools — map, place, check, and plan — that let any coding agent read a codebase's declared systems, boundaries, and allowed dependency routes before it writes code. Agents can look up where a file belongs and what it may import, see whether their uncommitted edits crossed a boundary, and declare new dependencies up front so violations surface on the map, in the PR, and mid-turn instead of in review.21 npm15MIT
- AlicenseNot gradedqualityDmaintenanceFramework-agnostic architecture-rule enforcement for AI agents: analyzes Python codebases import graphs against declarative rulesets to report layer, forbidden-import, and cycle violations with file and line numbers. Supports MCP, OpenAI, Anthropic, LangChain, LlamaIndex, and CLI integrations.MIT
- AlicenseAqualityBmaintenanceIndexes any TypeScript / React / Next.js repo into a queryable code graph and exposes 13 MCP tools — who-renders, who-calls, find-references, blast-radius, find-cycles, dead-code orphans, and local semantic search — so agents query structure instead of reading whole files. Built on ts-morph, so edges are resolved, not grepped.142MIT
- AlicenseNot gradedqualityBmaintenanceGives your AI coding agent a bounded map of an unfamiliar TypeScript SaaS repo: where the code lives, what's risky to touch, and where the money / auth / user flows are. Provides eight MCP tools for orientation, task focus, risk assessment, and SaaS-specific observations without AST or type checking.14 npmMIT
- AlicenseAqualityBmaintenanceProvides read-only structural analysis of codebases, surfacing architecture smells with traffic-light ratings and rendering dependency relationships as Mermaid flowcharts.4MIT
- AlicenseAqualityDmaintenanceAnalyzes codebases to generate dependency graphs and architectural insights across multiple programming languages, helping developers understand code structure and validate against architectural rules.627 npm20MIT
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.