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
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.5 / 30
03Economics
12.3 / 20
04Discoverability
11.0 / 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.
8 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
create_standing_order |
create_monitored_area |
high | Both create continuous watches over a bbox ('keep an eye on this area' / 'monitor this region'); distinguishing event-based alerting from quantity-over-time measurement requires reading deep into descriptions, and create_monitored_area's own text explicitly warns of this overlap ('...rather than about events, which is create_standing_order'). |
search_imagery |
plan_event_imagery |
high | A task like 'get me satellite imagery for this event/disaster' fits both — search_imagery is the manual bbox/date catalog search while plan_event_imagery is the event_id-driven deterministic dual-sensor plan; plan_event_imagery's own description says to prefer it 'over several search_imagery calls for the same event,' showing real functional overlap an agent could resolve either way. |
list_monitored_areas |
get_monitored_area |
medium | A request like 'how is the monitored area near X trending' could be served by either the summary list (most recent value + change) or the single-area full time series; only the phrase 'history/time series' cleanly disambiguates, so an agent scanning quickly could pick the wrong one. |
list_standing_orders |
list_monitored_areas |
medium | 'Show me what I'm watching/monitoring' is ambiguous between event-based standing orders and quantity-based monitored areas — both are 'list my watches' style calls with near-identical phrasing in the request, differentiated only by the underlying watch semantics. |
query_signals |
query_hotspots |
medium | A task like 'what's happening in this region' could plausibly be answered by either the filtered event list (query_signals) or the density-ranked geographic grid (query_hotspots); both accept the same bbox/date/category filters, so the choice hinges on subtle 'rows vs WHERE concentration' framing that's easy to miss. |
query_signals |
query_stats |
medium | 'How many kinetic events occurred in this area' could be answered via query_stats's aggregate total or by calling query_signals and counting/paging rows; both share the same filter schema, making the cheaper aggregate tool easy to overlook in favor of the more general query_signals. |
query_stats |
query_hotspots |
medium | Both are cheap aggregate/roll-up tools over the same bbox+date+category filters ('summarize activity here') — one gives category/day trend counts, the other geographic density bins — so a vague summarization request could be routed to either. |
query_signals |
assess_signal |
medium | A request like 'assess the situation at this location' could trigger a fresh query_signals search or assess_signal's AI deep-dive on an already-known event id; the shared 'signal' terminology and overlapping collection/GEOINT vocabulary make it plausible an agent invokes the wrong one when eventId isn't yet clearly established. |
Compare the field