eda_sys_window_get_url_anchor

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only the return type (string) and that the return value is the URL anchor value, which is essentially a restatement of the purpose. It omits what an anchor is (the # fragment), edge-case behavior when no anchor exists, and how the windowId parameter affects which window's anchor is read.

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 three short lines with the signature and purpose front-loaded. There is minor redundancy from bilingual duplication ('获取 URL 锚点' and 'returns: URL 锚点值' convey nearly the same information), but it is appropriately sized for a trivial getter with no wasted sentences.

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 low-complexity read tool with no output schema, the description does state the return type and value, and the schema fully documents the parameters. However, with no annotations and no output schema, it leaves gaps: it never defines what constitutes a URL anchor, describes edge cases, or notes whether any window context is required. Close to adequate but with 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?

Schema description coverage is 100% (both args and windowId are documented in the schema), so the baseline is 3. The description's signature 'sys_Window.getUrlAnchor()' hints that the underlying API takes no positional arguments, implying the args array should be empty, which adds slight value beyond the schema, but this requires 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?

The description states a specific verb+resource: '获取 URL 锚点' (get URL anchor) with the explicit method signature 'sys_Window.getUrlAnchor() -> string'. This is clear and specific enough to be distinguished from the sibling eda_sys_window_get_url_param, since it names the anchor rather than a parameter, though it stops short of explicitly differentiating itself.

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 guidance is provided on when to use this tool versus alternatives. It does not mention when to prefer it over get_url_param, get_viewport_size, or other window getters, and gives no conditions, prerequisites, or exclusions. The usage context must be inferred entirely from the tool name.

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