01Safety
0.0 / 30
What changed in the harness
Selection accuracy 88→90, token cost up 6%, 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
26.4 / 30
03Economics
20.0 / 20
04Discoverability
13.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.
3 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 |
|---|---|---|
esim_get_plan |
no_return_description |
Fetch the full detail of one plan by its slug. Returns the matched plan over its full detail, including all of its variations — each variation is one specific days × GB × price combo — so the caller can identify the exact variation_id to purchase. |
esim_create_order |
no_return_description |
Create a pending order and return the created order, which includes its order_id and order_token along with payment details. With `payment_method: "stripe"` (default) the order includes a `payment_link_url` — present it to the user to tap and pay on Stripe's hosted page. With `payment_method: "btc"` the order includes a `btc` block (on-chain address + amount + QR data URI + expiry) — present the address and amount to the user to pay from any Bitcoin wallet; no redirect. If the user hasn't said how they want to pay, ask: card or Bitcoin. The eSIM QR code arrives at `email` within ~30 seconds of payment clearing. Use `esim_check_order`, passing the returned order_id and order_token, to poll status. |
esim_check_order |
params_unexplained |
Poll an order's status. Pass the numeric order_id (the identifier of the order to check) and order_token (the opaque token returned by esim_create_order) for the order you created. Returns `status: pending` while waiting for payment, `status: processing` or `completed` once paid, with `activation` data (ICCID, QR URL, install instructions). |
Selection evidence
Confusable tool pairs.
3 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
esim_search_plans |
esim_get_plan |
medium | Both concern the same catalog and both descriptions mention variations and filters. A task phrased generically as 'get me plans for Spain' or 'what plan options are available with 10 days/5GB' could route to esim_get_plan (by slug) when search_plans is the correct first call, or vice versa when the user says 'get the plan details'; the agent must infer whether the user wants a filtered search result set or a full single-plan variation dump. |
esim_create_order |
esim_check_order |
medium | Both names share 'esim' and 'order' and are related in the same purchase flow. Natural wording like 'check out my eSIM' or 'I want to check on my order' can map to the wrong tool — 'check' suggests check_order while 'checkout/pay' or 'order an eSIM' suggests create_order; the agent must decide between placing an order versus polling its status. |
esim_search_plans |
esim_create_order |
low | A task like 'I want to order an eSIM plan for Japan' uses the verb matching create_order, but the correct workflow starts with esim_search_plans to obtain a variation_id. An agent could prematurely select create_order on the strength of the 'order' intent before searching the catalog, a plausible but less common mix-up since create_order's required variation_id dependency usually reveals the error. |
Compare the field