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
28.4 / 30
03Economics
14.2 / 20
04Discoverability
16.5 / 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.
5 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
foura_browser |
foura_auto |
medium | foura_auto is pitched as the default 'give it a URL and get the content back' tool that internally picks between HTTP, proxies, and a browser, while foura_browser is the explicit JS/DOM renderer. A task like 'fetch the rendered content of this SPA' fits both descriptions: an agent may route to auto (which can return an incomplete challenge page on JS-heavy sites) or to browser for a static page. |
foura_proxy |
foura_auto |
medium | Both handle protected/blocked targets through proxy rotation (auto even defaults forceProxy:true). A task like 'fetch this page, the site blocks scrapers' matches foura_proxy's rotating-retry description and auto's protected-target description about equally, so an agent can plausibly pick either and get different behavior (auto has no exitCountries control). |
foura_single |
foura_auto |
medium | Both accept url, method, headers, data, validate and return fetched content, and both claim ordinary 'fetch this JSON API / page' tasks. foura_single is the direct-HTTP tool while foura_auto is 'the default when you don't want to choose,' so a plain fetch task gives no definition-level signal about which control level the task expects, enabling misrouting. |
foura_proxy |
foura_browser |
medium | Both position themselves for protected content: foura_browser for 'supported browser challenges' and foura_proxy for 'blocked' targets with retry, and their descriptions cross-reference each other in a workflow (call foura_proxy first, pass its proxy ID to foura_browser). A task like 'fetch this Cloudflare/anti-bot protected page' lacks a definition-level cue for which protection type applies, so the agent can plausibly choose the wrong one. |
foura_single |
foura_proxy |
low | Both are HTTP request tools that accept a proxy parameter, so a task phrased as 'send this request through a proxy' could be misrouted to foura_single (which takes a proxy but does no rotation). However, the definitions explicitly redirect ('Switch to foura_proxy if the response is blocked', 'For rotation, use foura_proxy'), and country/rotation-specific tasks clearly point to foura_proxy, so confusion is only mildly plausible. |
Compare the field