eda_sys_window_get_url_param

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that the return type is string | null, which is valuable because it indicates a possible null return when the parameter is absent. However, it does not mention whether the tool can throw errors, how it handles missing keys beyond returning null, or any side effects. The return type hint adds some transparency but not extensive behavior context.

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 extremely brief, comprising a signature and two short Chinese lines. It is concise with no redundant content, though it could be better structured—for example, a clear description in English and a usage note would improve clarity. The brevity is efficient, but it borders on under-specification.

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 is simple with only one functional parameter (key). The description states the return type and that it returns the parameter value, which covers the output expectations. However, it does not provide an example, explain what constitutes a valid 'key', or clarify how the args array should be populated beyond the schema. Given the low complexity and full schema descriptions, the description is minimally adequate but lacks illustrative detail.

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% for both parameters; the args array is described as 'JSON parameter array in official signature order' and windowId as 'target EDA window ID; omit for current active window'. The description adds a function signature showing key: string, which helps map the conceptual key to the args array, but it does not elaborate beyond that. Since the schema already documents the parameters adequately, 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 it gets a URL parameter and returns the parameter value. The verb 'get' and the resource 'URL parameter' are specific, and the tool name clearly indicates its function. It is distinguishable from siblings like eda_sys_window_get_url_anchor and eda_sys_window_get_viewport_size, though it does not explicitly contrast 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?

There is no guidance on when to use this tool versus alternatives, nor any mention of context such as needing a query string or that it is a read-only getter. The description simply states what it does without any usage rules, prerequisites, or exclusions. An agent would have to infer the appropriate context from the name and schema.

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