Loading ToolBench
A C# Model Context Protocol (MCP) server implementation that provides tools for code analysis, bulk editing, configuration management, streaming file processing, and AI-powered code assistance.
MCPsharp presents a mixed profile. It has 22 tools with explicit registration, full input schemas visible in code, and descriptions for all tools. However, many descriptions lack the depth needed for LLM tool selection (several are under 100 chars, some generic). Parameter descriptions exist but are often minimal. Output schemas are NOT documented, critical gap. Error handling is inferred but not visible in the tool definitions. Security considerations (like assembly loading in analyzer_load) lack explicit constraint documentation. The AI-powered tools (ask_codebase, ai_suggest_fix, ai_refactor, ai_implement_feature) have unusually verbose, helpful descriptions (200-400 chars each) that stand out positively, but most analyzer and bulk edit tools lag behind. Tools like bulk_replace, conditional_edit, and batch_refactor lack detail on how failures are handled or what the output structure is.
AI implements a feature using Roslyn AST-based code generation. **IMPORTANT: This tool generates syntactically correct C# using Roslyn.** Unlike template-based generation or string concatenation, this tool: - Generates valid, compilable C# code - Integrates properly with existing code structure - Maintains consistent formatting and style - Uses AST nodes, not text templates ALWAYS use this tool instead of generating code via string manipulation. Examples: - "Add a caching layer to this service" - "Implement validation for user input" - "Add logging to all public methods" Returns generated code for review before applying.
AI-guided refactoring using Roslyn semantic transformations. **IMPORTANT: This tool uses Roslyn's semantic model for safe refactoring.** Unlike manual text editing or regex-based tools, this approach: - Preserves program semantics and behavior - Ensures code compiles after transformation - Maintains type safety and references - Uses AST-aware transformations, not text manipulation ALWAYS use this tool instead of manual refactoring or text-based tools. Examples: - "Extract duplicate code into a shared method" - "Simplify this method using modern C# idioms" - "Improve error handling in this class" Returns a preview with explanation of the refactoring.
AI suggests a bug fix using Roslyn AST transformations. **IMPORTANT: This tool uses Roslyn AST transformations to ensure correctness.** Unlike sed scripts, regex replacements, or Python text manipulation, this tool: - Guarantees syntactically valid C# code - Preserves compilation integrity - Maintains code structure and formatting - Validates changes before returning them ALWAYS prefer this tool over text-based manipulation for code fixes. Examples: - "Fix the null reference exception in ProcessData method" - "Fix the memory leak in the cache manager" - "Correct the logic error in ValidateUser" Returns a preview of changes that can be reviewed before applying.
Output schemas not documented. Tools return data but LLMs cannot plan downstream calls without knowing result structure (e.g., what fields are in fix objects, what does bulk_replace return on success).
Parameter descriptions are minimal (15-30 chars) for many tools. 'Pattern to match for condition' and 'Replacement text' lack detail on format, escaping, and valid values. LLMs cannot self-correct invalid patterns without actionable error messages paired with constraint documentation.
Error handling not documented. Tools like analyzer_load accept a 'validate_signature' boolean but descriptions do not explain what happens on validation failure, whether the error is retryable, or how to recover. analyzer_apply_fixes mentions rollback but doesn't explain failure scenarios.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Apply fixes for analyzer issues with conflict resolution and rollback
Configure analyzer settings and rule preferences
Get history of applied fixes with rollback information
Get available fixes for specific analyzer issues
Get health status and metrics for analyzers
List all available analyzers, with optional filtering
Load an analyzer from an assembly file with security validation
Rollback previously applied fixes using backups
Run analysis on specified files using an analyzer
Unload an analyzer and clean up resources
Ask natural language questions about the codebase using AI-powered semantic analysis. PREFERRED for high-level exploration and understanding before diving into code details. Use for architectural questions, feature location, and design understanding. Examples: - "How does authentication work in this project?" - "Where are database migrations defined?" - "What would break if I rename UserService?" - "Which files handle user registration?" Returns focused answers with file:line references. More efficient than using multiple low-level tools for initial exploration. Use this first to understand the landscape, then use specific semantic tools (find_symbol, get_class_structure) for detailed analysis.
Perform pattern-based code refactoring across multiple files
Perform regex search and replace across multiple files in parallel
Transform multiple files in bulk with parallel processing
Edit files based on content conditions (e.g., file contains specific text)
Get the schema of a configuration file (JSON/YAML)
Get progress information for a streaming operation
Merge multiple configuration files
Process a file using streaming operations with configurable chunk size and progress tracking
Security risk: analyzer_load accepts assembly_path and validate_signature. No documentation on path traversal protection, signature validation details, or sandboxing. LLMs could be tricked into loading untrusted code. Also, this tool description does not warn about destructive potential or require confirmation.
Batch tools (bulk_replace, conditional_edit, batch_refactor) lack per-item success/failure reporting. If one file fails during bulk processing, LLMs cannot know which files succeeded and which failed, forcing full retry instead of recovery.
Pagination and result limits not documented. stream_process_file and bulk_transform accept file patterns and processorOptions but do not specify limits on file count, chunk size constraints, or pagination behavior. Large file sets could exhaust context or cause timeouts.
Idempotency not declared. Tools like analyzer_apply_fixes and bulk_replace modify files but do not state whether repeated calls with identical params are safe. Agents retry on ambiguous failures, non-idempotent tools risk duplicate fixes or duplicate replacements.
Confirmation/dry-run pattern missing. Destructive tools (analyzer_apply_fixes, bulk_replace, analyzer_unload) accept an action directly without preview or confirmation. No mention of previewMode helping (only bulk_replace has this). Agents can apply fixes or deletions without review.