Fetch Page Content

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 does reveal one genuine behavior — the default extraction path (Jina Reader) with a native HTTP fallback. But it silently omits the semantics of the other five renderer modes (wikipedia, internet_archive, arxiv, stack_exchange are opaque), failure/redirect behavior, and truncation behavior tied to max_length. No contradiction exists since there are no annotations, but the disclosure is thin.

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?

Two sentences with zero wasted words and the core purpose front-loaded in the first sentence — structurally efficient. However, for a tool exposing a 6-option enum with opaque values and a truncation parameter, this is under-sized rather than appropriately concise. Efficient formatting at the cost of completeness.

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 tool has three parameters (one an opaque 6-value enum), no annotations, and no output schema — so the description must be rich to compensate, and it is not. Missing: explanation of the six renderer modes, max_length semantics, what the extraction returns, and failure handling. For a fetch tool with this complexity, the description is well short of adequate.

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 only 33% (url only), so the description was required to compensate for renderer and max_length. It barely does: the only nod is 'Jina Reader by default,' which telegraphs the renderer's default. The six enum options are completely unexplained (what does a 'wikipedia' or 'stack_exchange' renderer do?), and max_length's units/semantics never appear. The description adds almost nothing beyond the schema.

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 verb and resource ('Fetch and extract URL content') and adds the dominant mechanism (Jina Reader, HTTP fallback). This is clearly distinct from the siblings (web_search, corroborate, kb, providers, reload_config), though the differentiation is implicit rather than explicit — the description never names an alternative. Clear purpose, but no stated sibling contrast.

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?

There is no when-to-use guidance whatsoever. The description says what the tool does but gives no context for choosing it over infobroker_web_search (which could arguably also retrieve content) or infobroker_corroborate. No exclusions, no alternatives, no mention of prerequisites. An agent gets zero decision support.

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