01Safety
30.0 / 30
What changed in the harness
Selection accuracy 100%, destructive-action safety rate 100% (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.2 / 30
03Economics
20.0 / 20
04Discoverability
10.4 / 20
Highest-impact fix
Estimated gain +10 pointsMake target tools discoverable on the first call
Clarify tool names, decision boundaries, and required argument schemas so an agent can choose and construct the target call without exploratory steps.
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 |
|---|---|---|---|
get_endpoint |
get_schema |
medium | A task like 'show me the schema for creating an order' is ambiguous: get_endpoint returns the request/response schemas for one endpoint, while get_schema returns the field tree of a named data model. The near-identical get_ names and the fact that endpoint detail includes 'schema' make the wrong pick genuinely plausible. |
list_endpoints |
search_endpoints |
high | A task like 'find the endpoint for placing an order' fits both tools: list_endpoints (optionally filtered by category) and search_endpoints keyword search both advertise being the way to locate endpoints. Since the inputs differ (category vs free-text query), an agent can genuinely pick the wrong one to answer the same natural-language query. |
search_endpoints |
get_endpoint |
medium | 'Get me the create order endpoint and its parameters' is ambiguous: search_endpoints finds matches from a query, while get_endpoint returns full detail if the agent guesses the operationId/method+path. A user wanting one endpoint's detail could send the agent to either tool, and both descriptions emphasize summary/description matching. |
list_endpoints |
get_endpoint |
medium | Both names say 'endpoint' and both respond to 'show me endpoints for orders'. A singular-detail phrasing ('show me the place-order endpoint') can collide with a browsing phrasing ('show me order endpoints'), and list_endpoints' per-endpoint summaries overlap with get_endpoint's returned summary, so an agent may stop at the wrong one. |
list_schemas |
get_schema |
medium | 'List the fields of the Order schema' or 'show me the order schema' is ambiguous: an agent may call list_schemas (which only returns names) thinking it surfaces the model, or attempt get_schema (which needs an exact name) against a vaguely-phrased request. The list/get pair and shared 'schema/data/model' tokens make the wrong selection plausible. |
get_api_overview |
get_integration_guide |
medium | Starting/orienting tasks like 'give me an overview of this API' or 'how do I get started with trading' fit both: get_api_overview is the START HERE map, while get_integration_guide is the task-oriented walkthrough. Both are orientation tools with only 'get' shared, so an agent could pick the guide when an overview was wanted and vice versa. |
Compare the field