38 MCP tools: Rust computation, Discovery, composition, counterexample scans and signed checks.
Scored across 38 tools
The server offers many specialized tools, but several clusters overlap: planning/scheduling (build_robust_plan, improve_schedule, simulate_plan, plan_mission, optimize_tasks), observation/tracking (assimilate_observation, plan_observation, stress_test_observation, triangulate_tracks), and verification (verify_claim vs. check_*). Descriptions are detailed and help, but an agent could still misselect among related tools.
Tool names are consistently snake_case, with a dominant verb_noun pattern (e.g., analyze_chess_game, check_arithmetic, plan_mission). A few deviate to noun_noun (kepler_stability, network_status, route_optimizer, tour_profile) or insert 'the' (hear_the_shape, shape_the_sound), but these are minor deviations and do not break predictability.
With 38 tools, the server far exceeds the typical 3–15 range and the 25+ threshold that suggests over-scoping. While each tool may serve a distinct specialized purpose, the sheer number makes discovery and selection burdensome for an agent.
The tool surface spans a remarkably broad set of domains (chess, kinematics, statistics, planning, ephemeris, acoustics, networking, etc.) and includes lifecycle operations like listing capabilities, composing, executing, and verifying. Some gaps exist—e.g., no general data I/O or aggregation—but most apparent subdomains have multiple supporting tools.
Compare 4–40 supplied FEN positions and played SAN/UCI moves with Stockfish: first-choice agreement and centipawn loss. Entire analysis has a 25-second deadline; no cheating verdict.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | ||
| positions | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (read-only, idempotent, closed-world), so the description is free to add value — and it does: a hard 25-second deadline for the entire analysis and an explicit scope limit ('no cheating verdict'). Those are behavioral facts not derivable from the annotations or schema. Depth/cost trade-offs under that deadline are left unstated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense sentence front-loads the action, scope, engine, and outputs, with the operational constraint and disclaimer trailing. No filler; every clause carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter read-only analysis tool with no output schema, the description covers input shape, engine, metrics, and a critical time constraint. Missing: what the response looks like (per-position vs aggregate agreement/CPL) and how depth interacts with the deadline.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate: it does explain the positions array semantics (FEN + played moves, 4–40 count), which is the meaningful parameter. The depth parameter (4–20, default 12) and its accuracy/latency trade-off under the 25s deadline are never mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Compare) applied to a precisely-scoped resource (4–40 FEN positions with played SAN/UCI moves) using a named engine (Stockfish), yielding two named metrics. No sibling in the list does anything comparable, and an agent can distinguish it without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the input shape (supplied positions/moves) and the engine used, but says nothing about when to prefer this over alternatives or what conditions make it inapplicable. The 'no cheating verdict' note hints at a boundary but is framed as an output disclaimer rather than a use condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert angular speed and candidate distances to minimum transverse speeds; check a claimed speed-distance pair. Distance hypotheses are supplied, not measured; no object-origin conclusion.
| Name | Required | Description | Default |
|---|---|---|---|
| distance_max_km | No | ||
| distance_min_km | No | ||
| claimed_speed_kmh | No | ||
| claimed_distance_km | No | ||
| angular_speed_deg_per_s | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context beyond that: inputs are hypotheses rather than measurements, and the tool deliberately avoids object-origin conclusions. It does not discuss output format, but the annotations reduce the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no wasted words. The primary computation is front-loaded, followed immediately by the most important scope caveat about hypotheses and origin conclusions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only computational tool with no output schema and no parameter descriptions, the description provides purpose and scope caveats but omits return-value semantics. An agent knows what the tool computes, but not the exact output shape or how to interpret the minimum transverse speeds. This is minimally adequate but leaves clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With five parameters and 0% schema description coverage, the description must compensate. It names the core concepts—angular speed, candidate distances, and a claimed speed-distance pair—which maps to all five parameters collectively. However, it does not explain the distance_min_km/distance_max_km relationship or add semantic detail beyond what their names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific computational purpose: convert angular speed and candidate distances to minimum transverse speeds, and check a claimed speed-distance pair. It also distinguishes itself from origin-determination tools by saying 'no object-origin conclusion'. However, it does not explicitly differentiate itself from any named sibling, so it falls short of a full 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implied usage through the computation and caveats: distance hypotheses are supplied, not measured, and it does not conclude object origin. These are useful when-not signals, but no alternative tools or explicit selection guidance are provided, leaving usage largely inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refit original tracks plus one supplied new angular series, each counted once; compute the baseline natively. Declare synthetic/measured origin (unverified). Conditional uncertainty may worsen; forecast angles are not acquired evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | ||
| new_series | Yes | ||
| assumptions | Yes | ||
| data_origin | Yes | Origin declared by the caller; even measured is not independently verified or authenticated. | |
| observations | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| reasons | Yes | |
| forecast | Yes | |
| comparison | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| station_id | Yes | |
| data_origin | Yes | |
| limitations | Yes | |
| updated_fit | Yes | |
| baseline_fit | Yes | |
| new_series_id | Yes | |
| data_provenance | Yes | |
| contract_version | Yes | |
| new_angular_pairs | Yes | |
| input_angular_pairs | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real epistemic context – 'conditional uncertainty may worsen' and 'forecast angles are not acquired evidence' – but partly repeats the schema's note that declared origin is unverified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no obvious filler, but the front-loaded clause is jargon-heavy and the caveats are compressed into an elliptical style that costs clarity rather than saving space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, but for a tool with five required nested objects at 20% coverage the description should supply more parameter and sequencing context. The epistemic caveats help, yet a caller still cannot tell what objective, assumptions or observations must contain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% across five nested required parameters, so the description must carry meaning for objective, assumptions, new_series and observations. It only gestures at data_origin, which the schema itself already documents, leaving the other four parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action – refitting original tracks together with one new angular series – so the verb+resource is identifiable. However, phrasing like 'compute the baseline natively' and 'each counted once' is cryptic, and it never distinguishes itself from close siblings such as triangulate_tracks or stress_test_observation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus the many observation/track siblings, and no prerequisites or exclusions. The closest thing to guidance is 'Declare synthetic/measured origin', which is an input instruction, not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply necessary GRIM/GRIMMER checks to rounded means and sample deviations of bounded integer observations. Passing does not prove a dataset exists; inconsistency does not establish fraud.
| Name | Required | Description | Default |
|---|---|---|---|
| n | Yes | ||
| sd | No | ||
| mean | Yes | ||
| decimals | No | ||
| max_value | No | ||
| min_value | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuine interpretive context beyond structured fields: passing does not prove a dataset exists and inconsistency does not establish fraud, which shapes how an agent should report results. It still does not say what the check actually returns or which quantities drive a failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the operation and followed by the crucial interpretation caveat. Every sentence earns its place; nothing is redundant with structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, no-output-schema tool, the description covers purpose and interpretation but leaves gaps: no explanation of what a result looks like (pass/fail verdict, p-value), no guidance on n or the bounded-scale parameters, and no failure-mode detail. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning; it partially does by naming means, sample deviations, rounding, and bounded integer observations (mapping mean, sd, decimals, min_value/max_value). It never mentions n, the second required parameter, nor the meaning of decimals/min/max defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (apply checks) and resource (GRIM/GRIMMER consistency checks on rounded means and sample deviations of bounded integer observations), which is precise enough that an agent can tell it performs statistical consistency auditing rather than any sibling operation. Siblings are all unrelated domains, so no differentiation is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'apply necessary GRIM/GRIMMER checks to rounded means and sample deviations' – i.e., call this when you have a reported mean/sd/n from a bounded integer scale. However, there is no explicit when-to-use vs when-not guidance, no mention of prerequisites, and no routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare up to three task selections; choose highest examined value meeting the target under simultaneous 95% sampling bounds or an exact bound. Independent-uniform durations; can return inconclusive/blocked. Streams native events.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| items | Yes | ||
| budget | Yes | ||
| samples | No | ||
| uncertainty | Yes | ||
| allowed_tools | No | ||
| duration_model | No | independent_uniform | |
| max_candidates | No | ||
| min_success_rate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful traits beyond that: it can return 'inconclusive/blocked' results and it 'streams native events', which an agent could not learn from the annotations. It still omits what conditions cause a blocked outcome and what streaming implies for the caller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short and reasonably front-loaded, but the telegraphic, jargon-heavy style ('simultaneous 95% sampling bounds', 'Independent-uniform durations') costs clarity, and the trailing 'Streams native events' fragment feels appended rather than structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 9-parameter computational tool with no output schema and no schema descriptions, the description is too thin: it does not explain the required inputs (items, budget, uncertainty), the meaning of the sampling/model parameters, or the shape of the streaming result. Annotations cover safety but not the input/output contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 9 parameters, so the description carries the full burden and largely fails. It only obliquely maps to a few fields ('up to three task selections' roughly matches max_candidates=3, '95% sampling bounds' matches min_success_rate, 'independent-uniform durations' matches duration_model) while leaving required parameters items, budget, and uncertainty plus seed, samples, and allowed_tools entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description does convey a verb (compare/choose) and the core mechanism (selecting the highest-value task selection meeting a target under sampling bounds), so the general function is inferable. However, it is expressed in dense statistical jargon ('simultaneous 95% sampling bounds', 'independent-uniform durations') and never plainly says it builds/optimizes a plan from a list of candidate tasks under a budget. It also does not name or distinguish itself from close siblings like optimize_tasks, simulate_plan, or improve_schedule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no statement of prerequisites, and no routing to alternatives. Given several sibling planning/optimization tools (optimize_tasks, simulate_plan, plan_mission, improve_schedule), the absence of any disambiguation is a real gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check an explicit arithmetic claim. Checked i128 rationals give exact verdicts when expression, claim and tolerances are representable. Unsupported functions or overflow return an estimate with an undetermined verdict. Includes a versioned integrity digest; no checks of units or model meaning.
| Name | Required | Description | Default |
|---|---|---|---|
| values | No | ||
| expression | Yes | ||
| claimed_value | Yes | ||
| tolerance_absolute | No | ||
| tolerance_relative | No |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| scope | Yes | |
| digest | Yes | |
| engine | Yes | |
| method | Yes | |
| verdict | Yes | |
| statement | Yes | |
| comparison | Yes | |
| elapsed_ms | Yes | |
| expression | Yes | |
| provenance | Yes | |
| assumptions | Yes | |
| exact_value | Yes | |
| claimed_value | Yes | |
| absolute_error | Yes | |
| computed_value | Yes | |
| relative_error | Yes | |
| exact_supported | Yes | |
| contract_version | Yes | |
| tolerance_absolute | Yes | |
| tolerance_relative | Yes | |
| effective_tolerance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: exact vs estimated verdicts, the undetermined fallback condition, and a versioned integrity digest. It also discloses scope limits (no unit or model-meaning validation), which is genuinely useful for interpreting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense, front-loaded sentences with no filler; the core action leads and the caveats follow. It is efficient, though the final clause about units/model meaning is slightly compressed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and annotations carry the safety profile. However, with 5 parameters at 0% schema coverage, the description should say more about the values array and the two tolerance parameters to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters, and the description only gestures at 'expression, claim and tolerances' without explaining the values array, tolerance_absolute vs tolerance_relative, or any format/semantic details. It fails to compensate for the documentation gap it is the only source for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check an explicit arithmetic claim') and bounds the scope by declaring it does no unit or model-meaning checks. It is clearly distinct in kind from siblings like verify_claim, though it never names that sibling to sharpen the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through capability boundaries: representable i128 rational expressions yield exact verdicts, while unsupported functions or overflow fall back to an estimate with an 'undetermined' verdict. There is no explicit when-to-use-this-vs-verify_claim guidance or stated prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a claimed Sun (soleil) or Moon (lune) position for UTC time/location using NOAA/Meeus approximations and lunar parallax. Returns model-conditional angular consistency and lunar phase.
| Name | Required | Description | Default |
|---|---|---|---|
| object | No | lune | |
| date_utc | Yes | ||
| latitude | Yes | ||
| longitude | Yes | ||
| tolerance_deg | No | ||
| claimed_azimuth_deg | Yes | ||
| claimed_elevation_deg | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this safe read-only idempotent behavior, so the description does not need to restate safety. It does add useful context by disclosing the methodology (NOAA/Meeus approximations, lunar parallax) and that results are 'model-conditional,' which signals approximation limits. It omits permission needs or accuracy bounds beyond that, so it is solid but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense, front-loaded sentences with no filler: the action and target come first, the methodology and return content follow. It is appropriately sized, though the technical phrasing is slightly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description partially compensates by naming the return (angular consistency and lunar phase). However, given 7 parameters at 0% schema coverage and no output schema, it leaves significant gaps about input formats and result structure that an agent would need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters, so the description carries the full burden and largely fails: it does not explain date_utc's fixed format, the tolerance_deg default/units, latitude/longitude ranges, or the azimuth/elevation claimed values. Only the Sun/Moon choice and UTC time/location are vaguely echoed from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check) and resource (a claimed Sun or Moon position) and scopes the inputs (UTC time/location), which lets an agent distinguish it from siblings like verify_shadows or check_shadow_track. It stops short of naming those siblings or drawing an explicit boundary, so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative guidance is given. It is implied the tool verifies a claimed position, but an agent gets no routing help against check_shadow_track, verify_shadows, or triangulate_tracks, which are plausible overlapping siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare 4–120 measured minute/azimuth pairs with solar motion: residuals, slope, direction and time-lapse speed. Supply measurements, not video. Results are model-conditional consistency findings.
| Name | Required | Description | Default |
|---|---|---|---|
| samples | Yes | ||
| date_utc | Yes | ||
| latitude | Yes | ||
| longitude | Yes | ||
| tolerance_deg | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral notes: it tells the caller to supply measurements rather than video, and that results are 'model-conditional consistency findings' — a caveat about output interpretation. It still lacks detail on calculation assumptions, failure modes, or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the action and output types. Three short sentences each carry some weight, though 'model-conditional consistency findings' is slightly vague and could be sharpened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 4 required, 0% schema descriptions, and no output schema, the description is incomplete. It explains the samples input shape but omits date format, location semantics, and tolerance meaning, leaving key required parameters undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It partially covers the samples array by specifying 4–120 minute/azimuth pairs, but says nothing about date_utc format, latitude/longitude, or the optional tolerance_deg parameter. The required location and date inputs are implied only indirectly through 'solar motion.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Compare') and resource ('measured minute/azimuth pairs with solar motion'), and lists the core outputs (residuals, slope, direction, time-lapse speed). It is clear what the tool does, though it does not explicitly contrast itself with nearby siblings such as verify_shadows or triangulate_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is 'Supply measurements, not video,' which is an input constraint rather than a when-to-use rule. There is no mention of when this tool should be chosen over alternatives like verify_shadows or check_ephemeris, nor any exclusions or prerequisites beyond the input format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Plan from declared available/goal contracts within tool, locality and search bounds. Returns dependencies, blockers and existing-tool bindings. Cost counts graph steps, not speed, price or quality. Runs no engines; execution validates arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| goals | Yes | ||
| inputs | No | ||
| adapters | No | ||
| available | Yes | ||
| constraints | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral value beyond that: it discloses the return contents (dependencies, blockers, existing-tool bindings), clarifies that cost counts graph steps rather than speed/price/quality, and states it runs no engines. The remaining gap is response structure/pagination, which is minor given the closed-world read-only annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences, front-loaded with the core purpose and return behavior, with no filler. The density is arguably excessive but every sentence conveys distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex planning tool with five parameters, nested objects (adapters, constraints), 0% schema coverage and no output schema, the description is too thin. It omits the meanings of inputs/adapters and constraint options, and gives no guidance on interpreting the returned plan, leaving significant gaps an agent must guess at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It only alludes to 'goals', 'available' and the constraint surface (tool, locality, search bounds); the 'inputs' and 'adapters' parameters and the specific constraint keys (max_steps, local_only, allowed_tools, max_search_states, max_structural_cost) are left entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description does state a specific verb (plan) over a named resource (capabilities/contracts), distinguishing it loosely as a planning-not-executing tool. However the jargon-laden phrasing ('declared available/goal contracts', 'locality bounds') is hard to parse, and it never differentiates itself from close siblings like list_capabilities, list_composition_capabilities or execute_composition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named. The phrase 'execution validates arguments' faintly gestures at execute_composition but leaves the agent to infer the workflow on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute an ideal two-body Keplerian orbit around one solar mass. Time starts at periapsis; distances use AU and time uses days. This model is not a real celestial ephemeris.
| Name | Required | Description | Default |
|---|---|---|---|
| eccentricity | Yes | ||
| elapsed_days | Yes | ||
| semi_major_au | Yes |
| Name | Required | Description |
|---|---|---|
| orbit | Yes | |
| engine | Yes | |
| method | Yes | |
| position | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| distance_au | Yes | |
| period_days | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds substantive context the annotations cannot: the periapsis time origin, the AU/day unit system, and the caveat that results are not a real ephemeris, which manages expectation about output fidelity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, fully front-loaded: the core action first, then conventions, then the limitation caveat. Zero filler and no repetition of structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained. The description adequately covers the model's conventions and its fidelity limits for a deterministic simulation tool; only the eccentricity parameter's semantics remain thin against the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the parameter burden. It supplies units and time origin that map onto semi_major_au and elapsed_days, but says nothing about eccentricity's meaning or the 0–0.9 bound, leaving one of three parameters undocumented in prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Compute) and a precise resource (ideal two-body Keplerian orbit around one solar mass). The explicit 'not a real celestial ephemeris' clause distinguishes it from sibling tools like check_ephemeris and assimilate_observation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by contrasting the idealized model with a real ephemeris, which hints at when to pick it over check_ephemeris, but it never names an alternative or states an explicit condition for selection. Conventions (periapsis start, AU/days) are given, but that is setup, not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run approved task-selection/route-to-duration risk chains only. Supply engine inputs and explicit uncertainty; route speed is 1–150 km/h. Returns native receipts and 95% sampling bounds. Completed means assessed, not safe. Other paths use advertised bindings.
| Name | Required | Description | Default |
|---|---|---|---|
| goals | Yes | ||
| inputs | No | ||
| adapters | No | ||
| available | Yes | ||
| constraints | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds genuinely useful context beyond them: it returns 'native receipts and 95% sampling bounds' and warns that 'Completed means assessed, not safe.' The latter is a meaningful semantic caveat. It stops short of describing failure modes or rate/timeout behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences with the action front-loaded and no filler. However, the compressed jargon ('advertised bindings', 'native receipts') trades clarity for brevity, so efficiency is slightly at the expense of comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter, nested-object tool with 0% schema coverage and no output schema, the description is too thin: it never explains the required goals/available inputs or the constraint controls. It partially covers the output ('receipts', '95% sampling bounds') but leaves the input contract opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 5 parameters with nested objects, so the description must carry the load. It mentions 'engine inputs and explicit uncertainty' and repeats the 1–150 km/h route speed that the schema already enforces, but says nothing about goals, available, or the constraints object (max_steps, local_only, allowed_tools, max_search_states). It does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'run' plus the resource 'task-selection/route-to-duration risk chains' gives a nominally specific purpose, but the phrasing is dense domain jargon that an agent cannot easily map to a concrete action. It gestures at scope ('approved ... chains only') but does not clearly distinguish this from siblings such as run_route_policy, compose_capabilities, or build_robust_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Run approved ... chains only' states a precondition but no when-to-use versus alternatives. 'Other paths use advertised bindings' hints at routing but is too vague to tell an agent which sibling to pick instead. No exclusions or hand-offs are stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Train route-score ASTs on 1–8 supplied cases: at most 64 attempts and 31 nodes; stop between trials after 25s. Select converged candidates using training quality plus logical-fuel cost, a work proxy rather than CPU time. No held-out validation, arbitrary code or automatic promotion.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | Yes | ||
| train | Yes | ||
| budget | Yes |
| Name | Required | Description |
|---|---|---|
| seed | Yes | |
| budget | Yes | |
| trials | Yes | |
| selected | Yes | |
| attempted | Yes | |
| promotion | Yes | |
| selection | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| limitations | Yes | |
| stop_reason | Yes | |
| train_sha256 | Yes | |
| kernel_version | Yes | |
| request_sha256 | Yes | |
| search_version | Yes | |
| contract_version | Yes | |
| unique_evaluated | Yes | |
| baseline_program_sha256 | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description usefully adds search/trial limits (64 attempts, 31 nodes, 25s stop) plus the convergence-selection rule and explicit non-goals. Some terms ('logical-fuel cost, a work proxy') remain opaque, keeping it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, no filler, limits front-loaded before the selection rationale. The heavy jargon compresses meaning but does not pad.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be described, and the description conveys the conceptual workflow. However, for a tool with nested required parameters and zero schema prose, it omits key input semantics and never clarifies its relationship to run_route_policy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage the description must compensate, and it partly does: it maps '1-8 supplied cases' to train and 'at most 64 attempts' to budget.candidates, and hints at fuel. It leaves seed, time_per_case_ms, and the nested point structure unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Train route-score ASTs' on supplied cases, with the artifact (AST) named. It does not, however, name or differentiate itself from close siblings like run_route_policy or route_optimizer, and 'route-score AST' is undefined jargon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use statement and no routing to alternatives; the reader is left to infer that this is a training/forging step that presumably precedes run_route_policy. The negative list ('No held-out validation, arbitrary code or automatic promotion') discloses limitations but not usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a public contributor ticket/progress and verified pi or discrete synthetic schedule result. Schedule results include fixed-sample Wilson95 bounds. Worker/verification/wall times are separate; model probabilities are not delivery guarantees.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered externally. The description adds result-interpretation context ('worker/verification/wall times are separate; model probabilities are not delivery guarantees'), which is useful but concerns output semantics rather than tool behavior. With annotations carrying the behavioral burden, this is an adequate middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with no obvious filler and the retrieval statement is front-loaded, but the phrasing is choppy and jargon-dense ('verified pi or discrete synthetic schedule result'), forcing the reader to decode rather than absorb. Adequate but not clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description rightly carries return-value information: it names the ticket/progress payload, the schedule result, the Wilson95 bounds, and the separate timing fields. That is a reasonably complete sketch of what comes back, though it omits the job_id input meaning and any error/not-found behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description says nothing about the sole parameter, job_id. The schema supplies the UUID format and pattern but no human-readable meaning, and the description does not compensate by explaining what a job_id represents or where it comes from. This is a gap for a parameter that gates the entire call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gestures at the resource ('public contributor ticket/progress and verified pi or discrete synthetic schedule result') but never plainly says it retrieves a network job by id, and heavy jargon ('pi', 'Wilson95', 'discrete synthetic schedule') obscures the core purpose. The 'Read' verb is clear, but the object of the read is only inferable from the tool name, not the description text. It also does not differentiate itself from the sibling submit_network_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus alternatives such as network_status or submit_network_job, nor any prerequisites (e.g., needing a job_id from a prior submission). The only guidance is an interpretive caveat about results, which is not usage routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute 1–12 ideal fixed/free membrane modes for a simple polygon in metres using bounded P1 finite elements. Return upper bounds, extrapolated estimates and optional frequencies/shapes. Finite spectral agreement does not prove isospectrality; no damping. CPU, direct-only; no planner binding.
| Name | Required | Description | Default |
|---|---|---|---|
| modes | No | Default 8, counted with multiplicity. | |
| polygon | Yes | Vertices [x, y] in metres, either orientation; a repeated closing vertex is allowed. Must be simple. | |
| boundary | No | fixed (default): drumhead, TM waveguide. free: acoustic cavity, TE waveguide. | |
| wave_speed | No | m/s; √(tension/areal density) for a membrane. Enables frequency_hz and notes. | |
| compare_polygon | No | Optional second shape: do the two drums sound the same? | |
| include_mode_shapes | No | Adds a ≤1024-triangle mesh with normalized mode values, for visualization. |
| Name | Required | Description |
|---|---|---|
| shape | Yes | |
| engine | Yes | |
| method | Yes | |
| boundary | Yes | |
| statement | Yes | |
| comparison | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| assumptions | Yes | |
| compared_shape | Yes | |
| contract_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds valuable behavioral context: results are bounded upper bounds and extrapolated estimates rather than exact values, finite spectral agreement does not prove isospectrality, damping is excluded, and execution is CPU/direct-only with 'no planner binding'. These caveats materially shape how an agent should trust and use the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the core operation before moving to caveats and execution profile. Every clause carries information, though the sentences are somewhat packed and the 'no planner binding' fragment is slightly terse relative to its importance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is unnecessary, yet the description still names the outputs (upper bounds, extrapolated estimates, optional frequencies/shapes) helpfully. Combined with the accuracy and execution caveats, it is nearly complete; only explicit usage/precondition guidance for a six-parameter numerical tool is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents modes, polygon, boundary, wave_speed, compare_polygon, and include_mode_shapes. The description reinforces the physical meaning of fixed/free boundary and the frequency/shape outputs but adds no syntax or constraint details beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (compute), resource (ideal fixed/free membrane modes), scope (1–12), and method (bounded P1 finite elements) for a simple polygon in metres. No sibling tool in the list covers spectral geometry, so the naming as an acoustic/membrane solver plus the 'drum' framing makes its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides interpretive context – fixed/free physical mappings, the isospectrality caveat, and 'no damping' – but never states when to call this tool versus another or what preconditions the caller must satisfy. Usage is implied by the physics framing rather than explicitly routed, which is adequate but leaves gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare up to 32 declared deadline/optional-task changes under independent-uniform durations; preserve required tasks. Search bounds select one finalist for separately seeded confirmation, without retries. Conditional on the model, not delivery reliability.
| Name | Required | Description | Default |
|---|---|---|---|
| costs | Yes | ||
| items | Yes | ||
| samples | Yes | ||
| search_seed | Yes | ||
| uncertainty | Yes | ||
| removal_sets | Yes | Unique sorted sets of optional original task indices; include the empty set, preserve required tasks, and keep at least one task. | |
| extra_minutes | Yes | Unique permitted deadline increments; include zero and keep every modified deadline at most 1440 minutes. | |
| duration_model | Yes | ||
| deadline_minutes | Yes | ||
| min_success_rate | Yes | ||
| required_indices | Yes | ||
| confirmation_seed | Yes |
| Name | Required | Description |
|---|---|---|
| status | Yes | |
| candidates | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| study_kind | Yes | |
| explanation | Yes | |
| limitations | Yes | |
| confirmation | Yes | |
| contract_version | Yes | |
| simulation_samples | Yes | |
| selected_candidate_id | Yes | |
| provisional_candidate_id | Yes | |
| confirmation_error_budget | Yes | |
| search_family_error_budget | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds meaningful process behavior beyond that: no retries, a separately seeded confirmation phase, and the model-conditional caveat. It does not, however, explain cost behavior, failure modes, or what happens when no finalist meets min_success_rate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, none wasted in a strict sense, but they are densely jargon-laden and front-loaded with process mechanics rather than the primary purpose. An agent must parse 'search bounds select one finalist for separately seeded confirmation' to extract the essential behavior. Adequate but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter, all-required tool with nested objects and only 17% schema coverage, the description is far too thin about inputs. An output schema exists so return values are exempt, but the input semantics and the meaning of the search/confirmation split are not adequately covered for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% across 12 required parameters, so the description carries a heavy burden and largely fails it. It gestures at 'up to 32 declared changes', 'independent-uniform durations', and 'preserve required tasks', but says nothing about the meaning of deadline_minutes, extra_minutes, costs, min_success_rate, samples, or the two seeds. Most parameters remain individually opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description reveals this is a two-phase schedule search-and-confirmation tool over deadline/optional-task changes, which is more specific than the name alone. However, it never states plainly what the tool returns or produces (a finalist schedule?), instead burying the purpose in process jargon like 'search bounds select one finalist'. It also fails to distinguish itself from close siblings such as optimize_tasks or build_robust_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance and no mention of the obvious alternative, optimize_tasks, despite the two being near-neighbors. The only guidance is a caveat ('conditional on the model, not delivery reliability'), which is a limitation note rather than selection criteria. An agent has to infer from context whether to pick this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Survey up to 512 initial orbits in a planar circular Sun–Jupiter model; at most 4 million reserved CPU steps. Return finite-window sensitivity, actual durations, sampled Jacobi drift and explicit stops. Bands do not prove chaos or stability; radial overlap is not an encounter. Direct-only.
| Name | Required | Description | Default |
|---|---|---|---|
| n_a | Yes | ||
| n_e | Yes | ||
| e_max | Yes | ||
| e_min | Yes | ||
| a_max_au | Yes | ||
| a_min_au | Yes | ||
| mass_ratio | No | ||
| duration_yr | No | ||
| max_work_units | No | ||
| steps_per_year | No | ||
| initial_phase_deg | No | ||
| jupiter_semi_major_au | No |
| Name | Required | Description |
|---|---|---|
| grid | Yes | |
| notes | Yes | |
| engine | Yes | |
| method | Yes | |
| points | Yes | |
| system | Yes | |
| map_text | Yes | |
| statement | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| assumptions | Yes | |
| contract_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safety profile (read-only, idempotent, non-destructive, closed-world), and the description adds real behavioral context: a 512-orbit ceiling, a 4-million CPU-step budget, 'explicit stops,' and result-interpretation limits. It stops short of describing how truncation or 'explicit stops' surface in the response, which the output schema presumably covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, front-loaded with the operation and its budget, with no filler. The interpretation caveats are dense but arguably necessary given the tool's misuse potential; nothing reads as padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not strictly required, yet the description usefully names the outputs anyway. The real gap is the 12 undocumented parameters and the absence of any indication of default values (e.g., Jupiter semi-major, mass ratio) or how the 512-orbit cap interacts with a 64×64 grid request.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 12 parameters, so the description must carry the load, and it only partially does: 'up to 512 initial orbits' maps to n_a×n_e and 'at most 4 million reserved CPU steps' maps to max_work_units. Units and meaning for mass_ratio, duration_yr, steps_per_year, initial_phase_deg, jupiter_semi_major_au, and the a/e bounds are left entirely to bounds inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Survey ... initial orbits') and pins the physical model ('planar circular Sun–Jupiter'), which is far more than the name conveys. It does not explicitly distinguish itself from near-neighbor siblings such as compute_orbit or propagate_uncertainty, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: this is a stability survey tool, and 'Direct-only' signals an invocation constraint, but no when/when-not or sibling alternative is named. The interpretive caveats ('Bands do not prove chaos or stability; radial overlap is not an encounter') guide result reading, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read native contracts, themes, units, assumptions, backends and approved composition families; optional exact theme filter. tools/list discovers direct MCP tools; list_composition_capabilities adds planner bindings.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds the one behavioral note that the theme filter must match exactly, but says nothing about result size, ordering, or pagination. Given annotation coverage, this is adequate but thin.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no filler: the scope of data read comes first, then the routing hints. Dense but front-loaded and free of redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with no output schema and one parameter, the description compensates by enumerating the categories of data returned and noting the optional exact filter. An agent has enough to invoke it correctly, though ordering/pagination behavior is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'theme' parameter, so the description carries the burden and does add the key semantic that the filter is 'optional' and must be an 'exact' match. It stops short of giving format examples or stating behavior for non-matching themes, so the gap is only partly closed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Read) and enumerates the concrete resources returned (native contracts, themes, units, assumptions, backends, approved composition families). It also explicitly distinguishes itself from the sibling list_composition_capabilities and from tools/list, so an agent can tell them apart without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives comparative context ('tools/list discovers direct MCP tools; list_composition_capabilities adds planner bindings'), which implies where this tool sits. However, it never states when to choose this tool over those alternatives — no condition or task framing that selects it — so usage remains implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read implemented versioned contracts, native capabilities, approved adapters and planning examples. Unsupported unit/model facts expose missing adapters. No engines run; direct tools remain independently callable.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine context beyond that: nothing is executed ('no engines run') and direct tools remain independently callable, plus the note that unsupported unit/model facts surface as missing adapters. It does not describe the shape or scope of what is returned, so it is useful but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the verb and the resource list, with no filler. It is compact, though the middle sentence about missing adapters is cryptic enough that its brevity costs clarity rather than serving it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no parameters, so the description carries the burden of telling the agent what it gets back. It names the data categories but not the structure, cardinality, or how the 'missing adapters' signal is surfaced, which is a real gap for a discovery tool whose output feeds downstream planning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema is a closed empty object, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Read' plus a list of resource categories (versioned contracts, native capabilities, approved adapters, planning examples) conveys a listing/inspection purpose, which is more specific than a bare tautology. However, the categories are jargon-heavy and it never distinguishes itself from the sibling 'list_capabilities' or explains what a 'versioned contract' or 'approved adapter' is in this domain, so an agent cannot confidently route between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'No engines run; direct tools remain independently callable' implies this is a non-executing inspection step used before execution tools like compose_capabilities/execute_composition, which is implicit usage guidance. But it never states when to call this instead of list_capabilities or when-not to call it, leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read contributor availability, offered CPU/GPU resources and verified throughput by workload. Hardware is self-reported; per-GPU VRAM is not pooled. Mixed-workload samples do not measure comparative speed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower, and the description adds genuinely useful interpretation caveats: hardware is self-reported, per-GPU VRAM is not pooled, and mixed-workload samples are not comparable. These disclose data-quality limits an agent would otherwise assume away.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the primary purpose and then the caveats. Each sentence earns its place; no filler or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, closed-world read tool with no output schema, the description covers purpose, data dimensions, and reliability caveats. It stops short of describing return structure, which is acceptable given no output schema exists but leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (Read) and specifies the resource dimensions: contributor availability, offered CPU/GPU resources, and verified throughput by workload. This clearly separates it from write-side siblings like submit_network_job, though it never names an alternative explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the read-only, status-reporting phrasing, but the description gives no explicit when-to-use guidance and never contrasts itself with related siblings such as get_network_job or list_capabilities. The caveats hint at appropriate interpretation but not at tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exactly maximize value for up to 32 independent, indivisible tasks within an integer-minute budget. Each task is selected at most once; no prerequisites or shared resources.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| budget | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds genuine model semantics beyond that: exact (not heuristic) optimality, indivisible tasks, at-most-once selection, and independence with no shared resources. It does not describe the result shape, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with zero filler, front-loading the objective and then the problem-model constraints. Every clause carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description is the only place the return shape (e.g., selected tasks and achieved total value) could be conveyed, and it is silent on that. Problem structure, constraints and safety are adequately covered, but the missing output contract is a real gap for a solver tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry semantic weight, and it does: 'integer-minute budget' fixes the unit for budget, 'independent, indivisible' and 'selected at most once' define the 0/1 knapsack semantics of items, and 'maximize value' ties to the value field. It does not explain the name field, but schema names are largely self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and objective (exactly maximize value) over a specific resource (up to 32 independent, indivisible tasks within an integer-minute budget). The word 'Exactly' implicitly contrasts with heuristic siblings like improve_schedule or build_robust_plan, but no sibling is named, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description encodes applicability constraints (≤32 tasks, integer-minute budget, no prerequisites or shared resources) which imply when this solver applies, but it never states when to prefer it over alternatives such as improve_schedule or build_robust_plan. Usage is inferable rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute geometric golden [-4,+6°] and blue [-6,-4°] windows for one UTC day, 1900–2100. Sunrise at -0.833° is a separate convention. No refraction, terrain or weather. Numerical tolerance is not astronomical accuracy; oracle validation covers reference dates only. Shared solar models are not independent corroboration.
| Name | Required | Description | Default |
|---|---|---|---|
| date_utc | Yes | Real Gregorian UTC midnight, year 1900–2100. Rust also validates month/day and leap years. Other hours are rejected, never truncated; this is not a local civil day. | |
| latitude | Yes | Degrees, North positive. | |
| longitude | Yes | Degrees, East positive. |
| Name | Required | Description |
|---|---|---|
| bands | Yes | |
| notes | Yes | |
| status | Yes | |
| windows | Yes | |
| date_utc | Yes | Real Gregorian UTC midnight, year 1900–2100. Rust also validates month/day and leap years. Other hours are rejected, never truncated; this is not a local civil day. |
| latitude | Yes | |
| crossings | Yes | |
| longitude | Yes | |
| numerical | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| limitations | Yes | |
| period_end_utc | Yes | |
| contract_version | Yes | |
| period_start_utc | Yes | |
| sunrise_convention | Yes | |
| elevation_convention | Yes | |
| sun_max_elevation_deg | Yes | |
| sun_min_elevation_deg | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds meaningful behavioral context beyond them: no refraction/terrain/weather modeling, a warning that numerical tolerance is not astronomical accuracy, and a caveat on validation coverage and non-independence of shared solar models. This is genuinely useful limitation disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition leads with the core computation and angle ranges, then appends limits. It is dense but every sentence carries a distinct caveat or scope. The final two sentences on oracle validation and shared-model non-independence are slightly tangential but still earn place as trust caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and full schema description coverage, the description need not explain returns or parameters, and it correctly focuses on conventions and model limitations. Coverage is solid; the only gap is absent guidance about when to prefer this over related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents date_utc, latitude, and longitude in detail (including polarity, bounds, and validation rules). The description adds nothing about parameter format or constraints beyond the output angle ranges, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: computing geometric golden [-4,+6°] and blue [-6,-4°] windows for one UTC day. The scope, angle bounds, and time range are concrete, so an agent knows exactly what is produced. It does not explicitly distinguish itself from sibling solar tools like check_ephemeris or check_shadow_track, which keeps it below a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance and no routing to alternatives. The clause 'Sunrise at -0.833° is a separate convention' clarifies a boundary but is a disambiguation caveat, not usage direction. An agent gets no explicit signal about when this tool is preferred over the many related solar/ephemeris siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview robust scheduling without running engines: validate assumptions/permissions and return up to three candidate budgets (nominal, 10% reserve, 20% reserve), compute limits or blockers. No arbitrary tools or external code.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| items | Yes | ||
| budget | Yes | ||
| samples | No | ||
| uncertainty | Yes | ||
| allowed_tools | No | ||
| duration_model | No | independent_uniform | |
| max_candidates | No | ||
| min_success_rate | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: it is a preview that does not run engines, returns three budget candidates (nominal, 10%, 20% reserve), and computes limits/blockers. That extra detail is meaningful even with annotations present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the key constraint (no arbitrary tools/external code) front-loaded. No filler, though it is dense and could benefit from clearer separation of inputs vs outputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given nine parameters, no output schema, and heavy domain complexity, the description is too thin. It should explain what 'items' represent, how uncertainty shapes candidates, and the meaning of min_success_rate, but it does not. It is complete at a high level but not for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so nine parameters are documented only by names and types. The description mentions 'budgets', 'assumptions/permissions', and 'tools' but does not define what items, uncertainty, duration_model, or min_success_rate mean. It partially compensates but leaves most parameters semantically thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a verb and outcome ('Preview robust scheduling... return up to three candidate budgets'), which is specific. But it doesn't differentiate plan_mission from the sibling build_robust_plan, which appears to do the same job. The core purpose is vague relative to the crowded planning family.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage ('Preview... without running engines', 'No arbitrary tools or external code'), suggesting a dry-run planning call. But it never says when to use plan_mission instead of build_robust_plan, simulate_plan, or stress_test_observation. Usage is inferred, not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fit original tracks, then rank 1–64 supplied future series by local-linear uncertainty and declared cost. Assumes constant velocity, independent new errors and exact stations/clocks. Candidate angles and client baselines are forbidden. Prediction is not an acquired measurement or visibility proof.
| Name | Required | Description | Default |
|---|---|---|---|
| objective | Yes | ||
| candidates | Yes | ||
| assumptions | Yes | ||
| constraints | Yes | ||
| observations | Yes | Original angular observations; Rust computes the baseline fit and covariance itself. |
| Name | Required | Description |
|---|---|---|
| design | Yes | |
| status | Yes | |
| reasons | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| baseline_fit | Yes | |
| policy_trace | No | |
| contract_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), but the description adds real behavioral content: the modeling assumptions baked in (constant velocity, independent new errors, exact stations/clocks), the user is supplying future samples rather than measurements, and the output is explicitly not a measurement or visibility proof. That is meaningful context beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the core action before the assumptions, prohibitions, and caveat. Dense jargon but no filler sentences. Slightly telegraphic phrasing is the only structural cost.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values need no explanation, and the description does cover assumptions and intellectual limitations. However, for a five-parameter, deeply nested tool with 20% schema coverage, it omits the constraint semantics (max_cost_units, min_elevation_deg), the horizon domain, and the observer-clock handling, leaving a real gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, so the description must compensate, and it partially does: it explains the candidate series semantics (future, not measured angles), the cost criterion, and the three assumption flags. Field-level meaning for objective.horizon_s, constraints, and the sigma parameters is still conveyed only by the schema's sparse descriptions, so it does not fully close the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verbs and resources: it fits original tracks, then ranks 1–64 supplied future series by local-linear uncertainty and declared cost. That is far more than a restatement of the name. It does not, however, explicitly distinguish itself from nearby siblings such as assimilate_observation or stress_test_observation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives exclusions ('candidate angles and client baselines are forbidden') and a scope caveat ('prediction is not an acquired measurement or visibility proof'), which frames when the output is not sufficient. But it never says when to prefer this tool over assimilate_observation, stress_test_observation, or simulate_plan, so the positive selection criteria remain implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check dimensions, then compare first-order GUM with seeded fixed-sample Monte Carlo for an explicit model of 1–16 inputs. Return uncertainty budgets, coverage intervals and convergence/linearization findings. Conditional on supplied distributions; no affine units. CPU, direct-only; no planner binding.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Default 1. Same seed, same result. | |
| samples | No | Monte Carlo draws, default 1000000 (JCGM 101 typical value for 2 significant digits). | |
| coverage | No | Coverage probability, default 0.95. | |
| variables | Yes | ||
| expression | Yes | Model with + - * / ^, parentheses, pi and sqrt exp ln log10 sin cos tan asin acos atan abs. Literals are dimensionless; no implicit multiplication. | |
| result_unit | No | Output unit; must match the model dimension. | |
| correlations | No | Correlations between normal inputs with standard_uncertainty > 0. |
| Name | Required | Description |
|---|---|---|
| gum | Yes | |
| seed | Yes | |
| unit | Yes | |
| notes | Yes | |
| budget | Yes | |
| engine | Yes | |
| method | Yes | |
| status | Yes | |
| samples | Yes | |
| verdict | Yes | |
| coverage | Yes | |
| dimension | Yes | |
| statement | Yes | |
| diagnostic | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| validation | Yes | |
| assumptions | Yes | |
| monte_carlo | Yes | |
| recommended | Yes | |
| contract_version | Yes | |
| correlation_variance_share | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world). The description goes beyond them with genuinely useful traits: deterministic seeded Monte Carlo, sampling imposed on user-supplied distributions, the refusal of affine units, and CPU/direct-call execution with no planner binding. Determinism and the input-conditioning caveat are exactly the behavioral facts an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with the core comparison front-loaded and no filler. The telegraphic phrasing ("CPU, direct-only; no planner binding") is dense but each clause carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values needn't be detailed, and the description still previews the budget/interval/finding outputs. Combined with 86% schema coverage and full annotations, the definition is complete enough for correct invocation, though the description could say more about how the two methods are reconciled when they disagree.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so the schema already documents seed, samples, coverage, units, expression grammar and correlations. The description adds only a little beyond it (1–16 input bound, no affine units), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific operations (dimension check, first-order GUM vs seeded Monte Carlo comparison) on a specific resource (an explicit model of 1–16 inputs) and names what is returned (uncertainty budgets, coverage intervals, convergence/linearization findings). No sibling tool occupies this uncertainty-propagation niche, so the agent can select it unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Conditional on supplied distributions; no affine units" and "CPU, direct-only; no planner binding" give clear applicability conditions and clearly exclude the planner/route siblings. It stops short of naming an explicit alternative or stating when NOT to use it, so it is strong context rather than full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Order 2–256 points from index 0 using planar or spherical kilometre distances. Exact only after completed Held–Karp search (at most 13 points); otherwise bounded heuristics. Returns every leg and stop reason. No roads or traffic.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | Yes | ||
| points | Yes | ||
| time_budget_ms | No | ||
| return_to_start | No |
| Name | Required | Description |
|---|---|---|
| unit | Yes | |
| exact | Yes | |
| order | Yes | |
| method | Yes | |
| metric | Yes | |
| points | Yes | |
| tour_legs | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| work_limit | Yes | |
| work_units | Yes | |
| limitations | Yes | |
| stop_reason | Yes | |
| upper_bound_km | Yes | |
| return_to_start | Yes | |
| contract_version | Yes | |
| total_distance_km | Yes | |
| greedy_reference_km | Yes | |
| improvement_vs_greedy_pct | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safe-read profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond that: the exact-vs-heuristic boundary at 13 points, the fact that a Held-Karp search must complete for exactness, and that roads/traffic are out of scope. It stops short of noting timeout behavior or what a 'stop reason' can be.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler; the core operation, the exactness caveat, and the scope exclusion are all front-loaded and each sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be spelled out (though the description helpfully mentions legs and stop reasons). The gap is on the input side: two of four parameters are undefined in both schema and description, which for a solver tool with hard limits leaves the agent guessing on timeout and loop-closure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage the description must carry the load, and it partially does: 'planar or spherical kilometre distances' maps to the metric enum, and '2-256 points from index 0' covers the points array and origin. However, time_budget_ms and return_to_start are never explained anywhere, leaving half the parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: ordering a set of points into a route by planar or spherical kilometre distance. Clear enough that an agent knows this is the TSP-style route sequencing tool, though it never names or contrasts with siblings like forge_route_policy or run_route_policy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains exactness limits (Held-Karp only up to 13 points) but gives no guidance on when to choose this tool over route-related siblings such as forge_route_policy or run_route_policy, nor any preconditions for calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a supplied bounded score AST on 2–128 Euclidean-km points with depot 0 and 2-opt. Validates the closed tour; exact=false. No retraining, external effects or promotion. Hashes identify programs, not independent validation.
| Name | Required | Description | Default |
|---|---|---|---|
| points | Yes | ||
| program | Yes | ||
| fuel_limit | No | ||
| time_budget_ms | No |
| Name | Required | Description |
|---|---|---|
| legs | Yes | |
| exact | Yes | |
| order | Yes | |
| fuel_used | Yes | |
| length_km | Yes | |
| elapsed_ms | Yes | |
| fuel_limit | Yes | |
| provenance | Yes | |
| limitations | Yes | |
| stop_reason | Yes | |
| kernel_version | Yes | |
| program_sha256 | Yes | |
| simplification | Yes | |
| contract_version | Yes | |
| initial_length_km | Yes | |
| all_points_coincident | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses important behavioral limits: it validates a closed tour, exact=false, performs no retraining, external effects, or promotion, and hashes identify programs but not independent validation. These are non-obvious operational facts an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is compact and front-loaded, moving from execution to validation to operational caveats. Each sentence carries information, though the dense technical vocabulary could be more accessible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present, so return values need not be described. However, for a tool with a deeply nested program parameter and 0% schema description coverage, the description leaves important parameter semantics and AST usage details incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and four parameters, the description only partially compensates by mentioning 2–128 Euclidean-km points and depot 0. It does not explain fuel_limit, time_budget_ms, or the semantic meaning of the nested AST fields and feature names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: execute a supplied bounded score AST over Euclidean points using depot 0 and 2-opt. The word "supplied" helps distinguish it from a policy-forging sibling, though the AST jargon keeps it from being fully transparent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies this tool runs a pre-existing program rather than training one, but gives no explicit when-to-use or when-not-to-use guidance. It does not name or compare against siblings such as forge_route_policy or route_optimizer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bounded deterministic float64 scan of a scalar <= or >= claim over a declared grid of 1–6 variables. Reports numerical witnesses, undefined and uncertain evaluations, and the exact stop reason. A propagated screening guard rejects near-boundary candidates; it is not a certified interval or formal proof. An inconclusive outcome preserves unresolved sampled cells; absence of a witness does not establish the claim over the continuous box.
| Name | Required | Description | Default |
|---|---|---|---|
| bound | Yes | ||
| relation | Yes | ||
| tolerance | No | ||
| variables | Yes | ||
| expression | Yes | ||
| max_evaluations | No | ||
| max_counterexamples | No |
| Name | Required | Description |
|---|---|---|
| bound | Yes | |
| notes | Yes | |
| engine | Yes | |
| limits | Yes | |
| method | Yes | |
| verdict | Yes | |
| complete | Yes | |
| relation | Yes | |
| evaluated | Yes | |
| statement | Yes | |
| tolerance | Yes | |
| elapsed_ms | Yes | |
| expression | Yes | |
| grid_total | Yes | |
| provenance | Yes | |
| work_units | Yes | |
| assumptions | Yes | |
| stop_reason | Yes | |
| stopped_early | Yes | |
| counterexamples | Yes | |
| contract_version | Yes | |
| finite_evaluations | Yes | |
| first_counterexample | Yes | |
| uncertain_evaluations | Yes | |
| undefined_evaluations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial behavioral context beyond them: it is bounded and deterministic, reports undefined and uncertain evaluations plus the exact stop reason, uses a propagated screening guard that rejects near-boundary candidates, and preserves unresolved sampled cells on inconclusive outcomes. This is unusually rich disclosure of what the tool actually does and does not guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the core operation and followed by limitations. Every sentence carries distinct information with no padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values needn't be explained, yet the description adds the useful conceptual result model (witnesses, undefined/uncertain evaluations, stop reason). Given the 0% parameter coverage, minor gaps remain on tolerance and evaluation-limit parameters, but the conceptual picture is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it only partly does. It clarifies the variable grid (1-6 variables), the scalar relation (<= or >=), and the bound concept, but leaves tolerance, max_evaluations, and max_counterexamples entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb+resource+scope: a bounded deterministic float64 scan of a scalar <= or >= claim over a declared grid of 1-6 variables. The domain (float64 grid, not continuous proof) is sharply defined, but no sibling tool (e.g. verify_claim) is named for explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than stated: the description notes it is 'not a certified interval or formal proof' and that absence of a witness does not establish the continuous claim, which signals when not to rely on it. However, it never says when to choose this over alternatives like verify_claim or check_arithmetic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a supplied trade series for repeated volume at nearly equal prices within a declared time window. Return recycled-volume ratio and cycles; a pattern does not prove wash trading.
| Name | Required | Description | Default |
|---|---|---|---|
| trades | Yes | ||
| window_s | No | ||
| price_band_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuine value beyond them: it names the outputs (recycled-volume ratio, cycles) and, importantly, warns that a detected pattern does not prove wash trading. It omits sensitivity/threshold behavior on the window and band, but the interpretive caveat is a real addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, action first, outputs and caveat second — no filler. The only small loss is that the return-value clause could be tightened, but nothing is wasted or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden, and it only sketches the shape ('ratio and cycles') without naming fields. With 0% schema coverage on three parameters, an agent still lacks units and defaults. Adequate but with clear, fillable gaps for a screening tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are three parameters, so the description must compensate. It gestures at each one conceptually ('declared time window', 'nearly equal prices', 'repeated volume') but never uses the parameter names, units (seconds, percent), defaults (3600, 0.25), or permissible ranges, so an agent still has to read the schema to supply values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('screen a supplied trade series') plus the detection criteria (repeated volume, nearly equal prices, declared time window). That is far more precise than a name-restatement. It does not, however, differentiate itself from any sibling tool, which is largely moot here since no sibling operates in this domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the agent can infer this is for post-hoc pattern screening on a trade series it already holds. There is no explicit when-to-use, no when-not-to-use, and no named alternative or prerequisite (e.g., minimum data length, data source).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Kac's question in reverse: design a polygonal drumhead whose lowest tones play requested frequency ratios (a fifth, a triad, a pentatonic scale), each accepted within ±tolerance_cents. proven_impossible is returned only when proven theorems exclude every ratio combination inside those tolerance windows for a connected uniform membrane with a fixed edge: simple fundamental, f2/f1 ≤ j11/j01 ≈ 1.5933 with equality for the disk (Ashbaugh–Benguria 1992), and Yang's universal inequality minimized exactly over the window box; an exact-target exclusion is reported separately. Otherwise multi-start L-BFGS with exact finite-element shape derivatives designs a 5–16-vertex polygon, then reanalyses it on three refined meshes with the shared hear_the_shape solver: achieved ratios, errors in cents with estimated uncertainty (not rigorous bounds), resolution warnings, optional numerical tuning of the fundamental in Hz. not_achieved is a bounded-search result, never an impossibility proof. Ideal membrane only.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Default 1. Same seed, same drum. | |
| vertices | No | Polygon vertices, default 10. | |
| wave_speed | No | m/s, √(tension/areal density). | |
| target_ratios | Yes | Frequency ratios f2/f1, f3/f1, … of the lowest modes, ascending (e.g. [1.25, 1.5] for a just major triad). | |
| fundamental_hz | No | With wave_speed: scale the drum so its fundamental sounds at this frequency. | |
| max_evaluations | No | Search budget in finite-element evaluations, default 300. | |
| tolerance_cents | No | Success when |error| + uncertainty ≤ tolerance for every ratio; default 5 cents. | |
| include_mode_shapes | No | Adds computed mode shapes from the shared forward solver (≤1024 triangles, full-precision coordinates) for visualization. |
| Name | Required | Description |
|---|---|---|
| notes | Yes | |
| engine | Yes | |
| method | Yes | |
| search | Yes | |
| matches | Yes | |
| polygon | Yes | |
| verdict | Yes | |
| statement | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| assumptions | Yes | |
| feasibility | Yes | |
| verification | Yes | |
| fundamental_hz | Yes | |
| contract_version | Yes | |
| fundamental_note | Yes | |
| worst_cents_error | Yes | |
| resolution_warning | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only assert readOnly/idempotent/no-side-effects, and the description adds far more: the mathematical theorems that produce proven_impossible, the multi-start L-BFGS + FEM shape-derivative method, 5-16 vertex design space, three-mesh reanalysis, uncertainty being estimates 'not rigorous bounds,' and that not_achieved is 'never an impossibility proof.' The stated 'ideal membrane only' assumption and resolution warnings are exactly the behavioral caveats an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded and nearly every clause carries necessary information for a genuinely complex inverse-geometry tool, so the length is warranted. However, it is delivered as one dense run-on paragraph with no grouping, which costs some readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema already exists, the description need not restate return values, and instead goes beyond by explaining the epistemic status of each outcome (proof vs. bounded search), the idealization assumptions, and uncertainty limits. For a tool of this mathematical complexity, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already defines tolerance_cents semantics ('success when |error| + uncertainty ≤ tolerance'), the 5-16 vertex range, and every other parameter. The description restates the vertex range and tolerance-based acceptance rather than adding new parameter meaning, so it sits at the documented baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a precise verb and resource: 'design a polygonal drumhead whose lowest tones play requested frequency ratios,' with concrete examples (fifth, triad, pentatonic scale). It also implicitly distinguishes itself from the sibling hear_the_shape by naming it as the shared forward solver reused for verification, so an agent can separate the inverse-design tool from the analysis tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the description clarifies the relationship to hear_the_shape (this tool designs, then reanalyses with the forward solver) but never gives an explicit 'use this when / use hear_the_shape instead when' rule or states prerequisites. It does define outcome conditions (proven_impossible vs. not_achieved), which helps set expectations but is not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate pi with seeded Monte Carlo and a 95% Wilson interval; up to 5 million samples. CPU or optional CUDA. Other direct scientific engines run on CPU.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | Yes | ||
| backend | No | cpu | |
| samples | Yes | ||
| device_ids | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the description's job is to add operational detail — and it does: deterministic seeding, a 5M sample ceiling, Wilson-interval output, and a CPU/CUDA backend split. It stops short of stating runtime cost or whether CUDA requires specific hardware, but adds real value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact clauses — operation, output/limits, backend — with the core purpose front-loaded and no filler. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description names the returned statistic (95% Wilson interval) plus the dual-backend behavior, which is the key context for a simulation tool. The unexplained device_ids parameter is the only material omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning, and it does for three of four: seeding, the 5M sample cap, and the cpu/cuda backend choice. Only device_ids is left unexplained (how many GPUs, selection semantics), which keeps this from a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with method and precision: 'Estimate pi with seeded Monte Carlo and a 95% Wilson interval'. An agent immediately knows the operation. It does not name a sibling to differentiate from, though 'Other direct scientific engines run on CPU' gestures at a category distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, no prerequisites, and no named alternative among the many simulate_*/plan_* siblings. The backend clause implies a choice but gives no condition for selecting CUDA over CPU.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate deadline success, mean duration and empirical p95 for up to 32 integer-minute tasks under independent bounded uniform duration variations. Seeded CPU sampling; not a real-world forecast guarantee.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | Yes | ||
| budget | Yes | ||
| samples | Yes | ||
| durations | Yes | ||
| uncertainty | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds meaningful context beyond annotations: it specifies seeded CPU sampling and explicitly warns that results are not a real-world forecast guarantee, setting correct expectations about determinism and interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two dense sentences with no filler. The main capability is front-loaded, and the important caveat about not being a real-world forecast follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five required parameters, no output schema, and no schema parameter descriptions, so the description carries a heavy completeness burden. It names the estimated outputs and the sampling method, but it omits key operational details such as what budget controls, how samples affect runtime or precision, and the allowed uncertainty range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for five undocumented parameters, but it only partially does so. It implies durations are integer-minute tasks capped at 32, uncertainty is a bounded uniform variation, and seed is used for sampling, but budget and samples are never explained, and no parameter ranges or formats are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Estimate') and the exact outputs: deadline success, mean duration, and empirical p95 for integer-minute tasks under bounded uniform variations. It is clear what the tool does, but it does not distinguish itself from siblings like build_robust_plan or improve_schedule, which may also deal with scheduling uncertainty.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for simulating plan outcomes under uncertainty, but it offers no explicit when-to-use guidance, prerequisites, or alternatives. An agent must infer that this is appropriate for probabilistic deadline estimation rather than deterministic optimization.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solve Kuhn poker with CFR+ self-play, measure exploitability with pure best responses and compare the game value with -1/18. Illustrative game theory, not gambling advice.
| Name | Required | Description | Default |
|---|---|---|---|
| iterations | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, closed-world behavior, so the bar is lower; the description still adds real context by disclosing the algorithm (CFR+ self-play), the evaluation method (pure best responses), the reference value (-1/18), and a scope disclaimer. It omits cost/runtime expectations for a iterative solver, keeping it out of 5 territory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the core action and finishing with interpretation guidance and disclaimer. Every clause carries information; no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless-to-one-param read-only compute tool with no output schema, the description conveys purpose and an interpretive benchmark, which is most of what an agent needs. It still leaves the sole parameter undefined and gives no sense of output structure or runtime, so it is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
One parameter ('iterations') with 0% schema description coverage and no enum, and the description never mentions it. The description does not explain that iterations controls CFR+ training depth or the accuracy/runtime trade-off, so it fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb+resource ('Solve Kuhn poker with CFR+ self-play') plus supplementary behaviors (exploitability measurement, comparison against -1/18). No sibling tool touches poker or game theory, so differentiation is unambiguous from the description alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description of the computation, but there is no explicit when-to-use framing, no prerequisites, and no condition that selects this tool over any alternative. Adequate but with a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refit 1–32 declared hypothetical angular/clock perturbations to challenge reconstruction stability. Explicit hypothetical acknowledgement required. Non-convergence is inconclusive; none_found covers examined cases only. No new observations.
| Name | Required | Description | Default |
|---|---|---|---|
| cases | Yes | ||
| claim | Yes | ||
| bounds | Yes | ||
| observations | Yes | ||
| perturbations_are_hypothetical | Yes |
| Name | Required | Description |
|---|---|---|
| cases | Yes | |
| claim | Yes | |
| bounds | Yes | |
| status | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| limitations | Yes | |
| baseline_fit | Yes | |
| interpretation | Yes | |
| evaluated_cases | Yes | |
| requested_cases | Yes | |
| contract_version | Yes | |
| first_counterexample | Yes | |
| tested_admissible_cases | Yes | |
| baseline_position_at_evaluation_km | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the read-only, idempotent, non-destructive profile, and the description adds real behavioral context: perturbations are hypothetical rather than new data, non-convergence is inconclusive rather than failure, and none_found only covers the examined cases. It stops short of describing runtime cost or limits beyond the case count.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the action, then the precondition and the interpretation caveats. Every sentence carries distinct information with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a complex nested schema and an output schema that covers returns, the description adequately conveys the hypothetical framing and result-interpretation caveats, but leaves the five required parameters largely unguided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Coverage is reported at 0% for five required top-level parameters; the description hints at the case count (1–32) and the hypothetical flag, but the claim, bounds, and observations structures are left entirely to the schema. It does not compensate for the documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (refit) and resource (declared hypothetical angular/clock perturbations) with a stated goal: challenging reconstruction stability. The scope '1–32' and 'No new observations' further distinguish it from ingest-style siblings like assimilate_observation, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies the context (stability stress-testing against perturbations) and states a hard prerequisite ('Explicit hypothetical acknowledgement required'), but never names when to choose this over alternatives such as analyze_kinematics or assimilate_observation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queue fixed public synthetic pi (CPU/CUDA) or one of three discrete schedule scenarios (CPU only). No private data/custom code. Returns a ticket; poll get_network_job. Coordinator recomputes every accepted shard; no net speedup claim. Jobs may expire.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| backend | No | auto | |
| samples | Yes | ||
| workload | No | pi_chunk_v1 | |
| scenario_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations by disclosing the async ticket model, the required polling flow, job expiration ('Jobs may expire'), and the important caveat that the coordinator recomputes every accepted shard with no net speedup claim. These are non-obvious traits an agent must know before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with purpose and scope, then return/polling, then caveats. Some clauses are telegraphic ('no net speedup claim') but each carries information and nothing is padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description explains the return value (ticket) and the polling mechanism, plus lifecycle caveats and scope limits. It is largely complete for a 5-parameter submit tool, with the main gap being the semantics of seed and samples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the load. It maps the workload enum to the pi vs schedule modes and notes schedule scenarios are CPU only, which clarifies backend/workload/scenario_id relationships, but seed and samples are never explained, leaving some parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Queue') and resource ('fixed public synthetic pi ... or one of three discrete schedule scenarios'), and discriminates the two workload modes. It names get_network_job as the polling sibling, but does not differentiate itself from the broader set of siblings (e.g. simulate_pi).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'No private data/custom code' implies a when-not-to-use boundary, and 'poll get_network_job' implies the follow-up flow. However there is no explicit guidance on when to pick the pi workload versus the schedule scenarios, nor which sibling to choose for private/custom workloads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locally normalized geometric descriptors of 3–256 planar points: distances, nearest-neighbour isolation, centroid spread, PCA collinearity and histogram. The principal-axis mirror residual is null for isotropic noncoincident covariance, whose axes are undetermined. Rounded fingerprints are descriptive, not proofs of equivalence or method benefit.
| Name | Required | Description | Default |
|---|---|---|---|
| points | Yes | ||
| reference_distance_fraction | No |
| Name | Required | Description |
|---|---|---|
| n | Yes | |
| notes | Yes | |
| engine | Yes | |
| limits | Yes | |
| method | Yes | |
| statement | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| work_units | Yes | |
| assumptions | Yes | |
| descriptors | Yes | |
| fingerprint | Yes | |
| collinearity | Yes | |
| centrality_mean | Yes | |
| duplicate_pairs | Yes | |
| isolation_ratio | Yes | |
| mirror_residual | Yes | |
| contract_version | Yes | |
| nearest_neighbor | Yes | |
| bounding_diagonal | Yes | |
| centrality_spread | Yes | |
| distance_histogram | Yes | |
| isolation_mean_3nn | Yes | |
| close_pair_fraction | Yes | |
| mean_pairwise_distance | Yes | |
| principal_axes_defined | Yes | |
| median_pairwise_distance | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds genuine behavioral context beyond that, disclosing a degenerate case (principal-axis mirror residual is null for isotropic noncoincident covariance) and an interpretation caveat about rounded fingerprints. These are non-obvious traits an agent could not get from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler, and the core capability is front-loaded in the first sentence. The degenerate-case and caveat sentences each earn their place, though the vocabulary is heavy enough to slow comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described, and annotations carry the safety profile. However, with two parameters and zero schema coverage, the unexplained reference_distance_fraction plus absent usage guidance leaves the definition short of complete for an agent trying to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate and largely does not. The 3–256 point count is echoed, but 'reference_distance_fraction' is never mentioned or explained in the description, leaving its meaning and effect entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (3–256 planar points) and enumerates exactly what is computed: distances, nearest-neighbour isolation, centroid spread, PCA collinearity and histogram. The verb is implicit rather than stated, but an agent can tell this characterizes a point set geometrically and it is clearly distinct from siblings like analyze_kinematics or audit_statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not guidance and no named alternative. The only usage-adjacent content is the closing caveat that rounded fingerprints are 'descriptive, not proofs of equivalence or method benefit,' which hints at a limitation but does not tell the agent when to pick this tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fit position/velocity from 2–4 supplied azimuth/elevation tracks using constant velocity in spherical ECEF and declared angular noise/clocks. Reports fit status and conditional local uncertainty; no object identification or calibrated accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| observers | Yes |
| Name | Required | Description |
|---|---|---|
| grid | Yes | |
| state | Yes | |
| status | Yes | |
| reasons | Yes | |
| observers | Yes | |
| residuals | Yes | |
| elapsed_ms | Yes | |
| provenance | Yes | |
| trajectory | Yes | |
| baseline_km | Yes | |
| diagnostics | Yes | |
| limitations | Yes | |
| contract_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a safe, idempotent, closed-world read, and the description usefully adds behavioral scope: it reports fit status and conditional (not calibrated) uncertainty, and explicitly excludes object identification. These expectations about output meaning are meaningful added context beyond the structured hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences that front-load the operation, the model, and the range constraint, then close with output expectations and explicit limitations. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not explain return values, and it still summarizes the output (fit status, conditional uncertainty). For a complex nested-input compute tool the key semantic concepts and limitations are covered, leaving only field-level detail unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is effectively 0% for the single deeply nested 'observers' parameter, so the description must compensate. It partially does by mapping observers to 'tracks', sigma to 'angular noise', and clock_offset to 'clocks', but never explains lat/lon/elevation_m/samples/t_s semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a precise verb and resource ('Fit position/velocity from 2–4 supplied azimuth/elevation tracks') plus the underlying model (constant velocity in spherical ECEF). This is highly specific and lets an agent tell what it does without opening the schema, though it never names or contrasts a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The input constraints (2–4 tracks) imply when the tool is applicable, but there is no explicit when-to-use guidance or routing to alternatives such as compute_orbit or analyze_kinematics. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a structured arithmetic, shadow, ephemeris, statistics or route claim with a bounded native engine. Returns a model-scoped verdict and portable Ed25519 server receipt; never truth, authenticity or fraud certification. Route claims explicitly distinguish optimality from a supplied tour total. Native failures return no scientific verdict. Parameters and examples: /verify and /docs/mcp/.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | No | ||
| domain | Yes | ||
| parameters | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, non-destructive, non-open-world, and notably non-idempotent behavior, but the description adds real context beyond them: it discloses the return shape (model-scoped verdict plus portable Ed25519 server receipt), scopes what the verdict does not certify, and states the failure mode ('native failures return no scientific verdict'). The 'bounded native engine' phrasing hints at resource limits. It does not explain the surprising idempotentHint=false, which is the one remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then return value, then scope caveats, then the route-claim distinction and failure mode. Each sentence carries information, though the trailing docs pointer is a slightly inert way to end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly takes on the burden of explaining the return (verdict + receipt) and the failure case, which it does. For a nested, 3-parameter tool at 0% schema coverage, the in-line guidance on the free-form parameters object is thin, kept afloat by a documentation pointer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry the load, and it largely defers instead ('Parameters and examples: /verify and /docs/mcp/'). It gives useful semantics for the domain enum and clarifies that route claims distinguish 'optimality' from a supplied tour total (mapping to claim.kind), but the free-form 'parameters' object and the rest of the claim structure are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (verify) and resource (structured arithmetic, shadow, ephemeris, statistics or route claim), and enumerates the domains it covers. This distinguishes it from single-domain siblings like check_arithmetic, check_ephemeris, verify_shadows and route_optimizer, which an agent can separate without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The domain list implies when the tool applies (multi-domain structured claim verification), and it clarifies what the tool is NOT for ('never truth, authenticity or fraud certification'). However, it never explicitly says when to prefer this unified verifier over the domain-specific check_* / verify_shadows siblings, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check measured shadows using NOAA solar position, a ground-plane homography from 4–16 controls and Monte Carlo uncertainty. Returns conditional consistency, never image authenticity.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | ||
| shadow | Yes | ||
| samples | No | ||
| date_utc | Yes | ||
| latitude | Yes | ||
| longitude | Yes | ||
| pixel_sigma | No | ||
| second_shadow | No | ||
| control_points | Yes | ||
| time_sigma_minutes | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavioral context by clarifying that the result is conditional consistency, not image authenticity, which is critical for interpreting the output correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tightly written sentences with no wasted words. It front-loads the core action and ends with an important limitation, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 10 parameters, nested objects, no output schema, and no schema parameter descriptions, the definition is too sparse. It gives a high-level method and one output caveat but lacks enough detail to call the tool confidently or understand the full return semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 10 parameters, so the description carries the full burden. It only partially clarifies inputs, mentioning 4–16 control points and Monte Carlo uncertainty, but leaves date_utc, latitude, longitude, shadow, second_shadow, seed, samples, pixel_sigma, and time_sigma_minutes unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Check measured shadows' using NOAA solar position, homography, and Monte Carlo uncertainty. It is clear what the tool does, but it does not explicitly distinguish itself from closely related siblings such as check_shadow_track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any when-not-to-use conditions. The description implies a use case by naming 'measured shadows', but an agent still has to infer routing from the tool name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
scan_counterexample13 fields changedOutput schema / properties / contract_version / constPrevious value: -"0.1.0"New value: +"0.2.0"Output schema / properties / counterexamples / items / properties / comparison_guardAdded value: +{
+ "maximum": 1.7976931348623157e+308,
+ "minimum": 0,
+ "type": "number"
+}Output schema / properties / counterexamples / items / properties / expression_value / maximumPrevious value: -1e+308New value: +1.7976931348623157e+308Output schema / properties / counterexamples / items / properties / expression_value / minimumPrevious value: --1e+308New value: +-1.7976931348623157e+308Output schema / properties / counterexamples / items / properties / margin / maximumPrevious value: -1e+308New value: +1.7976931348623157e+308Output schema / properties / counterexamples / items / requiredPrevious value: -[
- "expression_value",
- "margin",
- "values"
-]New value: +[
+ "comparison_guard",
+ "expression_value",
+ "margin",
+ "values"
+]Output schema / properties / finite_evaluationsAdded value: +{
+ "maximum": 200000,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / first_counterexample / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "expression_value": {
- "maximum": 1e+308,
- "minimum": -1e+308,
- "type": "number"
- },
- "margin": {
- "maximum": 1e+308,
- "minimum": 0,
- "type": "number"
- },
- "values": {
- "items": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "maxLength": 32,
- "minLength": 1,
- "type": "string"
- },
- "value": {
- "maximum": 1000000,
- "minimum": -1000000,
- "type": "number"
- }
- },
- "required": [
- "name",
- "value"
- ],
- "type": "object"
- },
- "maxItems": 6,
- "minItems": 1,
- "type": "array"
- }
- },
- "required": [
- "expression_value",
- "margin",
- "values"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "comparison_guard": {
+ "maximum": 1.7976931348623157e+308,
+ "minimum": 0,
+ "type": "number"
+ },
+ "expression_value": {
+ "maximum": 1.7976931348623157e+308,
+ "minimum": -1.7976931348623157e+308,
+ "type": "number"
+ },
+ "margin": {
+ "maximum": 1.7976931348623157e+308,
+ "minimum": 0,
+ "type": "number"
+ },
+ "values": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "maxLength": 32,
+ "minLength": 1,
+ "type": "string"
+ },
+ "value": {
+ "maximum": 1000000,
+ "minimum": -1000000,
+ "type": "number"
+ }
+ },
+ "required": [
+ "name",
+ "value"
+ ],
+ "type": "object"
+ },
+ "maxItems": 6,
+ "minItems": 1,
+ "type": "array"
+ }
+ },
+ "required": [
+ "comparison_guard",
+ "expression_value",
+ "margin",
+ "values"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / stop_reasonAdded value: +{
+ "anyOf": [
+ {
+ "const": "grid_complete",
+ "type": "string"
+ },
+ {
+ "const": "evaluation_budget",
+ "type": "string"
+ },
+ {
+ "const": "counterexample_limit",
+ "type": "string"
+ }
+ ]
+}Output schema / properties / uncertain_evaluationsAdded value: +{
+ "maximum": 200000,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / undefined_evaluationsAdded value: +{
+ "maximum": 200000,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / verdict / anyOfPrevious value: -[
- {
- "const": "counterexamples_found",
- "type": "string"
- },
- {
- "const": "no_counterexample_in_scanned_box",
- "type": "string"
- }
-]New value: +[
+ {
+ "const": "counterexamples_found",
+ "type": "string"
+ },
+ {
+ "const": "no_counterexample_in_scanned_box",
+ "type": "string"
+ },
+ {
+ "const": "inconclusive",
+ "type": "string"
+ }
+]Output schema / requiredPrevious value: -[
- "assumptions",
- "bound",
- "complete",
- "contract_version",
- "counterexamples",
- "elapsed_ms",
- "engine",
- "evaluated",
- "expression",
- "first_counterexample",
- "grid_total",
- "limits",
- "method",
- "notes",
- "relation",
- "statement",
- "stopped_early",
- "tolerance",
- "verdict",
- "work_units",
- "provenance"
-]New value: +[
+ "assumptions",
+ "bound",
+ "complete",
+ "contract_version",
+ "counterexamples",
+ "elapsed_ms",
+ "engine",
+ "evaluated",
+ "expression",
+ "finite_evaluations",
+ "first_counterexample",
+ "grid_total",
+ "limits",
+ "method",
+ "notes",
+ "relation",
+ "statement",
+ "stop_reason",
+ "stopped_early",
+ "tolerance",
+ "uncertain_evaluations",
+ "undefined_evaluations",
+ "verdict",
+ "work_units",
+ "provenance"
+]tour_profile7 fields changedOutput schema / properties / contract_version / constPrevious value: -"0.1.0"New value: +"0.2.0"Output schema / properties / mirror_residual / anyOfAdded value: +[
+ {
+ "maximum": 2,
+ "minimum": 0,
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / mirror_residual / maximumRemoved value: -2Output schema / properties / mirror_residual / minimumRemoved value: -0Output schema / properties / mirror_residual / typeRemoved value: -"number"Output schema / properties / principal_axes_definedAdded value: +{
+ "type": "boolean"
+}Output schema / requiredPrevious value: -[
- "assumptions",
- "bounding_diagonal",
- "centrality_mean",
- "centrality_spread",
- "close_pair_fraction",
- "collinearity",
- "contract_version",
- "descriptors",
- "distance_histogram",
- "duplicate_pairs",
- "elapsed_ms",
- "engine",
- "fingerprint",
- "isolation_mean_3nn",
- "isolation_ratio",
- "limits",
- "mean_pairwise_distance",
- "median_pairwise_distance",
- "method",
- "mirror_residual",
- "n",
- "nearest_neighbor",
- "notes",
- "statement",
- "work_units",
- "provenance"
-]New value: +[
+ "assumptions",
+ "bounding_diagonal",
+ "centrality_mean",
+ "centrality_spread",
+ "close_pair_fraction",
+ "collinearity",
+ "contract_version",
+ "descriptors",
+ "distance_histogram",
+ "duplicate_pairs",
+ "elapsed_ms",
+ "engine",
+ "fingerprint",
+ "isolation_mean_3nn",
+ "isolation_ratio",
+ "limits",
+ "mean_pairwise_distance",
+ "median_pairwise_distance",
+ "method",
+ "mirror_residual",
+ "n",
+ "nearest_neighbor",
+ "notes",
+ "principal_axes_defined",
+ "statement",
+ "work_units",
+ "provenance"
+]scan_counterexampletour_profileshape_the_soundcheck_arithmeticverify_claimhear_the_shapekepler_stabilitypropagate_uncertaintycompute_orbit3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / requiredPrevious value: -[
- "semi_major_au",
- "eccentricity",
- "elapsed_days"
-]New value: +[
+ "eccentricity",
+ "elapsed_days",
+ "semi_major_au"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "distance_au": {
+ "maximum": 60,
+ "minimum": 0,
+ "type": "number"
+ },
+ "elapsed_ms": {
+ "maximum": 1000000000000,
+ "minimum": 0,
+ "type": "number"
+ },
+ "engine": {
+ "const": "rust-cpu",
+ "type": "string"
+ },
+ "method": {
+ "maxLength": 1024,
+ "minLength": 1,
+ "type": "string"
+ },
+ "orbit": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "x": {
+ "maximum": 60,
+ "minimum": -60,
+ "type": "number"
+ },
+ "y": {
+ "maximum": 60,
+ "minimum": -60,
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "maxItems": 241,
+ "minItems": 241,
+ "type": "array"
+ },
+ "period_days": {
+ "maximum": 61000,
+ "minimum": 0,
+ "type": "number"
+ },
+ "position": {
+ "additionalProperties": false,
+ "properties": {
+ "x": {
+ "maximum": 60,
+ "minimum": -60,
+ "type": "number"
+ },
+ "y": {
+ "maximum": 60,
+ "minimum": -60,
+ "type": "number"
+ }
+ },
+ "required": [
+ "x",
+ "y"
+ ],
+ "type": "object"
+ },
+ "provenance": {
+ "additionalProperties": false,
+ "properties": {
+ "client": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "version": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "version"
+ ],
+ "type": "object"
+ },
+ "identity_source": {
+ "type": "string"
+ },
+ "model": {
+ "type": "null"
+ },
+ "server": {
+ "const": "scorecompute",
+ "type": "string"
+ },
+ "tool": {
+ "const": "compute_orbit",
+ "type": "string"
+ }
+ },
+ "required": [
+ "tool",
+ "server",
+ "client",
+ "identity_source",
+ "model"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "distance_au",
+ "elapsed_ms",
+ "engine",
+ "method",
+ "orbit",
+ "period_days",
+ "position",
+ "provenance"
+ ],
+ "type": "object"
+}forge_route_policy24 fields changedOutput schema / properties / attempted / maximumPrevious value: -9007199254740991New value: +64Output schema / properties / contract_version / constPrevious value: -"0.1.0"New value: +"0.2.0"Output schema / properties / kernel_versionAdded value: +{
+ "const": "1.0.0",
+ "type": "string"
+}Output schema / properties / request_sha256Added value: +{
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+}Output schema / properties / search_versionAdded value: +{
+ "const": "1.0.0",
+ "type": "string"
+}Output schema / properties / seed / maximumPrevious value: -9007199254740991New value: +4294967295Output schema / properties / selected / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "fitness": {
- "additionalProperties": false,
- "properties": {
- "maximum_length_ratio": {
- "minimum": 0,
- "type": "number"
- },
- "mean_length_km": {
- "minimum": 0,
- "type": "number"
- },
- "mean_length_ratio": {
- "minimum": 0,
- "type": "number"
- },
- "total_fuel": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- }
- },
- "required": [
- "mean_length_ratio",
- "maximum_length_ratio",
- "mean_length_km",
- "total_fuel"
- ],
- "type": "object"
- },
- "program": {
- "additionalProperties": false,
- "properties": {
- "score": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "left": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "right": {
- "additionalProperties": false,
- "properties": {
- "name": {
- "enum": [
- "distance",
- "depot",
- "isolation",
- "centrality",
- "progress"
- ],
- "type": "string"
- },
- "op": {
- "enum": [
- "feature",
- "constant",
- "add",
- "sub",
- "mul",
- "min",
- "max"
- ],
- "type": "string"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "value": {
- "anyOf": [
- {
- "const": -2,
- "type": "number"
- },
- {
- "const": -1,
- "type": "number"
- },
- {
- "const": -0.5,
- "type": "number"
- },
- {
- "const": 0,
- "type": "number"
- },
- {
- "const": 0.5,
- "type": "number"
- },
- {
- "const": 1,
- "type": "number"
- },
- {
- "const": 2,
- "type": "number"
- }
- ]
- }
- },
- "required": [
- "op"
- ],
- "type": "object"
- },
- "version": {
- "const": 1,
- "type": "number"
- }
- },
- "required": [
- "version",
- "score"
- ],
- "type": "object"
- },
- "program_sha256": {
- "pattern": "^[a-f0-9]{64}$",
- "type": "string"
- },
- "trial_index": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- }
- },
- "required": [
- "trial_index",
- "program",
- "program_sha256",
- "fitness"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "fitness": {
+ "additionalProperties": false,
+ "properties": {
+ "maximum_fuel_ratio": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "maximum_length_ratio": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "mean_fuel_ratio": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "mean_length_km": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "mean_length_ratio": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "selection_objective": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "total_fuel": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "mean_length_ratio",
+ "maximum_length_ratio",
+ "mean_length_km",
+ "total_fuel",
+ "mean_fuel_ratio",
+ "maximum_fuel_ratio",
+ "selection_objective"
+ ],
+ "type": "object"
+ },
+ "program": {
+ "additionalProperties": false,
+ "properties": {
+ "score": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "left": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "right": {
+ "additionalProperties": false,
+ "properties": {
+ "name": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "op": {
+ "enum": [
+ "feature",
+ "constant",
+ "add",
+ "sub",
+ "mul",
+ "min",
+ "max"
+ ],
+ "type": "string"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "value": {
+ "anyOf": [
+ {
+ "const": -2,
+ "type": "number"
+ },
+ {
+ "const": -1,
+ "type": "number"
+ },
+ {
+ "const": -0.5,
+ "type": "number"
+ },
+ {
+ "const": 0,
+ "type": "number"
+ },
+ {
+ "const": 0.5,
+ "type": "number"
+ },
+ {
+ "const": 1,
+ "type": "number"
+ },
+ {
+ "const": 2,
+ "type": "number"
+ }
+ ]
+ }
+ },
+ "required": [
+ "op"
+ ],
+ "type": "object"
+ },
+ "version": {
+ "const": 1,
+ "type": "number"
+ }
+ },
+ "required": [
+ "version",
+ "score"
+ ],
+ "type": "object"
+ },
+ "program_sha256": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "simplification": {
+ "additionalProperties": false,
+ "properties": {
+ "compiled_program_sha256": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "executed_node_count": {
+ "maximum": 31,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "original_node_count": {
+ "maximum": 31,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "original_program_sha256": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "required_features": {
+ "items": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "type": "array"
+ },
+ "simplifier_version": {
+ "const": "1.0.0",
+ "type": "string"
+ }
+ },
+ "required": [
+ "simplifier_version",
+ "original_program_sha256",
+ "compiled_program_sha256",
+ "original_node_count",
+ "executed_node_count",
+ "required_features"
+ ],
+ "type": "object"
+ },
+ "trial_index": {
+ "maximum": 63,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "trial_index",
+ "program",
+ "program_sha256",
+ "simplification",
+ "fitness"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / selectionAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "maximum_case_fuel_ratio": {
+ "type": "null"
+ },
+ "maximum_executed_nodes": {
+ "const": 31,
+ "type": "number"
+ },
+ "maximum_mean_fuel_ratio": {
+ "type": "null"
+ },
+ "maximum_training_length_ratio": {
+ "const": 1.1,
+ "type": "number"
+ },
+ "mean_fuel_penalty": {
+ "const": 0.01,
+ "type": "number"
+ }
+ },
+ "required": [
+ "maximum_training_length_ratio",
+ "mean_fuel_penalty",
+ "maximum_mean_fuel_ratio",
+ "maximum_case_fuel_ratio",
+ "maximum_executed_nodes"
+ ],
+ "type": "object"
+}Output schema / properties / stop_reason / enumAdded value: +[
+ "candidate_budget_exhausted",
+ "caller_stopped"
+]Output schema / properties / trials / items / properties / admission_failuresAdded value: +{
+ "items": {
+ "enum": [
+ "incomplete_or_nonconverged_training_evaluation",
+ "maximum_training_length_ratio",
+ "maximum_mean_fuel_ratio",
+ "maximum_case_fuel_ratio",
+ "maximum_executed_nodes"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "type": "array"
+}Output schema / properties / trials / items / properties / admittedAdded value: +{
+ "type": "boolean"
+}Output schema / properties / trials / items / properties / cases / maxItemsAdded value: +8Output schema / properties / trials / items / properties / enumeration_indexAdded value: +{
+ "anyOf": [
+ {
+ "maximum": 364,
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / trials / items / properties / fitness / anyOfPrevious value: -[
- {
- "additionalProperties": false,
- "properties": {
- "maximum_length_ratio": {
- "minimum": 0,
- "type": "number"
- },
- "mean_length_km": {
- "minimum": 0,
- "type": "number"
- },
- "mean_length_ratio": {
- "minimum": 0,
- "type": "number"
- },
- "total_fuel": {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- }
- },
- "required": [
- "mean_length_ratio",
- "maximum_length_ratio",
- "mean_length_km",
- "total_fuel"
- ],
- "type": "object"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "additionalProperties": false,
+ "properties": {
+ "maximum_fuel_ratio": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "maximum_length_ratio": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "mean_fuel_ratio": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "mean_length_km": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "mean_length_ratio": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "selection_objective": {
+ "minimum": 0,
+ "type": "number"
+ },
+ "total_fuel": {
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+ }
+ },
+ "required": [
+ "mean_length_ratio",
+ "maximum_length_ratio",
+ "mean_length_km",
+ "total_fuel",
+ "mean_fuel_ratio",
+ "maximum_fuel_ratio",
+ "selection_objective"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / trials / items / properties / generation / enumAdded value: +[
+ "baseline",
+ "enumerated_small_expression",
+ "generated",
+ "crossover",
+ "point_mutation",
+ "subtree_mutation"
+]Output schema / properties / trials / items / properties / index / maximumPrevious value: -9007199254740991New value: +63Output schema / properties / trials / items / properties / parents / maxItemsAdded value: +2Output schema / properties / trials / items / properties / population_afterAdded value: +{
+ "items": {
+ "maximum": 63,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "maxItems": 32,
+ "type": "array"
+}Output schema / properties / trials / items / properties / reused_trial / anyOfPrevious value: -[
- {
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
- },
- {
- "type": "null"
- }
-]New value: +[
+ {
+ "maximum": 63,
+ "minimum": 0,
+ "type": "integer"
+ },
+ {
+ "type": "null"
+ }
+]Output schema / properties / trials / items / properties / simplificationAdded value: +{
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "compiled_program_sha256": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "executed_node_count": {
+ "maximum": 31,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "original_node_count": {
+ "maximum": 31,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "original_program_sha256": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "required_features": {
+ "items": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "type": "array"
+ },
+ "simplifier_version": {
+ "const": "1.0.0",
+ "type": "string"
+ }
+ },
+ "required": [
+ "simplifier_version",
+ "original_program_sha256",
+ "compiled_program_sha256",
+ "original_node_count",
+ "executed_node_count",
+ "required_features"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+}Output schema / properties / trials / items / properties / status / enumAdded value: +[
+ "reused",
+ "invalid_program",
+ "failed",
+ "evaluated_admitted",
+ "evaluated_not_admitted"
+]Output schema / properties / trials / items / requiredPrevious value: -[
- "index",
- "program",
- "program_sha256",
- "parents",
- "generation",
- "status",
- "reused_trial",
- "fitness",
- "cases",
- "generator_state_after"
-]New value: +[
+ "index",
+ "program",
+ "program_sha256",
+ "parents",
+ "generation",
+ "enumeration_index",
+ "status",
+ "reused_trial",
+ "simplification",
+ "fitness",
+ "admitted",
+ "admission_failures",
+ "cases",
+ "generator_state_after",
+ "population_after"
+]Output schema / properties / unique_evaluated / maximumPrevious value: -9007199254740991New value: +64Output schema / requiredPrevious value: -[
- "contract_version",
- "seed",
- "train_sha256",
- "budget",
- "baseline_program_sha256",
- "trials",
- "selected",
- "attempted",
- "unique_evaluated",
- "stop_reason",
- "promotion",
- "elapsed_ms",
- "limitations",
- "provenance"
-]New value: +[
+ "contract_version",
+ "search_version",
+ "kernel_version",
+ "seed",
+ "request_sha256",
+ "train_sha256",
+ "budget",
+ "selection",
+ "baseline_program_sha256",
+ "trials",
+ "selected",
+ "attempted",
+ "unique_evaluated",
+ "stop_reason",
+ "promotion",
+ "elapsed_ms",
+ "limitations",
+ "provenance"
+]run_route_policy9 fields changedOutput schema / properties / contract_version / constPrevious value: -"0.1.0"New value: +"0.2.0"Output schema / properties / fuel_limit / exclusiveMinimumRemoved value: -0Output schema / properties / fuel_limit / maximumPrevious value: -9007199254740991New value: +4000000Output schema / properties / fuel_limit / minimumAdded value: +1Output schema / properties / fuel_used / maximumPrevious value: -9007199254740991New value: +4000000Output schema / properties / kernel_versionAdded value: +{
+ "const": "1.0.0",
+ "type": "string"
+}Output schema / properties / simplificationAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "compiled_program_sha256": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "executed_node_count": {
+ "maximum": 31,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "original_node_count": {
+ "maximum": 31,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "original_program_sha256": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "required_features": {
+ "items": {
+ "enum": [
+ "distance",
+ "depot",
+ "isolation",
+ "centrality",
+ "progress"
+ ],
+ "type": "string"
+ },
+ "maxItems": 5,
+ "type": "array"
+ },
+ "simplifier_version": {
+ "const": "1.0.0",
+ "type": "string"
+ }
+ },
+ "required": [
+ "simplifier_version",
+ "original_program_sha256",
+ "compiled_program_sha256",
+ "original_node_count",
+ "executed_node_count",
+ "required_features"
+ ],
+ "type": "object"
+}Output schema / properties / stop_reason / enumAdded value: +[
+ "heuristic_converged",
+ "fuel_exhausted",
+ "time_budget_exhausted"
+]Output schema / requiredPrevious value: -[
- "contract_version",
- "program_sha256",
- "order",
- "legs",
- "length_km",
- "initial_length_km",
- "stop_reason",
- "fuel_used",
- "fuel_limit",
- "elapsed_ms",
- "exact",
- "all_points_coincident",
- "limitations",
- "provenance"
-]New value: +[
+ "contract_version",
+ "kernel_version",
+ "program_sha256",
+ "simplification",
+ "order",
+ "legs",
+ "length_km",
+ "initial_length_km",
+ "stop_reason",
+ "fuel_used",
+ "fuel_limit",
+ "elapsed_ms",
+ "exact",
+ "all_points_coincident",
+ "limitations",
+ "provenance"
+]forge_route_policyrun_route_policyplan_observation1 field changedOutput schema / properties / policy_traceAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "artifact_sha256": {
+ "pattern": "^[a-f0-9]{64}$",
+ "type": "string"
+ },
+ "evaluated_candidates": {
+ "maximum": 64,
+ "minimum": 0,
+ "type": "integer"
+ },
+ "execution": {
+ "enum": [
+ "reference_small_workload",
+ "cached_exact_fisher",
+ "reference_policy_disabled",
+ "not_executed"
+ ],
+ "type": "string"
+ },
+ "policy_id": {
+ "const": "observation_exact_cached_fisher",
+ "type": "string"
+ },
+ "policy_version": {
+ "const": "0.3.0",
+ "type": "string"
+ },
+ "requested_candidates": {
+ "maximum": 64,
+ "minimum": 1,
+ "type": "integer"
+ },
+ "selection": {
+ "const": "exhaustive_all_supplied",
+ "type": "string"
+ }
+ },
+ "required": [
+ "policy_id",
+ "policy_version",
+ "artifact_sha256",
+ "selection",
+ "execution",
+ "requested_candidates",
+ "evaluated_candidates"
+ ],
+ "type": "object"
+}build_robust_plan1 field changedInput schema / properties / allowed_tools / maxItemsPrevious value: -13New value: +14compose_capabilities1 field changedInput schema / properties / constraints / properties / allowed_tools / maxItemsPrevious value: -19New value: +20execute_composition1 field changedInput schema / properties / constraints / properties / allowed_tools / maxItemsPrevious value: -19New value: +20plan_golden_hourplan_mission1 field changedInput schema / properties / allowed_tools / maxItemsPrevious value: -13New value: +14assimilate_observationcompose_capabilities1 field changedInput schema / properties / constraints / properties / allowed_tools / maxItemsPrevious value: -14New value: +19execute_composition1 field changedInput schema / properties / constraints / properties / allowed_tools / maxItemsPrevious value: -14New value: +19improve_scheduleplan_observationstress_test_observationsubmit_network_job2 fields changedInput schema / properties / scenario_idAdded value: +{
+ "enum": [
+ "single_80_deadline_90",
+ "pair_60_40_deadline_100",
+ "pair_60_40_deadline_110"
+ ],
+ "type": "string"
+}Input schema / properties / workloadAdded value: +{
+ "default": "pi_chunk_v1",
+ "enum": [
+ "pi_chunk_v1",
+ "schedule_probe_v1"
+ ],
+ "type": "string"
+}get_network_jobnetwork_statussubmit_network_jobtriangulate_tracksbuild_robust_plan1 field changedInput schema / properties / allowed_tools / maxItemsPrevious value: -12New value: +13compose_capabilities2 fields changedInput schema / properties / adaptersAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "route_durations.v1": {
+ "additionalProperties": false,
+ "properties": {
+ "speed_kmh": {
+ "maximum": 150,
+ "minimum": 1,
+ "type": "number"
+ }
+ },
+ "required": [
+ "speed_kmh"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}Input schema / properties / constraints / properties / allowed_tools / maxItemsPrevious value: -13New value: +14execute_composition2 fields changedInput schema / properties / adaptersAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "route_durations.v1": {
+ "additionalProperties": false,
+ "properties": {
+ "speed_kmh": {
+ "maximum": 150,
+ "minimum": 1,
+ "type": "number"
+ }
+ },
+ "required": [
+ "speed_kmh"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}Input schema / properties / constraints / properties / allowed_tools / maxItemsPrevious value: -13New value: +14plan_mission1 field changedInput schema / properties / allowed_tools / maxItemsPrevious value: -12New value: +13route_optimizercompose_capabilitiesexecute_compositionlist_composition_capabilitiesbuild_robust_planlist_capabilitiesplan_missionSelf-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Architecture compiler for AI code. 11 tools, 92 actions, 872 Lean4 proofs, 100/100 self-cert.
40 MCP tools: multi-chain RPC, market and transaction decisions, AI, EU compliance and US imports
Verified cyber-physical AI tools. 25 MCP tools, x402-payable on Base.
Add one secure layer between your agents and this server.
