Loading ToolBench
MCP server providing C# code analysis and navigation tools powered by Roslyn language server, including diagnostics, definitions, references, symbols, and type/call hierarchies
Roslyn MCP Server demonstrates solid definition quality with 8 well-named, verb-prefixed tools (diagnostics, hover, go_to_definition, peek_definition, get_call_hierarchy, get_type_hierarchy, document_symbols, find_symbols). All tools have descriptions (avg ~150 chars, within 10-1024 baseline). Input schemas are present with typed parameters and descriptions. However, output schemas are not documented in the source code provided, only input schemas are visible. Error handling uses UserFacingException with codes and messages, but recovery guidance is minimal. Parameter descriptions are generally good but lack explicit constraints (e.g., no enum declarations for 'severity', 'direction', 'scope', 'matchMode' despite fixed valid values). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) detected. All tools are read-only (no state mutation), which is appropriate but should be explicitly declared.
Use when you need Roslyn diagnostics already published by the language server for one C# file or for scope=workspace. This is not a full build; results reflect currently processed publishDiagnostics notifications.
Use when you know a C# file and need a bounded compiler-backed outline of its symbols, such as classes, methods, and properties. Optional kindFilter and query narrow returned symbols while preserving ancestor context for matching descendants. Use find_symbols when you do not know the file location.
Use when you know a C# symbol name but do not know its file location. This is compiler-backed workspace symbol search, not plain text search; query must be at least 2 non-whitespace characters and empty results can be inconclusive while warming.
Use when you have an exact C# callable position, such as a method, constructor, property accessor, event, or operator, and need direct depth-1 incoming callers, outgoing callees, or both. This is not recursive; kindFilter and includePathPrefixes reduce returned edges after Roslyn LS responds, not request cost.
Use when you have an exact C# type position and need base type, derived type, or interface implementation hierarchy. Traverses LSP type hierarchy edges breadth-first up to maxDepth. includePathPrefixes narrows returned and traversed follow-up types after Roslyn LS responds.
Output schemas not documented. Tool descriptions explain what is returned (e.g., 'definition locations with bounded source snippets'), but the actual response structure (field names, types, nesting) is not visible in source code. LLMs cannot plan downstream tool calls or extract specific fields without knowing the response schema.
Enum constraints not declared in schemas. Parameters like 'severity' (error|warning|information|hint), 'scope' (file|workspace), 'direction' (incoming|outgoing|both), and 'matchMode' (default|exact|prefix|contains) accept fixed sets of values but are defined as free-form strings. LLMs may hallucinate invalid values; enums are self-documenting and prevent this.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2026-07-28+ | v2 |
Use when you have an exact C# source position and need compiler-backed definition locations only. Prefer peek_definition when you also need source snippets.
Use when you have an exact C# source position and need compiler-backed type, signature, or documentation info.
Use when you have an exact C# source position and need definition locations with bounded source snippets. Prefer go_to_definition when locations alone are enough.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 8 tools are read-only and idempotent (safe to retry), but this is not explicitly declared in the tool metadata. Agents cannot infer safety properties without annotations.
Limited error recovery guidance. Error handling uses UserFacingException with codes (e.g., 'invalid_scope', 'invalid_severity') and messages, but does not guide the LLM on next steps. E.g., 'No textDocument/publishDiagnostics notification has been received for this file yet' explains the state but does not suggest 'retry after workspace warming' as an actionable recovery path.
Parameter constraints not fully documented. Numeric parameters like 'maxResults', 'contextLines', 'maxDepth' have defaults and server-side caps mentioned in descriptions, but min/max bounds are not explicitly stated in parameter descriptions. E.g., 'maxDepth defaults to 2 and is capped at 5' should be 'maxDepth: 1 - 5 (default 2)'.