Loading ToolBench
A collection of MCP servers providing C# compilation/execution, image-to-diagram conversion, and workflow visualization tools
This C# MCP server provides 8 tools with mixed quality. Tool definitions are visible and mostly have descriptions, but descriptions are often generic, parameter documentation is inconsistent, and output schemas are rarely documented. The server handles specialized domains (C# compilation, sandboxing, image-to-diagram conversion, workflow visualization) but lacks the rigor expected of production tools. Parameter descriptions are present but brief. Input schemas are partially visible via source code inspection. The tools lack explicit enums for constrained inputs, error guidance is minimal, and output structures are underspecified. Naming is reasonably clear (verb-noun pattern mostly followed), but schemas lack comprehensive documentation.
Compiles a C# class and returns errors if any
Converts an image to a Mermaid diagram
Converts an image from a URL to a Mermaid diagram
Echoes a message back to the client
Executes C# code in a secure sandbox environment
Gets the local time of the server
Gets the current timestamp
Output schemas are not documented. Tools like ExecuteCSharp, ConvertBase64ImageToMermaid, and WorkflowToMermaid return complex types (CompilationResult, string diagrams, JSON) but LLMs cannot infer the response structure from code. No return-type documentation visible in descriptions or schema definitions.
Parameter 'diagramType' in image-to-diagram tools lacks enum constraints. Description says '(flowchart, sequence, class, etc.)', a hint that looks like examples, not a formal constraint. LLMs will hallucinate invalid values like 'bar-chart' or 'timeline'. Should be an explicit enum: [flowchart, sequence, class, state, deployment, git].
Error handling does not guide recovery. CompileCSharpClass returns a CompilationError array on failure, but descriptions offer no guidance on interpreting error codes (e.g., 'CS0103') or what action the LLM should take next. ExecuteCSharp's error path is unclear (result assignment in error callback appears incomplete).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Converts a workflow to a Mermaid diagram
Cancellation token parameter exposed in schema. ConvertBase64ImageToMermaid, ConvertImageToMermaid, and WorkflowToMermaid accept a 'cancellationToken' parameter typed as 'object' with description 'A token to cancel the operation.' LLMs cannot construct or reason about .NET CancellationToken objects. This should be server-internal, not exposed as a parameter.
Tool descriptions are too generic. 'Echoes a message back to the client' (Echo), 'Gets the local time of the server' (GetLocalTime), 'Gets the current timestamp' (GetTimestamp) lack context on when to use them vs. similar tools and what they return. Average baseline is 194 chars; most here are <50 chars.
ExecuteCSharp implementation is incomplete. SandboxTools.ExecuteCSharpAsync() assigns compilation result in the error callback but the method always returns CompilationResult (originally null, then possibly overwritten). The logic appears broken: 'result = r' in the error handler, then 'return Task.FromResult(result)', if result stays null, it returns null.
Timeout parameter lacks validation. ExecuteCSharp accepts 'timeout' as an unbounded integer with description 'Timeout in milliseconds (default: 10000)'. No min/max specified. LLM could pass 1000000 (16+ minutes) or negative values, causing hang or error. Should constrain: 100 - 300000 ms.
No input validation or actionable error messages. Tools accept free-form strings (code, imageData, workflowJson) without validation. If LLM passes invalid C# or malformed Base64, errors are likely API-level (compile error, decode failure) with no guidance on correction.