fetch_plain_text

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

No annotations were provided, placing the full disclosure burden on the description. While the cost disclosure ('Requires 0.005 USDC on Polygon') is a valuable and candid piece of behavioral context, it stands alone without details on payment flow (who pays, when), failure modes (insufficient balance), or network/dependency caveats. The description is far too sparse for a monetized tool carrying transaction risk.

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 compact at just 10 words, following a logical order of verb→object→qualifier→cost. Every word except 'ultra-lightweight' (which adds no measurable value) serves a purpose. This efficiency is a strong match for the tool's stated goal.

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?

Considering there is an output schema (return type is thus documented), a small parameter set, and a stated cost, the description could still do more. The tool introduces a non-trivial concept: a per-call cost on the Polygon network with a required payment transaction hash. The description does not explain the lifecycle: does the caller need prior approval? What happens if the payment hash is invalid or already used? This is core operational context that feels missing for a payment-gated tool.

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?

With 0% schema description coverage and no property descriptions in the JSON schema, the description needed to explain the parameters. The cost mention is helpful, implying why `payment_tx_hash` exists and why a URL alone is insufficient. However, the description does not specify expected format for the URL (http/https), what the payment hash represents (prior approved payment?), or how the client is expected to request/handle the 0.005 USDC fee, leaving meaningful gaps.

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 uses a clear verb+resource structure: 'Extracts ultra-lightweight pure plain text from any web page.' It effectively separates this tool from obvious siblings like fetch_youtube_transcript and fetch_pdf_markdown by specifying text-from-web output. However, it does not clearly distinguish from the similarly-scoped sibling 'fetch_clean_web_content', which could cause confusion about which to choose.

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 provided on when to use this tool over its close sibling 'fetch_clean_web_content'. The description fails to offer any exclusions, prerequisites, or situational triggers (e.g., 'use when you need raw text without HTML tags'). Users are left to guess whether this is for articles, dynamic pages, or simple sites.

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