Loading ToolBench
MCP server providing C# code refactoring tools for automated method extraction, static conversion, extension methods, constructor injection, and code analysis
RefactorMCP is a C# domain-specific refactoring tool server with 14 tools. Strengths: all tools have descriptions and properly typed input schemas with descriptions. Critical weaknesses: (1) STDIO-only transport caps overall value; (2) tool names are kebab-case but lack clarity in verb structure, e.g., 'add-observer', 'convert-to-constructor-injection', 'convert-to-static-with-instance' are overly specific and make it hard for LLMs to infer intent from name alone; (3) output schemas are entirely undocumented, tools return free-form strings or complex objects with no declared shape; (4) no error handling guidance, exceptions are caught but responses don't tell agents how to recover; (5) no tool annotations (readOnlyHint, destructiveHint) despite clear READ_ONLY vs WRITE risk profiles; (6) descriptions lack WHEN/WHY context, they state what a refactoring does, not when an agent should choose it over alternatives. Average per-tool score: 48.
Introduce a simple observer event and raise it in a method
Analyze a C# file for refactoring opportunities like long methods or unused code
Remove unused using directives from a C# file (preferred for large C# file refactoring)
Clear all cached solutions
Convert method parameters to constructor injection (preferred for large C# file refactoring)
Convert an instance method to an extension method in a static class. A wrapper method remains so existing call sites continue to work. The extension class will be automatically created if it doesn't exist.
Transform instance method to static by adding instance parameter (preferred for large C# file refactoring)
Output schemas completely undocumented. Tools return raw strings or structured objects (e.g., 'Successfully loaded solution...', refactoring analysis results) with no declared return type, fields, or structure. LLMs cannot parse or chain outputs without guessing.
Tool names lack clear action verbs and are overly specific. E.g., 'convert-to-static-with-instance' vs 'convert-to-static-with-parameters' are nearly identical and force LLMs to reason about subtle differences. Names like 'add-observer' don't signal intent clearly. Recommend refactoring to shorter, verb-driven names: 'refactor-method', 'extract-method', 'inject-dependency'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Transform instance method to static by converting dependencies to parameters (preferred for large C# file refactoring)
Generate a simple adapter class that delegates to an existing method
List all classes in the solution with their line counts
List all available refactoring tools
Start a new session by clearing caches then load a solution file and set the current directory
Unload a solution and remove it from the cache
Show the current version and build timestamp
No error handling guidance. Exceptions are caught (e.g., McpException in load-solution) but error responses don't tell agents what to do next. No recovery hints, retryability classification, or alternative suggestions. E.g., if a file is not found, the agent doesn't know whether to try a different path, list available solutions, or give up.
Missing tool annotations despite clear risk profiles. All WRITE tools (load-solution, add-observer, cleanup-usings, etc.) should declare destructiveHint=true. All READ_ONLY tools should declare readOnlyHint=true. Annotations help agents reason about safety and side effects.
Descriptions lack WHEN/WHY context. E.g., 'Analyze a C# file for refactoring opportunities like long methods or unused code' explains WHAT but not WHEN to use it vs other tools, or what the agent should do with the results. Descriptions should answer: When is this preferable? What is the output format?
Complex parameter relationships undocumented. E.g., 'convert-to-constructor-injection' takes methodParameters as 'Method:Parameter;...' format, a freeform string requiring manual parsing. This should be an array of objects {methodName, parameterName} with examples or validation hints.
Optional parameters like 'extensionClass' in 'convert-to-extension-method' lack clarity on default behavior. Description says 'optional, class will be automatically created if it doesn't exist or is unspecified' but doesn't clarify naming convention or where the class is created.