get_page_info

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

With no annotations provided, the description carries the full burden, and it does so thoroughly. It labels the operation READ-ONLY, states what it does not do, explains the behavior when no browser session is active, and explicitly says it does not navigate, reload, click, type, or modify the page.

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?

Although the description is long, it is organized into clear sections with front-loaded purpose, a structured return specification, and an explicit tool-selection guide. Each sentence adds necessary guidance, especially given the large sibling set and absence of annotations.

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 description fully covers what the tool returns, what it does not do, when to use it, and how it behaves without an active browser session. Given the simple parameterless signature and rich output schema, nothing essential is missing for an agent to select and call it correctly.

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 tool has zero parameters and an empty input schema, so there is no parameter ambiguity. The description adds value by clearly documenting the returned dictionary keys and their meanings, which is the relevant semantic content for a parameterless metadata tool.

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 opens with a specific verb and resource: 'Get current browser session and page metadata.' It explicitly positions itself as the primary tool for determining the current browser location after navigation, clicks, or tab switches, and distinguishes itself from content, element, and condition-checking siblings.

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 'Tool selection' section gives direct, condition-based routing: 'Need URL, title, origin, or User-Agent -> use get_page_info' and maps each alternative need to a specific sibling tool. This leaves no ambiguity about when to use this tool versus find_elements, get_content, check_condition, wait_for, or assert_condition.

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