Loading ToolBench
MCP server exposing Godot to AI coding assistants over the Model Context Protocol — developed and tested with Claude — across four planes (CLI, live editor, LSP+DAP, runtime) with elicitation-gated destructive tools, long jobs on the formal MCP task model, captured console output, and MCP resources.
Breakpoint-mcp registers 15 tools with varying quality. While tool names follow verb_noun convention (godot_run_project, cs_dbg_set_breakpoints), most tool definitions lack critical documentation. Input schemas are partially visible in the assessment but parameter descriptions are minimal or absent in source code. Descriptions exist but are brevity-focused and often under 50 characters. The server demonstrates sophisticated domain modeling (Godot debugging, C# runtime introspection) but falls short of production-grade tool definition standards. Source inspection of host/src/tools/cli.ts and host/cs_demo_debugger_live.mjs shows tool registration but limited inline schema documentation. The codebase includes a tools.ts CLI artifact that exports tool metadata, suggesting definitions exist in toolsets.ts and annotations.ts, but those files are not provided for validation. Based on visible evidence only: descriptions are terse, parameter constraints are not articulated in tool metadata, and error recovery guidance is absent.
Continue execution in the C# debugger
Evaluate an expression in the C# debugger at the current frame
Launch the C# debugger on the Godot project
Get variable scopes for a stack frame in C# debugging
Set breakpoints in C# code for the debugger
Get the call stack from the C# debugger
Step through C# code in the debugger
Critical: Two tools (godot_run_project, cs_dbg_continue) have no visible input schemas; five tools show incomplete schemas missing parameter type definitions. Per HARD SCORING RULES, tools with no schema must score 0 for schema component.
High: Tool descriptions are uniformly brief (under 50 characters, often 25-45). Example: 'Launch the Godot project in headless mode' does not explain when to use it vs godot_run_managed, whether it persists state, or what 'headless' blocks.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2025-06-18+ | v2 |
Get variables in a scope from C# debugging
Capture console output from a running Godot process
Run a Godot scene as a managed process with captured console output
Launch the Godot project in headless mode
Stop a running managed Godot process
Assert the state of a node in the running game matches expected values
Assert that text appears on the screen in the running game
Read a property from a node in the running game
High: Parameter descriptions are minimal or absent. Visible schemas (e.g., godot_run_managed, runtime_assert_node_state) include type and name but lack contextual descriptions. Per pattern:tool-description, 100% of A+ tools have descriptions for all params. Absence forces LLMs to guess meaning.
High: Error handling and recovery guidance absent from visible tool definitions. No indication of which errors are retryable, user-fixable, or fatal. Per pattern:recovery-guide, error responses must guide LLM next steps. Example: if cs_dbg_launch fails, should the agent check Godot installation? Retry the debugger? Call a different tool?
Medium: Output schemas not documented in visible source. Pattern:tool-definition requires documentation of what each tool returns. Without it, LLMs cannot plan downstream tool calls or extract needed data. Example: godot_output returns 'captured console output' but structure (array of lines? string? with timestamps?) is unclear.
Medium: Tool naming uses prefixes (godot_*, runtime_*, cs_dbg_*) that group by domain but do not always clarify action vs discovery vs assertion. 'runtime_assert_node_state' vs 'runtime_assert_screen_text' both assert but on different resources, the names do not make the distinction obvious enough. Per review:name-clarity, similar names cause LLM conflation.
Medium: Elicitation gating is implemented (cs_dbg_evaluate accepts a 'confirm' parameter per source) but not all destructive tools appear to gate confirmation. godot_stop, cs_dbg_step, and cs_dbg_continue modify debugger state but no 'confirm' parameter is visible. Per pattern:confirmation-request, irreversible ops should support user confirmation.
Low: Parameter constraints (enums, ranges, patterns) are not evident in visible schema snippets. E.g., 'cs_dbg_step' has a 'kind' param described as 'into', 'over', or 'out' but no enum constraint is shown. Per pattern:constrained-input, enums prevent hallucinated values.