eda_sys_window_url_replace_state

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'modify URL history stack info', which is vague. It does not explain that it replaces the current entry without adding a new one, nor does it mention side effects like navigation or page reload, or any error conditions. This is insufficient for a mutation tool.

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 very short, which is concise, but the Chinese sentence is vague and does not convey the precise behavior. The signature is front-loaded, which is helpful, but the rest adds little. It is not overly verbose, so it earns a middle score.

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 simple tool with no output schema, the description omits critical details: how to structure the args array, the distinction from push_state, and the exact effect on the browser history. The optional windowId parameter is also not explained in the description. An agent would struggle to invoke this correctly without additional knowledge.

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 description includes the function signature 'url: string', which adds the type and order of the primary parameter. However, it does not clarify how the url should be passed inside the 'args' array defined in the schema. The schema descriptions are generic ('JSON parameter array in official signature order'), so the description only partially compensates. Since schema coverage is 100%, a baseline of 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?

The description states the action as 'modify the current URL history stack information', which is a clear verb-resource pair, but it does not explicitly state that this replaces the current entry rather than adding a new one. The tool name includes 'replace_state', which hints at the behavior, but the description itself is ambiguous and does not differentiate from the sibling push_state tool. This is more than a tautology but lacks specificity.

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 no guidance on when to use this tool versus alternatives such as eda_sys_window_url_push_state. It does not mention any context or exclusions, leaving the agent to infer the appropriate use case from the name alone. This is a clear gap for a tool with a close sibling.

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