page_info

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 reveals the return shape ({title, url}) but doesn't state whether this is a cheap synchronous read, whether it navigates or waits for load, or whether it could fail (e.g., on blank tabs or non-HTML pages). The return-shape disclosure is helpful but minimal.

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 concise — a single signature line. The return type is front-loaded in functional notation which is efficient. However, it borders on under-specification rather than refined conciseness, slightly reducing the score.

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?

This is a very simple tool — zero parameters, no output schema field disclosure needed beyond the return signature it already shows. The '{title, url}' return shape is disclosed. However, given the large sibling set with overlapping capabilities (state, page_text, get_markdown), the description is not complete enough to disambiguate it from those alternatives, which is contextually important.

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 schema coverage is 100% (vacuous). With no parameters, the description has nothing to clarify about arguments, so the baseline of 4 (0 params) applies. The 'no arguments needed' nature is implicitly clear from the signature.

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 'page_info() → {title, url}' indicates the tool returns page title and URL, but gives no resource context beyond the name itself. It doesn't clarify whether 'page' refers to the active tab, current DOM document, or browser state, making the purpose partially vague. The name 'page_info' plus the return signature suggest it fetches metadata about the current page, but this isn't explicitly stated.

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 given for when to use this tool versus alternatives. With siblings like 'state', 'page_html', 'page_text', 'get_markdown', and 'list_tabs', an agent would benefit from knowing this returns lightweight title/url metadata without full content. The context is entirely implied by the name, not stated.

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