agentreader

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

No annotations exist, so the description carries the whole burden. It does disclose valuable behavior: the check set, that results include issues and a score, and an explicit price of $0.001 USDC (a real cost/auth constraint an agent must know before calling). It does not state read-only safety, rate limits, timeouts, or what the score means or its range.

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 case, then the check inventory, then the value proposition, then an example and price — a sensible ordering in a very short space. The telegraphic phrasing ('issues + score', 'Structured JSON beats shell dig/openssl') trades a little readability for density but wastes no sentences.

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 one-parameter, no-output-schema tool, the description covers what is checked, roughly what comes back (issues + score), the input format via example, and the cost. The remaining gap is the score's semantics and the response shape, which are minor given the tool's simplicity but would help an agent interpret results.

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 0% and the single property is an undescribed string, so the description must compensate — and it does with the example {domain:"stripe.com"}, which signals a bare hostname with no scheme or path. That is meaningful disambiguation the schema does not provide, though it stops short of stating whether subdomains or ports are accepted.

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 ('check domain health') and then enumerates the exact dimensions covered: DNS via DoH, DNSSEC, TLS/HTTPS, HSTS, MX/SPF/DMARC, plus an aggregate issues list and score. None of the siblings (company_research, read_url, extract_links) overlap with this scope, so an agent can route to it without ambiguity.

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?

Gives a concrete triggering context ('when vetting domain health before outreach') and positions itself against a non-MCP alternative (shell dig/openssl), which is useful framing. It does not name any sibling tool or state when-not to use it, so it stops short of full routing guidance.

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?

With no annotations, the description carries the full burden, and it does disclose the price ($0.65 USDC), the bundling rule, and the auto-attachment trigger ('.uk TLD or CH number detected') — useful non-obvious behavior. However, it never states what happens when no UK signal is present (implied by uk_included, but unstated), whether the charge still applies, or any rate/auth constraints, so the mutation-and-billing profile is only partially covered.

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 case, then the auto-attach rule, then a concrete input/output example — an efficient ordering. The price is stated twice ($0.65 vs $0.75, then $0.65 USDC), which is mild redundancy in an otherwise tight description.

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 one-parameter tool with no annotations and no output schema, the description covers purpose, cost, conditional behavior, and even the return shape ({company, uk, uk_included}). The main omission is what the response looks like when UK data is not included.

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 0% for the single 'domain' parameter, so the description must compensate. The example {domain:"tesco.com"} shows the expected value shape — a bare domain, not a URL — which is genuinely helpful, but it does not clarify edge cases such as subdomains, paths, or scheme prefixes.

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 both resources precisely: 'website company research' plus 'UK Companies House pack in one call', which tells an agent this is the combined bundle versus the separate company_research / uk_company siblings it alludes to via '$0.75 separate'. It stops short of naming those siblings explicitly, so an agent must infer which two tools this replaces.

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 this for website company research + UK Companies House pack' gives a clear selecting condition, and the price comparison against buying separately reinforces when this beats the alternatives. There is no explicit when-not guidance (e.g., use uk_company_lite if you already know the CH number), so the routing logic is only half-specified.

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?

With no annotations, the description carries the full burden and does well: it discloses provenance ('Sourced ... no LLM fiction'), enumerates collected data categories, and surfaces a per-call cost ($0.25 USDC), which matters for an agent deciding to invoke. It stops short of stating whether the charge applies on failure, latency expectations, or error behavior.

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 routing condition and the exclusion, then the data scope, then the example and cost — a sensible priority order. The dash-separated source list is dense but each item adds signal; only the fragmentary phrasing costs it a point.

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 one-parameter tool with no annotations and no output schema, the description covers what to pass, what comes back at a category level, what it costs, and when not to use it. A short note on output shape or failure/payment semantics would make it fully complete.

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 0% and the single 'domain' property is undocumented, so the description must compensate. The phrase 'from its website domain' plus the example {domain:"stripe.com"} conveys the expected bare-domain format (no scheme or path), which is the key ambiguity for this parameter.

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 ('researching a company from its website domain') and immediately scopes it away from the sibling 'uk_company' family by name, so an agent can discriminate without opening a 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?

Gives an explicit when-to-use clause, an explicit when-not ('not UK Companies House'), a named alternative ('Prefer uk_company* for UK filings'), and a concrete invocation example. Nothing is left to inference about routing.

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?

With no annotations, the description carries the full burden. It does disclose the material behavioral facts of cost ($0.03 USDC, implying a paid endpoint) and the return shape ({detected_format, markdown, pages, word_count}), but omits how payment/auth is established, size or page limits, failure behavior, and whether an unspecified format has a default.

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?

Three tight clauses — when-to-use, worked example, price — with the trigger front-loaded and no filler. Slightly more compact than a 5 would require only because the example and cost sit in separate fragments rather than integrated prose.

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 naming the four returned fields, which is the most important missing structure. For a two-parameter tool that is nearly sufficient, though defaults, limits, and error conditions remain uncovered.

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 0%, so the description must compensate for both parameters. The example ({url, format:"markdown"}) shows a valid format value and the 'public ... URL' phrasing adds a real constraint on url, but the default for format and any URL validation rules are left unstated.

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 ('converting a public PDF/DOCX/HTML/text URL to markdown or plain text') and enumerates exactly which input formats are supported, so the agent knows the operation precisely. It does not, however, distinguish this from the sibling read_url, which plausibly overlaps in fetching URL content, leaving the agent to infer the split.

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 a clear triggering context ('Use this when converting... for RAG/summaries') and implicitly excludes non-public URLs via the word 'public'. No alternative tool is named and no explicit when-not conditions are stated, so selection against read_url or extract_links still requires inference.

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?

With no annotations, the description carries the behavioral load and does a fair job: it discloses cadence (hourly), duration (30 days), that alerts go to a webhook, the return value (id), that polling GET /monitor/:id is free, and the cost ($1.00 USDC). It omits the payment/auth mechanism and what actually constitutes a detected change.

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 text is dense and front-loaded: use case first, then return value, then example, then price. Every clause carries information. The telegraphic notation ("selector?", "$1.00 USDC") is slightly cryptic but not wasteful.

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 4-parameter tool with no annotations and no output schema, the description covers lifecycle, cost, and return. Two gaps remain: how change detection is configured via keyword/selector, and what payment or authorization is required to invoke it. Fixing the parameter semantics would make it complete.

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 0% across 4 parameters, so the description must compensate and largely fails. The example mentions url, webhook, and an optional selector but assigns them no meaning, and the `keyword` parameter is never mentioned at all — leaving the crucial keyword-vs-selector distinction undocumented.

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 operation and scope: a 30-day, hourly web-change monitor with webhook alerts, plus example target page types. That distinguishes it from one-shot siblings like read_url or extract_links, though it never names them, so sibling differentiation is only implied.

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 this for 30 days of hourly web change monitoring" gives a clear trigger context, but there is no stated alternative (e.g. when to use read_url for a one-off check instead) and no guidance on when this is a poor fit. Usage is implied rather than spelled out.

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?

With no annotations, the description carries the full burden and does well: it discloses the price ($0.001 USDC), the relative cost/latency versus read_url, the de-duplication and absolute-link-only filtering behavior, and the return shape. It omits auth requirements, rate limits, and failure behavior, which keeps it from a 5.

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?

Three short, front-loaded fragments: selection condition first, then comparative cost, then concrete input→output example. Every clause carries information and nothing is padded.

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 one-parameter read tool with no output schema, the description supplies the return shape, the cost, and the alternative, which is nearly everything an agent needs to call it correctly. Only error/empty-result behavior and auth expectations are left unspecified.

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 0% and the single 'url' parameter has no description in the schema. The example implies it is the page URL to scrape, but the description adds no format, scheme, or edge-case guidance (redirects, relative-link base, non-HTML inputs) beyond that hint.

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 the resource and scope precisely: de-duplicated absolute links (crawl maps), and the inline example '{url} → {count, links:[{url,text,internal}]}' makes the input and output explicit. The verb 'extract' is only implied via the tool name, but an agent can tell this apart from read_url at a glance.

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 this when you only need de-duplicated absolute links' gives a clear positive selection condition, and 'Cheaper/faster than read_url' names the sibling alternative with a comparative rationale. It stops short of an explicit exclusion ('use read_url when you need page text'), but the routing is strongly implied.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that the tool is free and lists the information returned, but it does not cover authentication needs, rate limits, return format, or whether the data is static or live.

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 definition is a single efficient sentence with no wasted wording. The key cost attribute "Free" is front-loaded, followed by a compact list of returned content.

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 zero-parameter informational tool with no output schema, the description is largely complete because it enumerates the returned content. It could add a brief note about the response format or whether the data is current, but the core purpose is sufficiently covered.

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 tool takes zero parameters, so parameter semantics are not applicable and the baseline is 4. The description does not need to document inputs and appropriately focuses on what the tool provides.

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 purpose: listing AgentReader tools, prices, when-to-use hints, and payment details. This clearly identifies the resource and the information returned, though it does not explicitly differentiate from unrelated siblings like check_domain or read_url.

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 only usage hint is the leading word "Free," which suggests cost but does not explain when an agent should call this tool. There is no explicit guidance about alternatives, exclusions, or prerequisites.

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?

No annotations are supplied, so the description carries the full load, and it delivers the two facts an agent most needs: the response shape (title, author, date, language, word_count, markdown, links) and that the call costs $0.002 USDC on Base via x402. It does not cover failure modes, redirects, page-size limits, or rate limits — gaps that matter for a paid network 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?

Four tight sentences, front-loaded with the usage trigger, then the return fields, then the alternative comparison, then the example and price. No filler and nothing repeated from the schema.

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 one-param tool with no output schema, the description supplies the return fields, cost, and usage context that would otherwise be invisible. Remaining gaps are error/edge-case behavior and any rate or size constraints around the paid x402 call.

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 0% and the single param is only typed as a URI, so the description must compensate; it does so by specifying 'public URL' as a constraint and giving a concrete example ({url:"https://example.com"}). It stops short of saying what happens with non-public, authenticated, or malformed URLs.

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?

Names a specific verb and resource (fetch/convert a public URL into clean Markdown plus metadata) and explicitly contrasts with raw HTML output and with 'fetch'. An agent can tell immediately what it gets back: title, author, date, language, word_count, markdown, links.

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?

Gives a clear selection rule — use this when you want clean Markdown + metadata rather than raw HTML, and states it is better for RAG/summaries than fetch. Missing only explicit exclusions such as private URLs, paywalled pages, or when to prefer the sibling extract_links instead.

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?

With no annotations, the description carries the full burden and does well: it discloses the data source behavior ('official API with public fallback'), the red-flag logic applied (overdue, dissolved, officer churn, mass-formation office), and the price. It stops short of stating auth requirements, failure modes for ambiguous name matches, or result completeness, which keeps it from a 5.

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 purpose and scope, then the alternative and cost, then an example — a sensible ordering with little waste. The cost figures and example are tightly packed into the same sentence, which makes it denser than ideal but not padded.

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 two-parameter, no-output-schema tool it covers purpose, the content of the result, the cheaper alternative, and pricing. The only material gap is the input constraint ambiguity (no parameter required, no name-matching semantics) given there is no schema documentation to fall back on.

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 0% and neither parameter is marked required, so the description must clarify usage. It does convey that lookup accepts 'number or name' and gives a concrete example ({number:"00445790"}), but it never says whether one is required, whether both may be combined, or how partial name matching behaves.

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 ('full UK Companies House due diligence') and enumerates the returned sections (profile, officers, PSCs, filings, charges, insolvency, red flags), so an agent knows exactly what this produces. It also explicitly separates itself from the sibling uk_company_lite.

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?

Names the alternative (uk_company_lite) and the exact condition that selects it ('status/flags only'), with a concrete cost trade-off ($0.05 vs $0.50). Nothing about when to prefer which tool is left to inference.

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?

With no annotations, the description carries the full disclosure burden. It does add real value by disclosing the cost ($0.05 USDC) and the scope of the 'lite' response, but it says nothing about auth/permission needs, error behavior, or what happens when both parameters are omitted (required parameters = 0), which is a meaningful gap.

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?

Three short, front-loaded fragments plus a concrete example — very little waste. The telegraphic phrasing ('Upsell', 'red flags') is slightly informal but does not obscure the meaning.

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 two-parameter lookup with no output schema and no annotations, the description covers purpose, fields, cost, and the main alternative reasonably well. It falls short on how the two optional inputs interact and on any failure semantics.

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 0%, so the description must compensate. The included example {number:"00445790"} clarifies the format of 'number', but the 'name' parameter is never mentioned and no guidance is given on whether name and number are alternatives or can be combined.

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 the resource (a UK company) and enumerates the returned fields: status, SIC, office, compliance overdue, mass-formation check, red flags. It also explicitly distinguishes itself from the sibling 'uk_company', so an agent can choose between them without opening either 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?

It states the use case ('cheap UK company snapshot') and gives an explicit alternative with its own use case ('Upsell uk_company for officers/PSC/filings/charges/insolvency'). The other siblings (company_full, company_research) are not addressed, so routing among the full family is incomplete.

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