get_page

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

No annotations are provided, so the description carries the full behavioral burden. It only lists what can be retrieved, never stating whether the call is read-only, whether it waits for page load, what happens when the type parameter is omitted, or any permission requirements.

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?

A single short parenthetical clause with the verb front-loaded and zero filler. Every word earns its place in the description.

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 no output schema and no annotations, the description is too sparse. It leaves critical behavior unstated, especially what is returned when the optional 'type' parameter is omitted and what each mode actually produces.

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 0%, and the description merely repeats the five enum values already present in the schema. It adds no meaning for ambiguous values such as 'source' or 'viewport' and does not explain optionality or the default behavior when 'type' is omitted.

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?

Specific verb + resource ('Get page information') with the retrievable data types enumerated, so the tool's core purpose is clear. It does not distinguish itself from sibling getters such as get_url, get_title, or get_text, which prevents a 5.

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 when-to-use guidance, no alternatives, and no conditions are given. The enum implies selectable fields but does not route an agent between this tool and more specific siblings like get_url or get_title.

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