Loading ToolBench
MMI Architecture Quality Analyzer with Live Monitoring for Cursor - Analyzes Clean Architecture layering, encapsulation, abstraction levels, and circular dependencies in C# projects with real-time monitoring.
MMI Analyzer has 9 tools covering C# architecture analysis. Tool naming is verb-based and clear (analyze_*, visualize_*, start_*, stop_*, get_). Descriptions are present and reasonably detailed (80-200 chars range). Input schemas are defined with type declarations and enums for mode parameters. However, there are significant gaps: output schemas are not documented in the tool definitions themselves, error handling is minimal beyond basic validation, and parameter descriptions could be more prescriptive about constraints. The server is read-only for most tools (architecture analysis) with two stateful monitoring tools (start_monitoring, stop_monitoring). STDIO transport is a hard limitation capping protocol readiness.
Analyzes separation of abstraction levels. Detects mixing of business logic (Domain/Application) with technical details (SQL, HTTP, File I/O). Identifies violations of clean separation.
Analyzes circular dependencies (cycles) in the codebase. Detects files that depend on each other in a circular way, which violates good architecture principles. Critical when Domain layer is involved.
Analyzes encapsulation quality by checking public vs internal visibility of classes, interfaces, and records. Identifies over-exposed types that should be internal.
Analyzes Clean Architecture layering violations in a C# project. Checks if Domain/Application/Infrastructure layers follow dependency rules.
Complete MMI (Modularity Maturity Index) analysis. Runs all three dimensions: Layering (Dimension 2), Encapsulation (Dimension 5), and Abstraction Levels (Dimension 8). Provides overall architecture quality score.
Output schemas not documented. Tool definitions lack return type documentation, making it unclear to LLMs what structure to expect from responses. For example, analyze_mmi returns a combined report but the schema is not specified in the tool definition.
Minimal error recovery guidance. Error responses use basic messages like 'Check the log file for details' and 'Please check if the path is correct' without actionable next steps for the LLM. Should guide agents: 'Path not found. Valid project paths must be absolute and contain a .csproj file. Example: C:\Projects\MyApp'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
Shows status of all monitored projects with current scores and trends.
Starts continuous MMI monitoring for a C# project. Watches .cs files and automatically analyzes on changes. Stores score history over time.
Stops MMI monitoring for a project. Preserves history.
Generate interactive architecture heatmap visualization with D3.js. Shows files as nodes colored by score (green=good, red=critical), dependencies as links, violations highlighted. Click nodes to see details.
Parameter descriptions lack constraints. 'mode' parameter is well-constrained with enum, but 'projectPath' description states 'Path to the C# project directory' without format expectations (absolute vs relative, required structure, platform-specific handling). Should specify: 'Absolute path to C# project root (must contain .csproj file); platform-agnostic (e.g., D:\Projects\MyApp on Windows or /home/user/MyApp on Linux)'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present. This limits LLM understanding of tool safety and idempotency. start_monitoring and stop_monitoring are stateful operations that should declare destructiveHint:true (they modify monitoring state).
Monitoring tools lack confirmation/dry-run pattern. start_monitoring and stop_monitoring are stateful operations that could benefit from optional 'dry_run' or 'confirm' parameters to prevent accidental state changes, following the confirmation-request pattern.
get_monitoring_status has empty properties object, providing no visibility into returned fields. LLMs cannot determine what data is available without documentation of the monitoring status structure (which projects are monitored, their current scores, trends, etc.).
No input validation messaging. While code includes validateProjectPath(), error messages do not distinguish between 'path does not exist' vs 'path is not a C# project' vs 'insufficient permissions'. Agents need detailed error types to make appropriate recovery decisions.