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

The description goes far beyond annotations by disclosing DNS validation, redirect re-validation, deterministic truncation behavior, and a strong security posture: page content is untrusted evidence, embedded instructions must be ignored, and value-moving actions must never be triggered by external content. Nothing contradicts readOnlyHint:false or openWorldHint:true.

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 tool-specific content is front-loaded and useful, but the description is bloated by a duplicated SAP MCP execution guidance block that is also repeated in the schema description and does not help an agent select or invoke web_extract specifically. Several sentences repeat generic platform policy rather than tool-specific guidance.

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 fetch-and-extract tool, the description covers input constraints, return fields (provenance, authority, fetchedAt, content hash, citation-ready URL), network safety validation, and the relationship to web_search. With an output schema present, nothing necessary for correct invocation is missing.

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?

Although schema coverage is 100%, the urls item description is tautological ('Urls parameter for Web Extract'). The description adds real semantics: URLs must be public, at most three, and the output budget is deterministic with per-page and shared limits, which clarifies how charLimit and the overall call behave.

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 first sentence names a specific verb and resource ('Fetch up to three public URLs and return their readable text') and adds distinctive behavior: a deterministic head-and-tail budget, no model summarization, and provenance metadata. It also differentiates from sibling web_search by positioning itself as the follow-up when a snippet is insufficient.

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 explicitly says 'Use it after web_search when a snippet is not enough, or when the user provides a specific URL,' giving the agent clear trigger conditions. It also states hard exclusions (loopback, private, link-local, CGNAT, and cloud-metadata targets are refused), so when-not-to-use is also clear.

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