extract_table

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 states the output format and gives no information about table selection behavior, how multiple tables are handled, how limit affects rows, whether headers are included, or what happens when no table matches.

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, efficient sentence that clearly front-loads the main purpose. It contains no wasted words, though it is so brief that it misses opportunities to convey important usage and behavior details.

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 no output schema and no annotations, the description leaves out important operational details such as how limit interacts with row extraction, whether it targets the first matching table, what the JSON array entries look like, and what error or empty behavior occurs when no table is found. More context is needed for reliable invocation.

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 already documents both parameters with descriptions and defaults: limit is 'Max rows' and selector is 'CSS selector for the table'. The description adds little beyond restating the HTML table context, so it meets the baseline for high schema coverage without adding significant 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 action ('Extract data'), a specific resource ('HTML table'), and a clear output format ('JSON array'). It is distinguishable from broader siblings like get_text or get_html by focusing on structured table extraction, though it does not explicitly name any sibling alternatives.

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 gives no guidance on when to use this tool versus alternatives such as query_selector_all, get_text, or extract_structured. It also does not clarify whether it operates on the current page, a URL, or a provided HTML source, leaving usage context ambiguous.

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