Loading ToolBench
C# semantic code indexing and navigation server for MCP. Provides full-text search, symbol navigation, code span retrieval, and workspace-aware code analysis for .NET repositories.
CodeMap MCP demonstrates strong schema completeness and clear parameter documentation across all 9 tools. All tools have explicit input schemas with typed parameters and descriptions. Tool names follow verb_noun conventions (symbols.search, code.get_span, index.ensure_baseline). However, several tools lack descriptions that fully satisfy the 'WHAT/WHEN/WHY' rubric pattern. Output schemas are not documented. Error handling strategies are not visible in the provided code samples. The server operates over STDIO only, which is a hard transport limitation but does not affect definition quality scoring per se. Strengths: complete parameter typing, consistent naming, workspace/virtual_files overlay pattern. Weaknesses: missing output schema documentation, descriptions that lack recovery guidance, no visible error categorization.
Read a bounded excerpt of source code with line numbers.
Search indexed source file content by regex pattern. Returns file:line:excerpt for each match. Searches only indexed files (no bin/obj). Use file_path to restrict to a subtree.
Remove old cached baselines to reclaim disk space. Current HEAD and workspace-referenced baselines are never deleted. Default is dry_run:true — set dry_run:false to actually delete.
Build a semantic index for a .NET solution. Idempotent: returns immediately if the current commit is already indexed.
List all cached baselines for a repository, showing commit SHA, creation date, file size, and whether each is the current HEAD or referenced by an active workspace.
Remove ALL cached baselines for a repository, freeing all disk space. Unlike index.cleanup, this ignores protection rules — HEAD and workspace-referenced baselines are also deleted. Default is dry_run:true.
Output schemas not documented. Tools return 'full structured summary' or 'cached baselines' but no schema details visible for the response payload. LLMs cannot plan downstream tool calls or extract specific fields without knowing response structure.
Descriptions lack 'WHEN to use this instead of similar tools' guidance. symbols.get_card vs symbols.get_definition_span distinction is explained in symbols.get_definition_span description ('prefer symbols.get_card') but not vice versa. LLMs may conflate the two.
Error handling and recovery guidance not visible in provided code. No evidence of error categorization (retryable vs user-fixable vs fatal) or actionable error messages ('Invalid query format: FTS5 syntax error at position X, use quotes for literals.').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Get a full structured summary of a C# symbol including signature, docs, facts, and source code. Accepts either symbol_id (exact) or name (resolved via search).
Source code only — no card metadata or fact hydration. Accepts either symbol_id (exact) or name (resolved via search). Use for batch reads or when you need precise line control. For most uses, prefer symbols.get_card which includes source automatically.
Search for C# symbols by name, namespace, kind, or file path using full-text search.
Destructive tools (index.cleanup, index.remove_repo) marked with dry_run:true default, which is good, but no confirmation/double-check pattern or irreversible operation warning in descriptions. Users should know the blast radius.
Parameter 'virtual_files' is an array with no documented schema or example. What structure does it expect? Is it {path: string, content: string}? Ambiguous array types invite invalid input.
Parameter 'kinds' in symbols.search accepts 'array of strings' but no enum values or examples. LLMs will guess (e.g. 'Class', 'Method', 'Interface') instead of the actual allowed SymbolKind enum values.