Give any AI assistant real architectural understanding of a codebase — local, private, zero-config MCP server.
mcp-architect provides well-intentioned tooling for code analysis with generally clear descriptions and reasonable parameter schemas. However, there are systematic gaps in schema completeness, output documentation, and error handling patterns. All 5 tools are explicitly registered with @mcp.tool() decorators and have docstrings. Tool naming is verb-forward and clear (architecture_overview, dependency_graph, impact_analysis, hotspots, explain). Descriptions range from 104-174 characters, which is within the production baseline (p10=34, p90=392). All parameters have descriptions. The critical weakness: NO input schemas are visible in the source code, only docstring arg documentation. Tools return free-form markdown strings rather than structured JSON. Error responses are minimal (e.g., '❌ Not a directory: {root}') and do not guide recovery. No output schemas are documented. Per-tool scores: architecture_overview 65, dependency_graph 68, impact_analysis 70, hotspots 66, explain 69.
High-level map of a codebase: languages, frameworks, size, structure, and entry points. Start here to understand an unfamiliar repo.
Map how internal modules import each other, the most-depended-upon modules, and any circular dependencies. Use to understand coupling.
Deep-dive a single folder or file: its files, public classes/functions, and external dependencies.
Find the files most worth attention: largest, most complex, most frequently changed (git), and highest combined risk.
What could break if you change `target`? Walks the import graph backwards to list direct importers and the full transitive blast radius, and flags whether the target is a high-risk hub. Use before editing/refactoring a module.
No input schemas visible in source code. All tools use only docstring-style arg documentation (path: str = '.') without explicit JSON Schema registration. FastMCP may auto-generate schemas from type hints, but this cannot be verified from the source.
All tools return unstructured markdown strings (free-text) instead of structured JSON objects. Example: architecture_overview returns a formatted string like '# Architecture Overview, `repo`\n\n**N files · M LOC**\n\n## Languages\n...' This requires LLMs to parse markdown, wastes tokens, and loses type information. Structured responses with typed fields (languages: [{language: string, files: int, loc: int}], ecosystems: [string], etc.) would be more composable.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Output schemas are completely undocumented. Tools return markdown blobs; LLMs cannot plan downstream calls or extract specific data (e.g., extracting all module names from dependency_graph). Pattern:tool and pattern:tool-description both require documented output schemas.
Error handling is minimal and non-actionable. Errors like '❌ Not a directory: {root}' and '❌ Couldn't find `{target}` in the import graph.' do not guide recovery. Pattern:recovery-guide requires errors to include next steps (e.g., 'Target not found. Try calling dependency_graph() first to see available modules.').
No pagination or result limiting documented. Tools like dependency_graph could return graphs with hundreds of modules; impact_analysis can return large transitive closures. Code does cap transitive_importers display at 30 items with '…and N more', but this is done at formatting time, not at result-collection time. Pattern:paginated-result requires offset/limit params and total counts for tools returning lists.
Parameter 'language' in dependency_graph and impact_analysis accepts free-form 'auto', 'python', 'js'/'ts' but is not declared as an enum. Pattern:constrained-input requires enums for known-value sets. This invites hallucinated language values like 'ruby' or 'java'.
Parameter descriptions lack format/constraint specificity. Example: 'path: Repo path to analyze. Relative to the server's working directory (or MCP_ARCHITECT_ROOT if set). Defaults to the whole project.' Does not specify: must path exist? Is it a directory or file? What if path is absolute? Pattern:tool-description requires explicit constraints.