Loading ToolBench
MCP server for token-efficient .NET codebase navigation via Roslyn
RoslynLens provides 10 well-named, read-only analysis tools for .NET codebases. Tool names follow verb_noun convention (analyze_*, detect_*, find_*) and are action-oriented. All tools have descriptions (avg ~120 chars, within baseline 34-392). Input schemas are present with typed parameters and descriptions. However, output schemas are NOT documented in the tool definitions themselves, only in a separate ToolResponses.cs file. Parameter descriptions are present but often terse (e.g., 'Optional containing class name' lacks context on when/why to use it). No error handling guidance, no recovery hints, and no pagination/limit enforcement visible in tool definitions. Missing tool annotations (readOnlyHint, idempotentHint) despite all tools being read-only. Compound tools (analyze_method) combine multiple concerns without clear composition guidance.
Analyze control flow within a method: reachability, return points, and exit points.
Analyze data flow within a method: variable declarations, reads, writes, captured variables, and data flowing in/out.
Compound tool: returns a method's signature, callers, dependency graph, and complexity metrics in a single call.
Runs registered anti-pattern detectors on syntax trees and returns violations with suggestions.
Detects circular dependencies in the project reference graph or type dependency graph using DFS cycle detection.
Detect structurally similar code blocks across the solution using AST fingerprinting. Returns groups of duplicate methods.
Output schemas not documented in tool definitions. ToolResponses.cs exists but is not linked to tool registrations. LLMs cannot infer what fields to expect from each tool's response.
No tool annotations (readOnlyHint, idempotentHint, destructiveHint) despite all tools being read-only and idempotent. Agents cannot determine safety/retry semantics without explicit hints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Find all callers (call sites) of a method across the solution.
Finds potentially unreferenced types, methods, and properties that may be dead code. Skips generated code (obj/bin, *.g.cs, <auto-generated> headers) and types activated by standard .NET contracts (IHostedService, ControllerBase, PageModel, ComponentBase).
Identifies types or methods with disproportionately high incoming reference counts (god nodes). Flags symbols whose reference count exceeds mean + threshold × stddev. These are coupling hotspots worth reviewing for decomposition.
Find all implementations of an interface or all derived classes of a base class across the solution.
Parameter descriptions lack context. 'Optional containing class name' does not explain when/why to provide className or how it disambiguates overloaded methods. Descriptions should be 50-200 chars with actionable guidance.
No error handling guidance. Tools lack recovery hints (e.g., 'If method not found, try find_dead_code to verify it exists'). Agents cannot self-correct on failures.
Compound tool analyze_method combines signature, callers, dependency graph, and complexity metrics. Violates single-responsibility principle. Should be split into separate tools or clearly document composition.