01Safety
0.0 / 30
What changed in the harness
Selection accuracy 85→94, token cost down 0%, unconfirmed writes 0%→0%.
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
26.0 / 30
03Economics
16.5 / 20
04Discoverability
11.3 / 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.
2 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 |
|---|---|---|
toolfunnel_tool_instructions |
no_return_description |
Get the full usage instructions / documentation for one tool by name (venv, the reliable invoke command, safety notes). Read this before running the tool yourself. Returns a text document with setup and invocation instructions for the named tool, or an error if the tool name is not found. |
toolfunnel_howto |
no_return_description |
Get self-extension instructions: how to author a new tool, register an upstream MCP, add a hook, build a shareable package, WRAP one MCP server as the entire surface (transparent passthrough), or configure the gateway with JSON files only. The system documents how to extend itself. Returns a text guide corresponding to the requested topic (create-tool, add-mcp, add-hook, package, wrap, or configure). |
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 |
|---|---|---|---|
toolfunnel_list_tools |
toolfunnel_tool_instructions |
medium | A task like 'find out about the X tool' could lead an agent to call list_tools (browsing/filtering) instead of tool_instructions (full docs for a named tool), especially if the tool name is already known and the agent conflates 'listing' with 'getting details'. |
toolfunnel_tool_instructions |
toolfunnel_run_tool |
low | Both require a 'name' param and are sequential steps in the same workflow (read instructions, then run), but their verbs (get instructions vs execute) are distinct enough that confusion is unlikely except in rushed one-shot phrasing like 'use tool X to do Y', where an agent might skip straight to run_tool anyway (which is the correct behavior, not confusion). |
toolfunnel_list_tools |
toolfunnel_run_tool |
low | Different verbs (list vs execute) and different schemas make confusion unlikely; a request to 'use a tool for X' would naturally map to run_tool, not list_tools. |
toolfunnel_list_tools |
toolfunnel_howto |
low | Both could be invoked for a vague 'what tools/capabilities are available' query, but howto is scoped to self-extension topics (create-tool, add-mcp, etc.) via an enum, making misselection unlikely once the agent reads descriptions. |
toolfunnel_run_tool |
toolfunnel_howto |
low | A request like 'register a new tool' could theoretically be misrouted to run_tool if the agent thinks 'register' is itself a tool to run, but howto's distinct enum-based schema for self-extension guides reduces this risk. |
toolfunnel_tool_instructions |
toolfunnel_howto |
low | Both return instructional/documentation content, but tool_instructions is scoped to a specific existing tool by name while howto covers meta/self-extension topics from a fixed enum, so a clear request naming a tool vs a topic like 'add-hook' should disambiguate easily. |
Compare the field