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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses one useful trait—'No browser is launched'—but fails to mention whether a network request is made, whether data is only checked and discarded, or what the success/failure response looks like. The parameter descriptions hint at 'discarded after the shape check,' but the main description does not explain this behavior coherently.

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 short and front-loads the core action, with 'No browser is launched' adding a valuable exclusion. However, it is under-specified to the point of being incomplete, and the two sentences do not adequately cover the tool's complexity (seven parameters, no output schema). Thus it is concise but not effectively structured for agent use.

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?

Given seven heterogeneous parameters, no required fields, no output schema, and no annotations, this description is grossly incomplete. An agent cannot determine what to pass, whether to pass one or multiple of the parameters, what the tool returns, or what side effects might occur. The description leaves too many critical invocation details unstated.

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 input schema provides descriptions for all seven parameters, so the baseline is 3; however, these descriptions are terse and ambiguous ('discarded after the shape check'). The tool description does not clarify which parameters are relevant to 'checking whether a URL can be opened,' nor does it indicate required versus optional parameters. Since the schema already carries the burden of parameter names and short descriptions, the description adds no additional semantic value.

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 and resource: 'Check whether a URL can be opened.' It also distinguishes itself from a browser-based alternative with 'No browser is launched,' which clearly separates it from siblings like browser-url-ok. However, it does not define what 'opened' means (e.g., network reachability vs. syntactic validity), so it is not fully precise.

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 offers no explicit guidance on when to use this tool versus alternatives such as browser-url-ok, normalize-url, or fetch-status. It only mentions that no browser is launched, which implies a lightweight check, but does not state conditions or exclusions. The presence of heterogeneous parameters (city, feed, json, path) further muddies the intended use case without any routing guidance.

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