control

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

With no annotations, the description carries the full disclosure burden and does the most important part: reset is described as returning to the initial state, which signals state loss, and it warns that time-related modifications need a reset to take effect. It does not cover whether 'run' resumes from a paused state or starts fresh, nor whether any state is persisted or recoverable after reset.

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 no filler, and the side-effect caveat is packed into a parenthetical rather than a separate paragraph. The guide pointer leads, which slightly delays the purpose statement, but the whole thing is still front-loaded and quick 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 single-enum-parameter tool with no output schema, the description covers purpose, the guide prerequisite, action semantics, and the reset-after-time-change coupling. The remaining gap is what the tool returns or how state changes are observable via get_run_state, which would help an agent verify results.

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 enum is already listed, so the baseline is 3; the description earns above that by explaining the effect of each enum value, especially reset's 'back to initial state' semantics and its role in activating time changes, which the schema's bare '控制动作' does not convey.

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 the resource ('仿真控制' / simulation control) and enumerates the three concrete actions (run/stop/reset), each with a Chinese gloss, so an agent knows exactly what this tool manipulates. It is clearly separated from time-configuration siblings like set_datetime and set_run_speed by framing them as things that require a later reset.

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 an explicit prerequisite (call get_guide first if the guide has not been read) and an explicit operational rule: time-related changes only take effect after reset. That is real when-to-use guidance rather than an implied one. It stops short of stating when not to use this versus the dedicated setters (e.g., whether run/stop are sufficient or whether set_run_speed must precede run).

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