Loading ToolBench
A .NET debugger MCP server that launches and debugs .NET projects, providing breakpoint management, watch expressions, exception diagnostics, and real-time execution tracing.
OrangeCandy provides 20 well-intentioned debugging tools with explicit schemas and descriptions. However, critical gaps limit production readiness: (1) Most parameter descriptions lack format/constraint details (e.g., 'file' path format, 'line' number bounds). (2) Output schemas are not documented, callers cannot predict response structure. (3) Error handling is minimal; tools return generic errors without recovery guidance. (4) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear read/write semantics. (5) Descriptions average ~100 chars but lack WHEN-to-use context. Naming is strong (verb_noun pattern, clear intent), and schemas are present with types, but lack the rigor expected of production tools.
Add a watch expression that gets evaluated at every debug stop. Returns the watch ID.
Continue execution until next breakpoint, exception, or exit. Returns a full debug snapshot with locals, call stack, and source context.
When stopped on an exception, answers 'what went wrong?' — returns exception type, message, stack trace, locals at crash, and inner exceptions.
Get the execution flow: sequence of stops with function names, files, lines, and stop reasons.
Get all watch expressions and their current values.
Get the history of debug stops with snapshots.
Launch a .NET project under the debugger. Returns a debug snapshot at the entry point.
Output schemas not documented. Tools return complex objects (snapshots, records, traces) but callers cannot predict field names, types, or structure. LLMs cannot plan downstream calls or extract required data.
Parameter descriptions lack format/constraint details. 'file' has no path format guidance; 'line' has no bounds (1 - 999999?); 'expression' has no C# syntax constraints. LLMs cannot validate inputs before calling.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked READ_ONLY or WRITE in metadata but not in schema. LLMs cannot infer safety/idempotency from tool definitions alone.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | <=2025-11-25 | v2 |
Search the observation trace for method calls matching a pattern.
Start observing method calls and returns in the debugged application.
Stop observing method calls and returns.
Get the trace of observed method calls.
Get captured program output (stdout, stderr, console).
Remove a watch expression by ID.
Restart the current debug session. Kills the running process, rebuilds, and relaunches with optional new args. Returns a debug snapshot at the entry point.
Get current session state: project path, args, stop count, breakpoints, and current snapshot.
Set a breakpoint at a file and line.
Show source code context around a file and line.
Show the snapshot at a specific stop index.
Stop the debug session and terminate the process.
Get the timeline of all debug events (launches, stops, actions, output).
Error handling lacks recovery guidance. Tools return generic errors (e.g., 'no active debug session') without suggesting next steps. LLMs cannot self-correct or plan recovery.
Descriptions lack WHEN-to-use context. 'Get the history of debug stops' does not explain when to call history vs timeline vs flow. LLMs must guess which tool fits the user intent.