ScrapeMole Reader

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

Annotations already declare readOnly/openWorld/idempotent, and the description goes well beyond them: it discloses the payment model (x402 USDC on Base, $0.002 per successful call) and the failure behavior when unpaid (a PaymentRequired object is returned). That is exactly the kind of cost/auth/error context structured fields cannot convey.

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 single lead sentence is front-loaded with the use case and then the input/output contract, and the payment caveat is a compact second sentence. It is a long, comma-chained construction, but every clause (input flexibility, ISO 8601 dates, ordering, cost) carries information an agent needs.

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?

There is no output schema, and the description compensates by enumerating the returned fields (title, link, publish date, author, summary, image, categories) and the ordering (newest first, as listed). Combined with the payment/error note and the schema's `limit` docs, an agent has enough to call this correctly.

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 100%, so both `url` and `limit` are already documented, including the auto-discovery behavior the description restates. The description adds no extra syntax, format, or edge-case detail for the parameters, so the baseline 3 applies.

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 names a specific verb+resource (read the latest posts/headlines as RSS/Atom feed items) and scopes it to a distinct domain: site, blog, newsroom, podcast, subreddit. That resource class is inherently separable from siblings like `read` (page to Markdown), `sitemap` (URL lists), `links` and `meta`, so an agent can route to it without opening any schema.

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?

"Use when you need the latest posts or headlines from a site, blog, newsroom, podcast or subreddit" gives an explicit trigger condition and even the accepted input variants (feed URL or plain site URL). It stops short of naming alternatives (e.g. use `read` for a single article body) or stating when-not to use it, so it lands below the 5 tier.

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

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

Beyond the readOnly/openWorld/idempotent annotations, it discloses meaningful behavior: it fetches the URL live, respects robots.txt, deduplicates and resolves links to absolute URLs, and reports specific link attributes and totals. It also surfaces the critical commercial behavior - paid via x402 USDC on Base at $0.002 per successful call, with the PaymentRequired object returned on an unpaid call.

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?

It is dense but well front-loaded, opening with the trigger and then the returned fields and pricing. Every clause carries information, though the single long sentence packing the return-field list is slightly heavy.

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?

With no output schema, the description fully carries the burden: it enumerates the returned link fields, internal/external totals, and the payment flow. An agent has everything needed to call it correctly and to anticipate the payment requirement.

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 100%, so the schema already documents url, type and limit. The description restates the type=internal|external filter but adds no syntax or default detail beyond the enum, so the baseline 3 applies.

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+resource ('extract links from a page') and scopes it to a single page's outgoing links, which implicitly separates it from site-wide siblings like sitemap. It does not name any sibling tool explicitly, so differentiation relies on inference rather than an explicit 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?

It gives an explicit 'Use when you need...' trigger plus concrete use cases (crawling, SEO audits, finding contact/pricing/docs pages, link building). It stops short of naming alternatives or stating when NOT to use it, leaving the agent to infer that site-wide needs belong to sitemap.

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

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

Annotations cover the safety profile (readOnly, idempotent, openWorld), and the description adds materially beyond them: live fetch semantics, redirect following, and a full payment model (x402 USDC on Base, $0.001 per successful call) including the fallback behavior of returning a PaymentRequired object when called unpaid. That is exactly the kind of non-obvious operational context an agent needs before invoking.

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?

Front-loaded with the usage trigger, then the returned fields, then the payment terms — a logical order with no filler. The return-field enumeration is long, but it is justified because there is no output schema; only minor tightening is possible.

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?

With no output schema and no annotations describing returns, the description compensates by enumerating the key returned fields (metadata, OG/Twitter tags, favicon, author, publish date, feeds, JSON-LD types) and by disclosing the payment flow. An agent has everything needed to call it and interpret the result.

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 coverage is 100% for the single 'url' parameter, so the schema already carries the semantics; the description adds no syntax or format detail for it. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb and resource ('fetches the URL live and returns title, description, site name, canonical URL, language, Open Graph and Twitter card tags...'), which goes well beyond a restatement of the name 'meta'. It does not explicitly name or contrast with the siblings (read, feed, links, sitemap), so the distinction from 'read' and 'feed' is left partly to inference.

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?

'Use when you need a link preview or page metadata' gives a clear selecting condition. It stops short of explicit when-not guidance or naming siblings — notably it returns RSS/Atom feeds while a 'feed' sibling exists, which could create ambiguity for an agent choosing between them.

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

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

Goes well beyond the readOnly/openWorld/idempotent annotations: discloses robots.txt compliance, the lack of JavaScript execution, a precise pricing model ($0.003 per successful call, x402 USDC on Base), and the fallback behavior of returning a PaymentRequired object when called unpaid. This is exactly the operational context an agent needs before invoking a paid, open-world scraper.

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?

Front-loaded with the usage trigger and then packed with high-value facts in two dense sentences – no filler. Slightly overloaded with stacked clauses (output fields, robots.txt, JS limits, pricing) in the second sentence, but each clause earns its place.

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?

With no output schema, the description compensates by naming the returned fields (Markdown body, title, byline, publish date, language, word count) and the output format choice. Combined with the payment and rendering constraints, an agent has everything needed to call it correctly.

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 100%, so all five parameters are already documented in the schema, and the description adds little beyond mentioning Markdown/plain text output ('format'). The links, images and maxChars options are not elaborated in the description text. Baseline 3 applies.

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?

States a specific verb and resource ('read one public web page') plus the exact transformation (live fetch → clean Markdown/plain text with boilerplate removed). The scope ('one public web page') clearly separates it from the sibling tools feed, links, meta and sitemap.

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?

'Use when you need to read one public web page' gives clear triggering context, and 'Server-rendered HTML only (no JavaScript execution)' is an explicit exclusion. It stops short of naming the sibling tools as alternatives for feeds, links or sitemaps, so routing is inferred rather than stated.

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

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

Annotations already cover read-only/idempotent/open-world, and the description adds substantial behavior beyond them: the sitemap discovery order (robots.txt Sitemap: lines, then /sitemap.xml, /sitemap_index.xml, /wp-sitemap.xml), gzip support, sitemap-index expansion semantics, and the paid-tool model (x402 USDC on Base, $0.002 per successful call, PaymentRequired object when unpaid). The cost and payment-failure behavior are exactly the kind of detail annotations cannot express.

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?

Front-loaded with the 'Use when' trigger, then flows through input, return values, index behavior, and pricing in a single dense paragraph with no filler sentences. It is long and somewhat run-on, but every clause carries operational information.

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?

There is no output schema, so the description carries the return-value burden and does so: it names the fields returned (page URLs with lastmod, changefreq, priority) and the sitemap-index case. Combined with the discovery order and payment model, an agent has everything needed to call and interpret this 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?

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it clarifies that 'url' accepts either a site URL (triggering discovery) or a direct sitemap URL, and explains what expand does for a sitemap index ('returns its child sitemaps and (expand=true, default) the URLs of the first child sitemaps up to the limit'). It goes beyond restating 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?

States a specific verb and resource: returns the list of pages a site publishes, in the form of sitemap URLs with lastmod/changefreq/priority. This is clearly distinguishable from siblings feed, links, meta, and read, which cover RSS, link extraction, metadata, and page content respectively.

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?

Opens with an explicit trigger: 'Use when you need the list of pages a site publishes (to crawl it, find recent posts, or audit SEO)', giving three concrete scenarios. It does not, however, name or contrast with the sibling tools (feed, links) that an agent might otherwise reach for.

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