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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions that no browser is launched, but does not disclose whether a network request is made, whether the operation is read-only, or what the outcome indicates. It also does not explain the purpose of the many parameters that are 'discarded' or how they relate to checking a URL.

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 a single sentence with no wasted words, and the key constraint ('No browser is launched') is front-loaded. It is appropriately concise, though it could incorporate more useful information without losing brevity.

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 tool with 9 parameters, no required fields, no output schema, and no annotations, this description is severely incomplete. It does not explain the purpose of most parameters, what the tool actually does beyond a vague 'check', or what the return value signifies. An agent cannot determine correct usage or expected behavior from this definition alone.

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 schema descriptions cover all 9 parameters with explanations (e.g., 'discarded after the shape check'), so the schema already provides meaning. The tool description adds no parameter-level detail. However, the description fails to reconcile why parameters like 'city' or 'json' are part of a URL-check tool, which reduces the added value beyond the schema. Baseline of 3 is appropriate since schema coverage is 100%.

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 clear verb ('Check') and resource ('a URL'), and adds a distinguishing behavior ('No browser is launched'). However, it does not explain what 'can be opened' means precisely (e.g., HTTP reachability, format validation), and the input schema includes many unrelated parameters (city, json, path, zone, query) that the description does not account for, creating confusion about the tool's actual scope.

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 siblings like 'playwright-url-ok', 'fetch-status', or 'normalize-url'. It only states what it does and that no browser is launched, but does not mention alternatives or conditions for selection. This leaves the agent without routing information.

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