Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely non-redundant context: the returned numbers are conditional on the assumption and are explicitly 'not predictions that it will happen' — a critical interpretation caveat an agent would otherwise miss. It leaves mild tension around 'Set' versus a read-only tool, though 'under that assumption' largely resolves it.

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 short sentences with zero filler: the action is front-loaded and the interpretive caveat follows immediately. 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 scenario tool with an output schema, the description covers the action and the meaning of the returned values, which is the part the output schema cannot convey. It omits how 'links' are determined and whether the assumption is transient, but those are minor against the structured coverage.

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 defines both parameters, including 'series' as a series key or model id and 'value' as the seven-day number in the model's unit. The description restates the seven-day framing but adds no syntax, format, or unit guidance beyond what the schema provides, so 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 concrete verb+resource pair: 'Set one World Machine model's number in seven days and read the models that move through the links' — a what-if scenario evaluation that returns the downstream models. That distinguishes it in spirit from siblings like world, calibration, or search_models, but the metaphorical nouns ('number', 'links', 'move through') keep it from being crisply self-explanatory without 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?

Usage is implied (run a hypothetical assumption on one model and see the affected models) but never stated as when-to-use. No alternative is named for getting the baseline/actual numbers instead of the scenario, and no preconditions (e.g., needing an existing model or series key) are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.