01Safety
0.0 / 30
What changed in the harness
Selection accuracy 98%, destructive-action safety rate 0% (baseline only -- no rewrite pass applied).
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
27.9 / 30
03Economics
12.8 / 20
04Discoverability
12.6 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
0 defects found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
| No description defects were flagged in this assessment. | ||
Selection evidence
Confusable tool pairs.
6 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
detach_project |
stop_project |
high | Both tear down MCP bridge/runtime state, and stop_project's description explicitly handles attached sessions ('for attached sessions, this detaches without killing the externally launched process'), mirroring detach_project. A task like 'clean up / close the running project session' is therefore ambiguous about whether the process was spawned or externally launched, so the agent can pick the wrong cleanup call. |
run_project |
run_script |
medium | Both are 'run' tools taking project context. A task like 'run this script' or 'execute the project's script' is ambiguous: run_project spawns the whole project (main scene), while run_script executes inline GDScript against a live session — an agent may pick run_project when the user meant execute GDScript, or vice versa when a script needs the running project. |
get_node_properties |
get_node_signals |
medium | Both are node-introspection reads taking identical scenePath/nodePath inputs. A task like 'inspect this node' or 'what does this node expose' plausibly maps to either (property values vs. defined signals/connections), and the shared 'get_node_*' naming form adds to the ambiguity. |
get_scene_dependencies |
get_scene_tree |
medium | Both inspect a scene's contents under 'get scene', and both descriptions mention scripts among what is returned. A task like 'show me what this scene contains/references' could be answered by either the ext_resource dependency list or the node hierarchy tree depending on the user's intent. |
get_project_info |
get_project_files |
medium | Both describe inspecting project structure: get_project_info returns a structure summary (counts of scenes/scripts/assets) while get_project_files returns a recursive file tree. A task like 'show me the project structure/contents' fits either tool, so the agent may select the wrong one. |
get_project_info |
get_project_settings |
low | A task like 'get the project's configuration/version/settings' overlaps both — get_project_info gives metadata (name, version, structure) and get_project_settings parses configured project.godot sections — though specific wording usually disambiguates. |
Compare the field