01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100%, destructive-action safety rate 0% (baseline only -- no rewrite pass applied).
Category breakdown
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
0.0 / 30
29.6 / 30
20.0 / 20
10.0 / 20
Highest-impact fix
Estimated gain +30 pointsExpose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
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
2 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
purroxy_list_capabilities |
purroxy_run_capability |
medium | A task like 'use Purroxy to list my transactions/invoices' matches the word 'list' in list_capabilities, even though the correct tool is run_capability (which returns extracted data), not the metadata listing. Both share capability names/parameters in their descriptions, so a user phrasing a data-retrieval request as 'list X via Purroxy' could plausibly route to the wrong member. |
purroxy_list_capabilities |
purroxy_status |
low | Queries about availability/count, e.g. 'how many automations does Purroxy have?' or 'is Purroxy available?', are ambiguously served by status, which reports connection status and the number of available capabilities, versus list_capabilities, which returns the full details. Mostly distinct (status = connectivity, list = catalogue), but the shared 'capabilities available' framing creates a slight overlap. |
Compare the field