01Safety
0.0 / 30
What changed in the harness
Selection accuracy 100→100, token cost up 2%, 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
27.2 / 30
03Economics
12.9 / 20
04Discoverability
19.3 / 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.
6 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 |
|---|---|---|
optimize_contextual |
params_unexplained |
Select the best option from the candidate arms you supply (arms must contain at least 2 options, each with an id and name) for a given numeric context/feature vector, using a LinUCB contextual bandit that learns per-context preferences from optional history. Use when the best choice changes with situational features that vary call-to-call (user/segment attributes, time of day, current regime). Returns the chosen arm with its LinUCB expected reward and confidence width. If you have no per-call features, use optimize_bandit. |
solve_constraints |
params_unexplained |
[Premium] Solve a linear / mixed-integer / quadratic program with the HiGHS solver and return a provably optimal assignment. Set direction to 'maximize' or 'minimize', specify the objective as a map of variable name to coefficient, declare each variable with a name plus optional lower/upper bounds and type (continuous, integer, or binary; default continuous), and define constraints by name with a coefficients map and optional lower/upper bounds. Use when your objective and constraints are linear (or quadratic) over named continuous/integer/binary variables: budget allocation, supply or capacity planning with integer counts, allocation with hard caps. Returns solver status (optimal/infeasible/unbounded), the objective value, and the solved value per variable. Use optimize_cmaes for black-box objectives and solve_schedule for task-to-slot assignment. Premium: needs an ORACLAW_API_KEY OR a per-call x402 payment (no signup). |
solve_schedule |
params_unexplained |
Assign the tasks you pass in (each with id, name, durationMinutes, priority, and energyRequired, plus optional deadline/category) to the slots you pass in (each with id, startTime as a Unix timestamp in ms, durationMinutes, and energyLevel) to maximize total score by matching each task's energy requirement to a slot's energy level (and respecting duration). Use for deep-work blocking, shift or session planning, or any task-to-slot fit where high-energy work should land in high-energy slots. Returns the assignments, any unassigned task IDs, and a total score. For arbitrary linear constraints use solve_constraints; for routing use plan_pathfind. |
analyze_graph |
params_unexplained |
[Premium] Compute structural metrics of a directed weighted graph. Build the graph with nodes (each requires an id; type/label/confidence are optional) and edges (each requires source and target; weight/type are optional), then receive PageRank centrality, Louvain community clusters, an optional critical path between two given nodes, and bottleneck nodes. Use to find the most influential nodes, cluster a dependency/knowledge graph, or locate chokepoints in supply or process networks. Returns per-node PageRank and community index, cluster summaries, the critical path with its weight, and bottlenecks. For a single source-to-goal route, use plan_pathfind (free). Premium: needs an ORACLAW_API_KEY OR a per-call x402 payment (no signup). |
plan_pathfind |
params_unexplained |
Describe the graph in nodes (each with an id and optional cost/time/risk values) and edges (each with from/to and optional cost/time/risk), then find the shortest path (or k-shortest paths) between the given start and end node in the weighted directed graph using A* with selectable heuristic (zero=Dijkstra, time, cost, risk, weighted) and Yen's algorithm for alternatives. Use for routing, dependency resolution, or 'how do I get from X to Y' over a graph; set kPaths>1 for alternatives. Returns the path node IDs, total cost, a time/cost/risk breakdown, nodes explored, and a found flag. For centrality/communities use analyze_graph; for task-to-slot assignment use solve_schedule. |
optimize_evolve |
params_unexplained |
Run a genetic algorithm over a fixed-length gene vector against a weighted-sum fitness, with an optional Pareto frontier for multi-objective runs. Optionally constrain the genes with bounds (min/max per gene, plus a type of binary, integer, real, or permutation; default real). Use for discrete or mixed search spaces (feature selection, integer allocation, permutation/TSP-style problems) or when you want several non-dominated solutions. Returns the best chromosome and fitness, the Pareto frontier when applicable, the convergence generation, total generations, and recent fitness history; results vary run to run (stochastic). For smooth continuous objectives, use optimize_cmaes. |
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 |
|---|---|---|---|
optimize_bandit |
optimize_contextual |
medium | Both select the best option from 2+ discrete variants; a task like 'choose the best ad variant for this user' or 'pick the winning option now' is ambiguous because the agent must infer from context whether per-call context features (contextual bandit) or only arm pull/reward history (plain bandit) are meant, and both accept arms/output a chosen arm. |
optimize_cmaes |
optimize_evolve |
medium | Both optimize a weighted-sum objective over a parameter vector with stochastic, premium-framed runs; a task like 'optimize 10 parameters against a weighted objective' is ambiguous unless the search space is explicitly specified as smooth continuous (CMA-ES) vs discrete/binary/permutation genetic (evolve), so an agent can pick the wrong optimizer. |
predict_bayesian |
predict_ensemble |
medium | Both fold multiple weighted inputs into a single estimate; a task like 'combine these weighted probability estimates into one value' or 'fuse several signals into a revised prediction' could be read as Bayesian prior+evidence updating or weighted ensemble/stacking aggregation, since both take weighted inputs and return a combined number. |
score_convergence |
score_calibration |
medium | Both score collections of probability estimates; a task like 'score how well these probability estimates agree/match' is ambiguous between measuring agreement across multiple independent sources on one event (convergence) and measuring match to realized binary outcomes (calibration), especially when the user omits whether real outcomes exist. |
simulate_montecarlo |
simulate_scenario |
low | Both are 'simulate' tools over numeric inputs/outputs; a task like 'simulate what happens to my budget under different growth assumptions' could be read as random sampling from a parametric distribution with spread stats (montecarlo) or as named what-if overrides against a base case with sensitivity ranking (scenario), since users often say 'simulate scenarios' loosely. |
solve_constraints |
solve_schedule |
low | Both 'solve' assignment/allocation problems; a task like 'solve my task-scheduling problem with hard constraints' is ambiguous because solve_schedule is a specialized task-to-slot energy matcher while solve_constraints handles arbitrary linear/MIP/quadratic constraints, and a user may describe a scheduling or allocation problem without mentioning energy levels or slot timestamps. |
Compare the field