01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, 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
27.7 / 30
03Economics
19.2 / 20
04Discoverability
16.8 / 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.
1 defect 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 |
|---|---|---|
forcedream_verify_proof |
no_return_description |
Return whether a ForceDream agent proof is authentic and untampered, using public-key cryptography. Provide a task_id (the proof is fetched from the public endpoint) or a full proof object to verify directly. Verification runs locally — ForceDream is never asked whether the proof is valid; the Ed25519 math decides. No account or key needed. |
Selection evidence
Confusable tool pairs.
7 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
forcedream_search_agents |
forcedream_invoke_agent |
medium | A request like 'use an agent to research X' or 'get me an agent that can do Y' is ambiguous between discovering agents (search) and running one (invoke); the agent may select discovery when execution was wanted, especially since both take vague query-style input. |
forcedream_search_agents |
forcedream_search_costs |
medium | Budget-aware phrasing such as 'find me a cheap agent' or 'which agents can I afford' maps to both: search_costs lists price_per_call with a max_price filter, while search_agents lists agents by capability; a task mentioning 'agents' plus a price constraint can pick the wrong one and miss the needed field. |
forcedream_search_agents |
forcedream_search_reliability |
high | Both expose the same success_rate data (search_reliability is explicitly the standalone extract of search_agents' health field), so a natural reliability query like 'which agent is most reliable' or 'search for agents with high success rate' is served by both definitions, making wrong selection very plausible. |
forcedream_search_reliability |
forcedream_search_providers |
medium | Performance/health phrasing such as 'what's the uptime' or 'how healthy is the system' is ambiguous between per-agent reliability (success_rate/latency) and inference-provider health (health_score/breaker_state/uptime), so a broad reliability task can route to the wrong one. |
forcedream_extract_data |
forcedream_generate_sentiment |
medium | Both analyze free text, and a task like 'extract the sentiment/opinion from these reviews' contains the trigger word 'extract' pointing at extract_data even though the actual need is sentiment scoring, which only generate_sentiment provides. |
forcedream_invoke_agent |
forcedream_score_lead |
medium | A task phrased as 'invoke/run the lead-score-v1 agent on this lead' matches invoke_agent by name and agent_slug inputs, even though the description says score_lead is the preferred dedicated tool; the agent can pick the generic invoker and submit the wrong schema. |
forcedream_invoke_agent |
forcedream_security_scan |
medium | A request like 'run security-scan-v1 against this code' surfaces both the generic invoke_agent (agent_slug based, with a note redirecting to the dedicated tool) and security_scan; the agent may choose invoke and lose the purpose-built scan schema and defaults. |
Compare the field