TidyTools Free Web Data

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

Annotations only declare readOnlyHint and openWorldHint, and the description layers on genuinely useful behavior beyond them: rate limits (1 per IP per UTC day, 20 shared ASN, 20 global), a monetization model (limited free result plus paid upgrade links), and auth context (x402 payment via Apify, no account needed). That is exactly the rate-limit/auth context the 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?

Tight, front-loaded sentences: purpose first, then exclusions, then the cost/limit facts. Every clause is functional — nothing is padding, and the payment details are unusual but decision-relevant.

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 usefully states what comes back ('a limited free result and paid upgrade links'). Combined with rate limits and payment model, an agent has enough to call it correctly, though return-shape specifics (e.g. how extracted fields are keyed) are left unstated.

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 50%: 'url' is documented in the schema, while 'fields' has no description though it does carry minItems/maxItems constraints. The description alludes to the 'fields' concept ('Extracts named fields') but does not explain the 1-5 limit or expected field-name format, so it only partially compensates for the coverage gap — baseline 3 is appropriate.

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+resource+mechanism ('Extracts named fields from one public page with AI'), which clearly differentiates it from generic fetch/read siblings like read_url or smart_fetch. It scopes the operation ('one url') but never names a concrete sibling alternative to help disambiguation, so it stops just short of a 5.

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?

Provides explicit exclusion guidance: 'Use for one url. Not for batch work or unrestricted monitoring,' which rules out the tempting misuse cases. It gives clear context but no named alternatives (e.g. which tool handles batch or article body extraction), so it is not a full 5.

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?

Adds substantial behavior beyond the readOnly/openWorld annotations: a free tier returning limited results, paid upgrade links, x402 payment without an Apify account, bearer-token billing in credits, and explicit free quotas (3 per IP per UTC day, 50 per shared pool, 100 globally). The agent knows exactly what it gets, how to authenticate, and what limits apply.

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?

Purpose is front-loaded in the first sentence, with auth and quota details after. Every sentence carries operational value, though the quota numbers are dense and could be tightened.

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, it covers what is returned (limited free result plus upgrade links), authentication, billing, and rate limits. Only the shape of the returned metadata remains unspecified, which is minor here.

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% and the single parameter already documents 'One app ID or store URL.' The description adds the Apple context but no extra syntax, accepted URL forms, or ID format guidance. Baseline 3 is appropriate.

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 ('Reads metadata for one Apple App Store app') and the Apple platform qualifier implicitly separates it from play_store_details. It doesn't name the sibling explicitly, so it stops just short of a 5.

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 clear scope and exclusions: 'Use for one app. Not for batch work or unrestricted monitoring.' That rules out misuse, though it doesn't point to app_store_review or another alternative for review/collection use cases.

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?

Adds real context beyond the readOnlyHint/openWorldHint annotations: that results are truncated without auth, that a Bearer tt_ token bills TidyTools credits, that x402/Apify payment works without an account, and exact free-tier quotas (3/IP/day, 50 per ASN pool, 100 global). This is precisely the kind of cost and limit disclosure annotations cannot carry. It stops short of describing what a 'limited free result' actually contains or how 'recent' is defined.

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, then cost/auth, then limits — a sensible order. The billing and x402 sentences are dense and slightly repetitive about paid access, but every sentence carries actionable information for the caller.

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 read-only, single-parameter tool with no output schema, the definition covers purpose, auth, pricing, and quotas well. The one real gap is what the returned review looks like and how much is withheld in the free tier — relevant since there is no output schema to lean 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?

One parameter at 100% schema coverage ('One app ID or store URL'), so the schema already does the work. The description reinforces singularity ('for one app') but adds no format, examples, or accepted URL shapes beyond the schema text.

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?

Opens with a specific verb and resource: 'Reads one recent Apple App Store review.' The 'one app' scoping distinguishes it in spirit from app_store_details/play_store_details, but no sibling is named explicitly, so an agent must infer the boundary.

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 explicit exclusions ('Not for batch work or unrestricted monitoring') and a scope constraint ('Use for one app'), which is well above average. It never names the obvious alternative (app_store_details) for agents who actually want metadata rather than a review, leaving that routing 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?

Annotations already cover read-only and open-world behavior; the description adds real context beyond them: the result includes a paid upgrade link, and payment for Apify Actor links can run through x402 with no Apify account required. Billing and upgrade behavior would otherwise be invisible to the agent, though return format and rate-limit details are omitted.

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 core purpose and the main exclusion are front-loaded, and each sentence carries distinct information. The closing x402/Apify payment sentence is useful but slightly tangential to the tool's function.

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 a single simple parameter, the description still conveys the shape of the return (allowed and blocked bots plus an upgrade link) and sets the scope limit (declared policy, not enforcement). That is nearly complete for a one-parameter read-only lookup; only pagination or edge-case behavior for missing robots.txt is unaddressed.

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?

Only one parameter exists and schema coverage is 100%, so the baseline would be a 3; the description adds a little by framing the URL as a public website (or domain) whose declared policy is inspected, implying external accessibility is expected.

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 a site's robots.txt verdict for AI crawlers, listing allowed and blocked bots. It also scopes the input to one public website, which separates it from broader siblings like seo_audit or seo_browser_audit.

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 use case (inspect one public website's declared crawler policy) and two explicit exclusions (proving a CDN/firewall actually permits a bot, ongoing monitoring). It stops short of naming an alternative tool for the network-level question, so it is strong but not a full when/when-not/alternative mapping.

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 readOnlyHint/openWorldHint annotations: it discloses that results are a limited free tier with paid upgrade links, that payment runs through x402 via Apify without an account, and gives concrete quota mechanics (1 per IP per UTC day, shared caller/ASN pool of 20, 20 globally per day). For a metered AI tool, these are exactly the operational facts an agent cannot get from structured fields.

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?

Purpose and the 'one text' constraint are front-loaded, followed by return/payment behavior and quotas. All sentences carry information, though the quota clauses are dense and packed into a single run-on final sentence that could be structured more scannably.

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 still sketches the return shape ('limited free result and paid upgrade links'), and it covers cost/auth/quota behavior for a two-parameter open-world tool. The only gap is the exact structure of the free result, which an agent might want before parsing a response.

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 50% — 'text' is documented but 'question' has only a maxLength and no description. The description compensates by establishing that 'question' is a single yes/no question (not an open-ended prompt) and that 'text' is one fragment, adding real semantic constraints the schema lacks.

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+resource: 'Answers one yes/no question about supplied text using AI.' That is clearly distinct from sibling text tools like ai_extract, embed_text, summarize_article, and translate_text, which operate differently on text. The scope word 'one' further separates it from batch extraction tools.

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?

Explicitly states both the intended case ('Use for one text') and exclusions ('Not for batch work or unrestricted monitoring'), which is more than most definitions provide. It stops short of naming the specific alternative sibling an agent should call for batch work, leaving that inference to the caller.

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?

Adds substantial behavior beyond the readOnly/openWorld annotations: free-tier quotas (3 per IP per UTC day, shared pool 50, 100 global), paid upgrade links, x402 payment via Apify, and Bearer token billing with TidyTools credits. It does not describe the structure or fields of the returned company facts, so a small gap remains.

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-loads the core purpose, then covers scope, payment, auth, and rate limits in compact sentences. The payment and quota details are dense but relevant; nothing is clearly redundant, though the billing explanation could be tightened.

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-only tool with no output schema, the description covers scope, auth, billing, and free-tier limits adequately. It could be more complete by indicating what 'public company facts' includes or what a limited free result omits, but no critical calling information 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?

Only one parameter exists and the schema already documents it at 100% coverage as 'One public HTTP(S) URL.' The description reinforces the single-URL constraint but adds no format or validation detail beyond the schema, so 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: returns public company facts from one website. The single-URL scope clearly separates it from batch-style siblings, but it does not explicitly distinguish itself from the sibling 'company_enrich_ai', leaving the agent to infer the difference.

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?

Explicitly says 'Use for one url' and excludes 'batch work or unrestricted monitoring', giving clear when/when-not guidance. It stops short of naming the preferred alternative for batch or AI-specific enrichment, so it is not a full 5.

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 only declare readOnlyHint and openWorldHint, so the description carries real weight here and delivers: it discloses the tiered result model (limited free result plus paid upgrade links), the auth mechanism (Authorization: Bearer tt_…, billed in TidyTools credits), and concrete rate limits (1/IP/UTC day, 20 shared pool, 20 global). None of that is recoverable from the annotations or the one-param schema.

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?

Purpose is front-loaded in sentence one, with constraints and pricing following. The telegraphic fragments ('Use for one url.', 'no Apify account needed.') keep it scannable, though the x402/Apify payment sentence is a tangent that dilutes the core routing signal.

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 single-parameter, no-output-schema tool, the definition covers input scope, cost model, auth, and rate limits — enough to call it correctly. What is missing is any hint of which company facts come back, so an agent cannot judge whether the free result is sufficient for its task.

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% and the single 'url' parameter is documented as 'One public HTTP(S) URL.' The description reinforces singularity ('Use for one url'), which guards against array-style misuse, but adds no format or validation detail beyond the schema. 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 opening sentence names a specific verb and resource: AI-driven enrichment of public company facts from a single website. It scopes the input ('one website', 'Use for one url'), which separates it from batch-style siblings. It does not, however, distinguish itself from the sibling 'company_enrich' that presumably does a non-AI variant, so an agent must infer that difference.

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?

Explicit positive and negative guidance: 'Use for one url. Not for batch work or unrestricted monitoring.' This tells the agent when the tool is wrong, which is rarer than it should be. The gap is that it never points to the obvious alternative (company_enrich) for the non-AI or the batch case.

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 readOnlyHint/openWorldHint annotations: it discloses the free/paid result split, the x402 payment path via Apify with no account required, bearer-token auth billed in TidyTools credits, and concrete rate limits (1 per IP per UTC day, 20 AI pool, 20 global). This is exactly the cost/auth/throttling context the annotations cannot carry.

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-loads purpose, then payments, then scope exclusions, then limits – a sensible order with no filler. It is dense and slightly run-on (pricing/auth/rate-limit clauses stacked in consecutive sentences), but every sentence 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?

With no output schema, the description tells the agent what to expect back (limited free result plus paid upgrade links), how to unlock full results, what auth is needed, and what the quotas are. For a one-parameter, quota-limited tool this leaves nothing important unstated.

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% and the single parameter is already documented as 'One public HTTP(S) URL.' The description reinforces the one-URL constraint and adds that it must be a 'public image', which is a modest but genuine addition; baseline 3 applies 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: 'Compresses one public image', plus the scope ('one public image', 'one url'). It does not explicitly distinguish itself from nearby siblings like resize_image, convert_image or upscale_image, so the agent must infer the difference from names alone.

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?

Explicit exclusions are given: 'Use for one url. Not for batch work or unrestricted monitoring.' That tells the agent when not to call it, though it does not name the sibling alternative (e.g. resize_image) that a batch or resize need should route to.

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?

The description adds substantial behavior beyond the annotations: it explains the return shape (limited free result plus paid upgrade links), payment via x402 through Apify without an account, and detailed rate limits by IP, shared AI caller/ASN pool, and global daily cap. These details are highly relevant for invoking the tool correctly and understanding access constraints.

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 compact and front-loads the core purpose. Every sentence is relevant, though the ordering mixes return/payment information before usage boundaries, making the structure slightly less crisp than it could be.

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 simple one-parameter conversion tool, the description covers purpose, usage limits, return expectations, payment requirements, and rate limits. It does not fully specify the exact return structure, but no output schema exists and the implied Markdown result is clear enough.

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?

There is only one parameter, and the schema already describes it at 100% coverage as 'One text or HTML fragment.' The description reinforces the single-fragment constraint with 'one supplied HTML fragment' and 'Use for one text,' but adds little syntax or formatting guidance 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 gives a specific verb and resource: converts one supplied HTML fragment to Markdown. It also scopes the tool to a single text, which helps distinguish it from batch or monitoring tools, but it does not name or directly contrast with sibling alternatives such as extract_article 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?

It clearly states when to use the tool ('Use for one text') and when not to use it ('Not for batch work or unrestricted monitoring'). It lacks explicit routing to alternative sibling tools, so it falls short of full alternative 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?

The description adds substantial behavior beyond the readOnly/openWorld annotations: limited free results, paid upgrade links, x402 billing via Apify, Bearer-token auth, and per-IP/per-caller/per-day free limits. It still does not clarify the actual output format of the converted image, but the auth and rate-limit disclosure is strong.

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 front-loaded with purpose before pricing/auth/rate-limit details. It is somewhat dense, but each sentence carries operational information rather than filler.

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-only tool, the definition covers purpose, auth, billing, and limits. However, it leaves an important gap: with no output schema and no target-format parameter, the description does not explain what conversion result the caller receives.

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 single `url` parameter is fully described in the schema as 'One public HTTP(S) URL,' and the description only repeats the single-URL restriction. No additional parameter semantics, such as target image format, are provided.

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: 'Converts one public image format.' It also clarifies single-URL scope. However, it does not distinguish this format-conversion operation from sibling image tools such as resize_image, compress_image, or upscale_image, and it does not state the target format.

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 some scope guidance ('Use for one url', 'Not for batch work or unrestricted monitoring'), but it does not say when an agent should choose this over other image-processing siblings. The usage context is implied rather than fully differentiated.

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 readOnlyHint/openWorldHint annotations, the description discloses the return shape ('limited free result and paid upgrade links'), the payment path (x402 via Apify, no account needed), and concrete quotas (1 per IP per UTC day, 20 shared pool, 20 global). This is unusually rich behavioral context for a single-param tool.

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?

Purpose is front-loaded and every sentence carries information, but the text is telegraphic and slightly redundant ('one public image URL' followed by 'Use for one url'), and the payment/quota sentences are dense fragments rather than flowing 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?

For a one-parameter tool with no output schema, the description supplies what is needed: the return nature, payment model, and rate limits. It could be slightly clearer on the exact return payload, but nothing critical 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?

Schema description coverage is 100%, and the description's only parameter detail ('one public image URL') merely restates the schema's 'One public HTTP(S) URL.' With the schema doing the heavy lifting, the baseline of 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 and resource: 'Writes alt text for one public image URL with AI.' This cleanly separates it from image siblings like ocr_image (text extraction) and resize_image/compress_image (transformation), so an agent can select it without opening the 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 gives explicit scope ('Use for one url') and exclusions ('Not for batch work or unrestricted monitoring'), which is clear when-to-use/when-not guidance. It stops short of naming a specific alternative tool for batch scenarios, so it is not a full 5.

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 annotations: it discloses that unauthenticated calls return a truncated free result plus upgrade links, that 'Authorization: Bearer tt_…' unlocks billed full results, and that x402/Apify payment is possible without an account. It also quantifies rate limits (3 per IP per UTC day, 50 for the shared AI caller/ASN pool, 300 global per day). This is exactly the operational context annotations cannot carry.

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-loads the return payload, then moves through payment, auth, scope, and quotas. Dense and telegraphic rather than padded, though the auth/payment/quota clauses stack up and read as a run-on that could be tightened.

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 carries the burden of describing returns, and it does ('technologies and evidence', plus the free-result/upgrade-link behavior). Combined with the quota and auth disclosure, an agent has enough to call it correctly and to anticipate degraded results without a token.

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% and the single parameter is already documented as 'One public HTTP(S) URL.' The description still adds value by emphasizing 'Use for one url,' reinforcing that the input is singular and not a list. Little else is needed for a one-parameter tool.

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?

Opens with a specific verb+resource: 'Returns detected website technologies and evidence.' It also scopes the tool to a single URL, which separates it from any bulk/audit sibling. No sibling is named as the alternative for cases it declines, which keeps it just short of a 5.

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?

Explicitly states the positive case ('Use for one url') and the exclusions ('Not for batch work or unrestricted monitoring'). That is real routing guidance. It doesn't point an agent toward a specific sibling for the batch case, so it stops at 4.

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 readOnlyHint/openWorldHint annotations by disclosing the auth mechanism (Authorization: Bearer tt_…), billing model (TidyTools credits), x402 payment path with no Apify account, and concrete free-tier rate limits. This is exactly the operational context an agent needs before calling.

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?

Purpose is front-loaded and each sentence conveys actionable information about payment, auth, or limits. The x402/Apify sentence is slightly dense but still earns its place for callers who need paid access.

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 signals the return shape (limited free result plus paid upgrade links) and covers auth and rate limits thoroughly. It doesn't detail what authority metrics are actually returned, a minor gap for this complexity level.

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% and both domain and url are documented with their alias relationship, so the schema carries the load. The description only reinforces 'one domain' without adding format or validation detail beyond the schema, matching the baseline 3.

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: 'Looks up open-data authority for one domain', which is distinct from sibling tools like domain_whois or traffic_rank. It doesn't explicitly name which sibling to use instead for related lookups, so the differentiation is partial.

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?

Explicitly scopes usage to one domain and excludes batch work and unrestricted monitoring, which is clear when-not guidance. It stops short of naming alternatives (e.g., domain_overview) for those excluded cases.

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 only say readOnly/openWorld; the description adds the behavioral layer that actually matters here: partial free results plus upsell links, Apify x402 payment path, Bearer tt_ token for full billed results, and three concrete rate-limit tiers (3/IP/UTC day, shared ASN pool 50, 300 global).

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, then usage exclusions, then pricing/auth, then quotas — a sensible priority order in short declarative sentences. Slightly dense in staccato fragments, and the x402 sentence is tangential to invocation decisions.

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-param read tool with no output schema, the description covers auth, cost, partial-result behavior, and quotas, which an agent needs before calling. It doesn't say which record types (A, MX, TXT) come back, leaving the return shape opaque, but nothing critical to 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?

Schema coverage is 100% and the schema already documents the domain/url alias and the anyOf requirement. The description adds only the 'one domain' constraint, which the schema property text already conveys.

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?

Opens with a specific verb+resource: 'Returns DNS records for one domain.' The scope limitation ('one domain', 'not for batch work') cleanly separates it from neighboring domain_* tools that cover WHOIS, authority, or traffic data.

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?

Explicitly states when to use ('Use for one domain') and when not to ('Not for batch work or unrestricted monitoring'), but never names a sibling as the alternative for batch lookups, so the agent must infer the 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?

Annotations only cover readOnlyHint and openWorldHint; the description adds substantial context beyond them: partial free results with paid upgrade links, the x402/Apify payment path with no account required, Bearer tt_ auth for credited full results, and exact per-IP/ASN/global daily quota numbers. This is exactly the operational detail an agent needs before calling.

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?

Purpose is front-loaded, then payment model, then limits — a sensible order. "Use for one domain" mildly restates the opening sentence and the rate-limit sentence is dense, but no sentence is truly wasted.

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 read-only, two-parameter tool with no output schema, the agent knows cost, auth, limits, and that results are partial unless credited. The remaining gap is that it never says which signals the overview contains, leaving the return content blurry.

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% and the schema already documents url as an alias for domain and the one-of requirement. The description adds no further semantics about format or normalization beyond what the schema states, so 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 — combines open-data signals for one domain — so an agent knows it is an aggregation tool. However, it never names which signals (authority, whois, traffic, referring domains) or distinguishes itself from the many domain_* siblings, so the agent cannot tell from the description alone what data it covers.

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 for one domain. Not for batch work or unrestricted monitoring" gives explicit scope and exclusions. It stops short of naming a concrete alternative for batch use, but the when-not guidance is unambiguous.

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 and openWorld annotations, the description discloses important behavior: limited free results, paid upgrade links, Authorization Bearer usage for full paid results, and detailed daily/IP/ASN quotas. This is unusually complete behavioral context for an agent.

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 front-loaded with purpose and then covers payment, auth, scope, and rate limits in a compact sequence. Some payment details are slightly dense and the repeated 'Returns... Returns...' phrasing could be tightened, but there is little wasted space.

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 read-only lookup tool with no output schema, it covers scope, access/auth, free-vs-paid behavior, and quotas well. It does not enumerate the registration fields returned, but RDAP registration details is a reasonably clear output expectation.

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 input schema already documents both domain and url with 100% description coverage. The description reinforces single-domain usage but does not add parameter-level meaning beyond the schema, so the baseline of 3 is appropriate.

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: returns public RDAP registration details for one domain. It also makes the single-domain scope explicit, but it does not explicitly differentiate this tool from close siblings such as domain_overview or domain_dns.

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 clear usage context: use for one domain, not for batch work or unrestricted monitoring. It does not name an alternative sibling tool for those excluded cases, so it falls short of full when-to-use/when-not/alternatives 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?

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds important behavioral context: limited free results, paid upgrade links, x402 payment via Apify, no Apify account needed, and concrete free-tier limits per IP/ASN/global day.

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 front-loaded with the core return value, then usage exclusions and quota details. It is compact and mostly wastes no space, though the free-limit wording is dense and slightly ambiguous.

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 simple one-parameter embedding tool with no output schema, the description covers purpose, scope, payment behavior, and rate limits. It does not specify vector dimensions or exact return shape, but the core invocation requirements are adequately 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?

Schema description coverage is 100% for the single parameter, and the schema already says it accepts "One text or HTML fragment." The description reinforces single-text usage but does not add parameter semantics 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: it returns one text embedding vector. It also explicitly scopes the tool to a single text and rules out batch work, making it distinguishable from sibling text-processing tools.

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 clear usage guidance: "Use for one text" and "Not for batch work or unrestricted monitoring." It does not name a specific sibling alternative for batch work, but the exclusions are explicit and actionable.

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 only declare readOnlyHint and openWorldHint; the description adds the auth requirement (Bearer tt_…), billing model (credits vs. x402), free-tier rate limits, and the fact that the free result is limited with paid upgrade links. That is substantive behavioral context, though the x402/Apify pricing paragraph is more commercial than operational.

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?

Purpose and scope are front-loaded, but the middle is cluttered with billing mechanics (x402 via Apify, TidyTools credits) that don't help an agent decide or invoke, plus a dense rate-limit line. Some of it earns its place; the payment-channel detail does not.

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 one parameter, no output schema, and flat structure, the definition covers what the agent needs: scope, auth, rate limits, and a rough statement of what comes back (limited free result plus upgrade links). Only the exact shape of the enriched payload is left implicit, which is acceptable given no output schema exists.

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% and there is a single required parameter whose schema already gives the format ('One city with country code, e.g. Berlin, DE'). The description only restates 'one location', adding no syntax or format detail beyond the schema, so 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?

Names a specific verb ('Enriches') and resource ('one business listing in a city'), and immediately bounds the scope to a single location. The line 'Not for batch work or unrestricted monitoring' separates it from batch/enrichment siblings 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?

'Use for one location. Not for batch work or unrestricted monitoring' gives explicit when-to-use and when-not-to-use conditions. It stops short of naming a concrete alternative sibling (e.g. a batch enricher), so it is clear context rather than 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?

Annotations only say readOnly/openWorld; the description adds a lot beyond that: a truncated free-tier result with paid upgrade links, two payment paths (x402 via Apify with no account, or Bearer tt_… billed in TidyTools credits), and concrete quota numbers (3/IP/UTC day, 50 shared ASN pool, 100 global). These are the operational facts an agent needs before calling a rate-limited, paid-tier tool.

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 core purpose and the one-URL constraint lead, with pricing and quota detail compressed into dense trailing clauses. It is information-rich rather than padded, though the payment/billing sentences are terse enough to feel like a wall of fragments rather than 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?

With no output schema, the description does carry the burden of describing returns — it says main text plus metadata and warns that free results are partial and upgrade links are included. Auth and quota are fully covered; what those "metadata" fields actually are remains unspecified, a minor residual gap.

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% and there is only one parameter, so the schema already documents the single `url` field. The description adds only the implicit "one URL, not many" framing, which barely extends beyond "One public HTTP(S) URL." 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 ("Extracts one article's main text and metadata") and pins the scope to a single URL. It differentiates itself from batch/monitoring use but never names the closest siblings (summarize_article, read_url, smart_fetch), so an agent must still infer which extraction-flavored tool it wants.

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 for one url. Not for batch work or unrestricted monitoring" gives both the positive case and an explicit exclusion. It stops short of naming an alternative tool to use instead when batch or summarization is the goal, which is what a 5 would require.

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?

The description adds substantial behavioral detail beyond annotations: limited free result plus paid upgrade links, two payment paths (x402 via Apify and Bearer token for TidyTools credits), and precise free-tier rate limits (3/IP/day, 50 shared pool, 100 global). These are exactly the operational constraints an agent needs to avoid failed or over-limit calls.

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 front-loaded with the core purpose and return behavior, then layers in payment/auth details, scope boundaries, and rate limits. Every sentence carries operational value, though the payment-method sentence is dense and could be slightly tighter.

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?

Given one simple parameter, an output schema absence, and read-only/open-world annotations, the description covers the important gaps: what is returned (limited free result + paid links), auth requirements, and rate limits. It could be more specific about what 'contact details' includes (emails, phones, social profiles), but it is otherwise 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 100% for the single 'url' parameter, so the schema already defines it as 'One public HTTP(S) URL.' The description repeats the single-URL constraint ('one website', 'Use for one url') but adds no new format or semantic detail beyond what the schema provides. Baseline 3 is appropriate.

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 clearly states a specific verb and resource: 'Finds public contact details on one website.' It also bounds the scope to a single URL. It does not explicitly distinguish itself from sibling tools like ai_extract or company_enrich, but the one-URL constraint provides some differentiation.

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 explicit usage context: 'Use for one url. Not for batch work or unrestricted monitoring.' This tells the agent when not to use it. Alternatives are not named, but the exclusion is clear enough for an agent to route correctly.

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 readOnlyHint and openWorldHint annotations, the description discloses important behavior: limited free results, paid upgrade links, paid access via x402/Apify without an account, Bearer token billing with TidyTools credits, and specific rate limits. These details materially affect when and how an agent should invoke the tool.

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 front-loaded with the core purpose and then adds constraints, payment, auth, and rate limits in a compact form. It is dense but nearly every sentence carries operational value; the payment-path sentence is useful though slightly cluttered.

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-only, open-world tool with no output schema, the description covers purpose, scope, exclusions, auth, billing, and rate limits. An agent has enough information to decide whether to call it and how 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?

The schema already documents the single required parameter 'url' at 100% coverage, including that it must be a public HTTP(S) URL. The description reinforces the one-URL scope but adds little syntax or format detail beyond the schema, so the baseline of 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 and resource: 'Finds one public job posting from a company's jobs board.' It also scopes the tool to a single URL and explicitly excludes batch work and unrestricted monitoring, making it distinguishable from generic URL-fetching siblings.

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 gives clear usage constraints: 'Use for one url. Not for batch work or unrestricted monitoring.' It also states free-tier limits and the Authorization header needed for full results. It does not name a specific alternative sibling for batch work, which keeps it from a 5.

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 read-only and open-world annotations, the description discloses important operational behavior: free-result limitations, paid upgrade links, x402 payment handling, Authorization bearer requirements, credit billing, and detailed daily rate limits by IP, shared pool, and global cap.

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 purpose is front-loaded in the first sentence, and the remaining sentences cover usage, billing, authentication, and rate limits without excessive waste. The structure is slightly dense and mixes several operational details, but it remains appropriately sized.

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-only tool with full schema coverage and annotations covering safety, the description supplies the missing practical context: usage boundaries, authentication, billing behavior, and rate limits. No output schema exists, and the description adequately indicates that results may be limited unless upgraded.

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%, and the single parameter is already well documented in the schema with format guidance. The description reinforces the one-location constraint but does not add syntax or format detail beyond what the schema 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 clearly states a specific verb and resource: it returns one business listing in a city. It also scopes the tool to a single location and explicitly excludes batch work, though it does not name a particular sibling tool as the alternative.

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 clear usage context ('Use for one location') and exclusions ('Not for batch work or unrestricted monitoring'). It does not explicitly route the agent to a named alternative sibling tool, so it falls short of the top score.

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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: what the results contain (advertised prices, counted paid-product links) and the freshness limitation (catalog publication dates, not live availability). That staleness caveat is exactly the kind of context 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?

Three sentences, each doing distinct work: what it returns, when to use it, when not to. The return/output characterization is front-loaded and there is no filler.

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 correctly takes on the burden of describing the return payload (prices, counted paid-product links) and its staleness limits. For a single-parameter read tool with annotations covering the safety profile, nothing needed to call it correctly 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?

Schema coverage is 100% for the single 'query' parameter, so the schema carries the semantics and baseline 3 applies. The description implies keyword-style task search but adds no syntax, formatting, or matching-behavior detail 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?

States a specific verb+resource: 'Returns matching tools from the current TidyTools catalog', and immediately qualifies the scope with what it returns (advertised prices, counted paid-product links). It also distinguishes itself from siblings by excluding web-content fetching and live availability checks.

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 condition ('when you know a web-data task but not which TidyTools tool fits') and explicit when-not conditions ('not for fetching web content or checking live product availability'), which map onto the sibling tools read_url and check_ai_crawler_access.

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 only readOnly/openWorld, so the description carries real weight and delivers: it discloses a free/paid split, x402 payment via Apify needing no account, and concrete quotas (3/IP/day, 50 shared pool, 100 global/day). These are operational constraints an agent cannot get from any structured field.

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 dense but front-loads the core action first, then payment, usage, and quotas. Every sentence carries information, though the quota sentence packs three separate limits into one clause, slightly hurting scanability.

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 single-parameter, read-only, no-output-schema tool, the description covers purpose, scope, payment mechanics, and rate limits, which is enough to invoke it correctly. The return value is only gestured at ('limited free result'), leaving the caller guessing what the response actually contains.

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?

Only one parameter and schema coverage is 100%, so the schema already documents the url field fully. The description reiterates 'one public HTTP(S) URL' through the 'use for one url' line but adds no format, scheme, or validation detail beyond the schema. 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: 'Checks one URL's HTTP status and redirects.' It is clearly distinguishable from fetch-style siblings because it declares it is for a single URL and explicitly not for batch work. It does not, however, name the sibling to use instead for batch or monitoring.

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 explicit scope ('Use for one url') and explicit exclusions ('Not for batch work or unrestricted monitoring'), which is stronger than most. It falls short of naming an alternative tool for those excluded cases, so an agent must infer the 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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that free results are truncated, that upgrades are paid via x402 with no Apify account, that a Bearer tt_ token yields full billed results, and quotes exact rate limits (3/IP/UTC day, shared ASN pool 50, 100 global). This is precisely the operational context an agent cannot get from structured fields.

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?

Purpose is front-loaded in the first sentence, and every following sentence adds operational value (result limits, auth, quotas). The payment/auth/quota clauses run together somewhat, but no sentence is wasted.

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 still tells the agent what comes back (a limited free result plus paid upgrade links) and what unlocks full results. The only soft spot is that it never specifies what 'jobs platform' detection actually returns (e.g. ATS vendor name), but auth, cost, and quota are all 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?

Schema coverage is 100% for the single url parameter, and the description's 'Use for one url' only restates the single-URL constraint already encoded in the schema ('One public HTTP(S) URL', additionalProperties false). Baseline 3 for full schema coverage with no added format or validation detail.

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 opening sentence gives a specific verb and resource: detect a site's public jobs platform. It is clear enough for an agent to distinguish it from generic fetch/HTML tools, though it doesn't name a sibling (e.g. find_one_job) that might be the closer alternative.

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?

Explicitly scopes usage: 'Use for one url. Not for batch work or unrestricted monitoring,' which is a real when-not statement. It stops short of naming which sibling to use for the batch case, but the boundary is stated plainly.

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 annotations, the description discloses authentication requirements, free quota limits per IP and globally, shared ASN pool limits, paid upgrade behavior, and x402 billing options. These are substantial operational details an agent needs before calling the tool.

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 front-loads what the tool returns, then covers billing, auth, scope, and quotas. It is reasonably compact, though the ordering jumps between output, paid access, auth, usage scope, and rate limits.

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 single-parameter read-only tool with no output schema, the description covers return content, scope, auth, quotas, and paid access options. Nothing essential for correct invocation appears to be 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?

Schema coverage is 100% for the single url parameter, which already documents that it accepts one public HTTP(S) URL. The description reinforces the single-URL constraint but adds little parameter-level detail beyond the schema, so baseline 3 is appropriate.

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 resource and return values: title, Open Graph tags and page metadata for one URL. It distinguishes scope from batch/monitoring work, though it does not name sibling alternatives such as read_url or extract_article.

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 explicitly says to use for one URL and not for batch work or unrestricted monitoring, giving clear when-to-use and when-not-to-use guidance. It does not name alternative tools for batch or monitoring use cases.

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 only mark this read-only and open-world; the description adds the operational facts those annotations cannot: the free tier is limited, paid upgrades exist, an Authorization Bearer header is required for full results, and the quota is enforced per IP per UTC day (1 free, 20 for shared ASN pools, 20 globally). Auth, cost and rate limits are exactly the behavioural details an agent needs before calling.

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 action and scope, then the limits and billing. Every sentence carries information, though the x402/Apify billing clause is dense and slightly interrupts the sequence of functional constraints.

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?

A one-parameter tool with no output schema; the description covers input limits, auth requirements, quota behaviour and what is returned ('a limited free result and paid upgrade links'). Nothing material is missing for a correct invocation.

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 a single parameter at 100% schema coverage, the schema already defines the url field, so the baseline is 3. The description reinforces the 'one public image URL' constraint and the size/singularity limit, which slightly improves on the schema's own wording without adding format or syntax detail.

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: 'Reads text from one public image URL with AI.' That is unambiguously OCR, which separates it from the neighbouring image tools such as upscale_image, resize_image and remove_image_background. The scope word 'one' is stated up front rather than left implicit.

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 for one url. Not for batch work or unrestricted monitoring' gives the positive case and the explicit exclusions in consecutive sentences. No sibling alternative is named, but the boundary conditions are stated directly enough that an agent knows when not to call this.

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 annotations: discloses the free-tier result plus paid upgrade links, x402/Apify payment path, Bearer token auth for full results, and concrete rate limits (1/IP/UTC day, ASN pool 20, 50 global/day). This is exactly the operational context an agent needs before calling.

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?

Purpose is front-loaded in the first sentence and every clause carries operative information. The payment/auth details are dense and slightly crowded into the middle, but nothing is wasted.

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?

No output schema exists, and the description compensates by describing what comes back (limited free result plus paid upgrade links) along with auth and quota behavior. For a one-param read tool, nothing needed to call it correctly 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?

Schema coverage is 100% and the single 'url' param is documented as 'One public HTTP(S) URL'. The description reinforces the single-public-URL constraint, adding marginal value over the schema rather than syntax detail.

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 ('Renders one public page as a PDF') with clear single-URL scope. It doesn't explicitly distinguish itself from a likely sibling like screenshot_url, so differentiation is only implied via the batch/monitoring exclusion.

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 explicit positive guidance ('Use for one url') and exclusions ('Not for batch work or unrestricted monitoring'). No alternative sibling is named for batch/monitoring needs, so the routing is incomplete.

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 annotations: it discloses that the free tier returns a limited result, that full results require an Authorization: Bearer tt_… header billed in credits, and the exact rate limits (3/IP/day, 50 shared AI caller pool, 100 global). That auth and quota detail is exactly the context an agent needs before calling.

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?

Short, front-loaded sentences with the core action first and constraints after. The billing/quota sentences are dense and lean toward commercial messaging, but each still carries decision-relevant information for the caller.

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 everything material: what is returned (limited free result plus paid upgrade links), how to authenticate for full results, and the quota envelope. Nothing an agent needs in order to call it correctly 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?

There is one parameter at 100% schema description coverage ('One app ID or store URL'), so the schema already carries the semantics. The description only repeats the singular-app constraint rather than adding accepted URL/ID formats, so 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 ('Reads metadata for one Google Play app') and pins the scope to a single app. The Google Play qualifier naturally separates it from the iOS sibling app_store_details, and 'Not for batch work' rules out the review/bulk siblings.

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 positive case ('Use for one app') and explicit exclusions ('Not for batch work or unrestricted monitoring'), plus the free-quota thresholds that govern when it is usable. It stops short of naming which sibling to use for batch or review work, so the routing is only partially complete.

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 annotations: discloses auth scheme (Bearer tt_…), credit billing, that unauthenticated calls return a truncated result plus upgrade links, and concrete free-tier quotas per IP/ASN/global. The Apify/x402 sentence is confusing and sits awkwardly without explaining how it relates to this tool's call path.

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?

Purpose and exclusions are front-loaded, but the middle is cluttered with pricing/monetization detail (Apify Actor, x402) that reads like marketing copy and competes with the operational facts 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?

No output schema exists, and the description does sketch what comes back (limited free result plus paid upgrade links), plus the auth and quota model needed to decide whether a call will be useful. The unresolved "by region" claim is the main completeness gap.

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% and the schema already says "One public HTTP(S) URL." The description repeats "one url" and "public" but adds no new constraints, formats, or examples, so 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?

First sentence gives a specific verb and resource ("Checks one public product price") and adds a scope qualifier. The "by region" claim is misleading though, since the only parameter is a URL and no region input exists, and no sibling tool is referenced for differentiation.

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?

Explicitly states the intended unit of work ("Use for one url") and two exclusions ("Not for batch work or unrestricted monitoring"). It stops short of naming a sibling tool for batch or monitoring use, so the routing is incomplete.

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 only say readOnlyHint/openWorldHint; the description adds the material behavior: chunked output, a 20,000-character default chunk, a 100,000-character free window, a paid upgrade link, and an x402 payment path requiring no Apify account. Rate/limit and payment semantics are exactly the kind of context annotations cannot carry.

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?

Purpose and scope are front-loaded in the first two sentences, and every remaining sentence carries the paging workflow or payment detail. It is fairly dense and the closing x402 sentence is specialized, but it is not padding — it answers an auth question an agent would otherwise hit.

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 covers return shape (Markdown chunks with indices, outline/find variants) and cost boundaries, so the essential calling information is present. It stops short of describing failure modes (non-public URLs, non-HTML content, what the paid-upgrade link looks like in the payload).

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 only 60% schema description coverage, the description meaningfully compensates: it explains what start_index does (reads later chunks inside the free window) and states max_chars' default and purpose. It does not mention max_chars' 50,000 ceiling or error behavior for out-of-range values, and find/outline semantics are already fully documented in 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 opening sentence names a specific verb and resource plus the return format: 'Returns a public page or PDF as Markdown, in chunks.' It goes further and scopes what this tool is *not* for (JavaScript-only pages, whole-site crawling), which separates it from siblings like smart_fetch, convert_html and extract_article.

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?

Explicit when-to-use ('one URL's readable text'), explicit when-not ('Not for JavaScript-only pages or crawling whole sites'), and it names the alternative for the excluded cases plus a recommended two-step workflow (outline/find first, then start_index). No routing inference is left to the agent.

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 readOnlyHint and openWorldHint annotations, the description discloses important behavior: results are limited unless authenticated, paid upgrade links are returned, full results require a Bearer token billed in TidyTools credits, and free-tier quotas vary by IP and shared caller pool. These are meaningful operational details an agent would not get from the annotations alone.

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 front-loaded with purpose and return behavior, then adds auth and quota details without filler. It is somewhat dense with multiple operational facts, but each sentence contributes relevant context for calling the tool correctly.

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 appropriately explains what comes back: a limited free result plus paid upgrade links. It also covers authentication, billing, free-tier quotas, and scope limitations, which is enough for an agent to invoke the tool with realistic expectations.

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% for both the domain and url parameters, and the schema already explains that either one may be supplied. The description reinforces the single-domain scope but adds no parameter-specific syntax or constraints beyond what the schema provides, so baseline 3 is appropriate.

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 states a specific verb and resource: looking up one domain's referring domains. It also scopes the tool to a single domain and explicitly excludes batch work and unrestricted monitoring, so an agent can tell what this tool is for without opening the 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?

The description gives clear usage context ('Use for one domain') and explicit exclusions ('Not for batch work or unrestricted monitoring'), which helps an agent avoid misuse. It does not name a specific alternative sibling tool for batch work, so it falls short of a 5.

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?

Provides rich detail beyond annotations: return format ('limited free result and paid upgrade links'), payment methods (x402 via Apify, TidyTools credits), auth header, and rate limits (1 per IP per UTC day, shared pool 20, global 20).

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. The description is dense but every sentence contributes: return, payment, auth, usage constraints, and rate limits. Could be better organized but is appropriately sized.

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?

Covers purpose, usage, billing, auth, and limits for a tool with one parameter and no output schema. Missing a description of the actual result format (e.g., image URL or binary), which would help the agent understand what to expect.

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% and the single url parameter is fully described in the schema. The description adds only 'Use for one url', which is redundant.

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 ('Removes one image background') and scope ('one url', 'not for batch work'). Distinguishes from batch use cases although not by naming a specific sibling.

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?

Explicitly says 'Use for one url' and 'Not for batch work or unrestricted monitoring', providing clear when-to-use and when-not. However, it doesn't name an alternative tool for batch scenarios.

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 annotations, the description discloses free-vs-paid result tiers, the Authorization: Bearer tt_… credit billing model, x402 payment without an Apify account, and concrete rate limits (1/IP/UTC day, 20 shared caller pool, 20 global). These are exactly the operational facts an agent needs before calling.

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 core purpose and scope constraint are front-loaded, and the sentence-per-idea structure is easy to scan. The payment/credits block is dense but earns its place for a metered tool; only the 'unrestricted monitoring' clause reads as filler.

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?

Auth, billing, rate limits, and single-URL scope are all covered, which is a lot for a one-parameter tool. What's missing is the result shape — whether the resized image comes back as a URL or binary and at what dimensions, since there are no width/height parameters and no output schema.

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% and the sole parameter is already documented as 'One public HTTP(S) URL.' The description's 'one url' phrasing matches the schema without adding syntax, size, or format detail, 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 opens with a specific verb and resource ('Resizes one public image') and states the single-input scope. It does not, however, distinguish itself from near-siblings like compress_image, convert_image, or upscale_image, so an agent must infer which image transformation to pick.

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 for one url. Not for batch work or unrestricted monitoring.' gives explicit positive and negative conditions. It stops short of naming the alternative tool for batch or other image operations, which is what would push this to a 5.

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 readOnlyHint/openWorldHint: it discloses the auth mechanism (Authorization: Bearer tt_…), the x402 payment path with no Apify account required, and concrete rate limits (1/IP/UTC day, 20 shared pool, 50 global). It also warns that unauthenticated calls return a truncated free result plus upgrade links — exactly the behavior an agent needs to interpret output correctly.

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 action, then the usage boundary, then billing/auth, then quotas — a sensible order. The billing/upgrade sentence is dense and slightly repetitive with the later auth sentence, but no line is disposable.

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 single-parameter read-only capture tool with no output schema, this covers action, scope, auth, payment, and quota — everything needed to call it and to interpret a truncated response. Nothing material 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?

Only one parameter and schema coverage is 100% ('One public HTTP(S) URL'), so the schema already carries the semantics. The description's 'one public page' phrasing reinforces the single-public-URL constraint but adds no format or edge-case detail 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?

Opens with a specific verb+resource+scope: 'Captures one public page screenshot.' The follow-up 'Use for one url. Not for batch work or unrestricted monitoring

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?

Explicitly states the selection condition (one url) and two exclusions (batch work, unrestricted monitoring). It never names the alternative tool an agent should use for batch work, so routing is implied rather than resolved.

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 only cover read-only and open-world behavior, and the description adds substantial context beyond that: a free/paid split with upgrade links, x402 payment without an Apify account, a Bearer tt_ token for full billed results, and concrete rate limits (3 per IP per UTC day, 50 per shared caller/ASN, 100 global). This is exactly the kind of cost, auth, and quota disclosure 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?

The purpose is stated first and the operational details follow; every sentence carries information an agent needs (returns, auth, quota). Sentence fragments make it terse in places, but there is no filler.

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 correctly states what comes back (a limited free result plus paid upgrade links) and covers auth and rate limits. The remaining gap is that a sibling with an almost identical name exists and the description does nothing to route between them.

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% and the single parameter is documented as 'One public HTTP(S) URL.' The description reinforces the semantics with 'Use for one url' and 'not for batch work', clarifying that only a single public URL is accepted. Baseline is 3 when the schema carries the load, so the added scope constraint earns a 4.

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 gives a specific verb and resource ('Checks one page's technical SEO signals') and the scope is bounded to a single URL. The only shortfall is that the near-identical sibling seo_browser_audit is never mentioned, so the agent can't tell the two apart from this description alone.

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 for one url. Not for batch work or unrestricted monitoring.' gives an explicit use case plus an explicit exclusion, which is more than most tools offer. However, it does not name the alternative to reach for (seo_browser_audit) when batch or rendered-browser auditing is needed.

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 declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds substantial context beyond that: it returns a limited free result plus paid upgrade links, payment can be made via x402 without an Apify account, and it specifies concrete rate limits (1/IP/UTC day, 20 shared ASN pool, 20 globally per day). This is exactly the extra behavioral detail the rubric rewards.

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 core capability ('Audits the rendered DOM...') is front-loaded, followed by return/cost behavior, usage boundary, and limits in terse sentences. Nearly every sentence earns its place, though the x402/Apify payment mechanics add some density that is only marginally relevant to tool selection.

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 carries the return-value burden, and it does address this by stating it returns a limited free result plus paid upgrade links. Combined with rate limits and the single-URL scope, the agent has enough to call it correctly, though the shape of the audit result itself remains 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?

There is only one parameter (url) with 100% schema description coverage, so the schema already documents it fully. The description reinforces the single-URL constraint with 'Use for one url' and 'one public page', but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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: 'Audits the rendered DOM of one public page.' The 'rendered DOM' phrasing hints at JS-rendered analysis, which distinguishes it somewhat from raw-HTML siblings. However, it never explicitly contrasts itself with the very similar sibling 'seo_audit', so an agent must infer the difference.

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 clear boundary conditions: 'Use for one url. Not for batch work or unrestricted monitoring.' This is an explicit when-to-use plus when-not. It stops short of naming the alternative tool for batch work (e.g., seo_audit), leaving the agent to guess the substitute.

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 readOnlyHint/openWorldHint annotations: concrete rate limits (3 per IP per UTC day, 50 shared caller/ASN pool, 100 globally), the auth mechanism (Authorization: Bearer tt_…), the billing model (TidyTools credits), and the x402/Apify payment path with no account required. An agent knows the cost and failure profile before calling.

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 core action and return behavior, then quotas last. The x402/Apify sentence is jargon-dense and only relevant to a subset of callers, keeping it just short of a 5, but nothing is redundant.

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 only two annotations, the description carries the burden well: it covers return shape, auth, pricing, and quota. It omits the output format of 'readable content' (markdown vs. text) and error behavior, which are the remaining gaps for a fetch 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 one fully described parameter at 100% schema coverage, the schema already does the work (baseline 3). The description adds meaning by repeatedly stressing the single-URL constraint ('one public URL', 'Use for one url'), reducing the chance of a misuse like passing a list.

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 one public URL as readable content', plus what comes back (limited free result + paid upgrade links). It does not name a distinguishing sibling such as read_url or extract_article, so the agent must infer differentiation from scope language alone.

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 for one url. Not for batch work or unrestricted monitoring' gives explicit when-to-use and when-not-to-use boundaries. It stops short of naming alternatives (read_url, extract_article, link_preview) that would settle ambiguous cases.

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 far beyond the readOnlyHint/openWorldHint annotations: discloses that free calls return a truncated result plus paid upgrade links, the x402-via-Apify payment path needing no Apify account, the Bearer tt_… credit-billed path for full results, and concrete rate limits (1/IP/UTC day, shared ASN pool of 20, 20 global/day). That is exactly the billing, auth and quota context an agent needs before calling.

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-loads the core action in the first sentence and packs the operational facts into short clauses. The payment and rate-limit sentences are dense and slightly run-on, but each carries information an agent would otherwise get wrong.

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, it covers scope, auth, billing, free-tier truncation and rate limits — everything needed to decide whether to call and how to interpret a limited response. Nothing material 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?

Schema coverage is 100% and the single parameter is already described as 'One public HTTP(S) URL.' The description's 'Use for one url' reinforces the one-URL-per-call constraint but adds no syntax, format or validation detail beyond the schema, 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?

States a specific verb+resource: extracts and summarizes one article with AI. The 'Use for one url' clause scopes it to single-page work, but it never names the obvious siblings (extract_article, summarize_url) so an agent must infer the distinction from those tools' own descriptions.

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 for one url. Not for batch work or unrestricted monitoring' gives explicit negative guidance about when not to use it, which is rare and useful. It stops short of naming the alternative tool to pick for batch or monitoring workloads.

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 readOnlyHint/openWorldHint annotations: it discloses that only a limited free result is returned, that paid upgrade links exist, that Apify Actor links can be paid with x402 via Apify with no account required, and it enumerates concrete rate limits (1 per IP per UTC day, shared AI caller/ASN pool 20, 20 globally per day). For a read tool these operational constraints are exactly the context an agent cannot get from structured fields.

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-loads what the tool does and the single-URL scope, then appends limits — good ordering. Slightly marred by telemetry-style fragments and a somewhat redundant payment mention (upgrade links stated, then x402/Apify payment restated), which cost a little but keep the entry short overall.

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 carries the burden and does cover the return shape at a high level (limited free result plus paid upgrade links) plus access and quota constraints. It doesn't characterize the summary itself (length, language, whether it follows page language), which is a minor residual gap for a one-parameter 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 description coverage is 100% and there is a single parameter, so the baseline is 3. The description reinforces the constraint ('one public page', 'Use for one url') but adds no syntax, format, or edge-case meaning beyond what 'One public HTTP(S) URL' already says.

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 (summarizes) and resource (one public page/URL) with AI, plus an explicit scope boundary ('Use for one url. Not for batch work or unrestricted monitoring'). It doesn't name or contrast with the closest siblings (summarize_article, read_url, extract_article), so an agent must infer which summarization/extraction tool fits which input type.

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 clear when-to-use ('Use for one url') and when-not ('Not for batch work or unrestricted monitoring') guidance that routes single-URL jobs here. It stops short of naming an alternative tool for batch work, so the agent is told what not to do but not what to do 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?

Goes well beyond the readOnly/openWorld annotations: it discloses free-tier limits (3 per IP per UTC day, 50 shared AI caller/ASN pool, 300 globally per day), that free results are truncated with paid upgrade links, and the two auth paths (x402 via Apify vs. Bearer tt_ token billed in credits). This is exactly the operational context an agent needs before spending a 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?

Front-loads what it does, then terse sentences for pricing, auth, scope, and limits. Dense but every sentence carries a distinct fact; only minor redundancy between 'Returns a limited free result' and the free-quota sentence.

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 a simple two-param input, the definition covers cost, auth, quota, and the shape of the return (limited free result plus upgrade links). What 'limited' means concretely is left vague, but nothing blocking 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?

Schema description coverage is 100% and the schema already documents the domain/url alias and the anyOf requirement. The description repeats only 'one domain' and adds no format or validation detail beyond the schema, so 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: looks up one domain's CrUX traffic rank. Scope is narrowed with 'Use for one domain. Not for batch work or unrestricted monitoring.', which distinguishes it from broader siblings like domain_overview or seo_audit, though none are named.

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 explicit when-to-use (single domain lookup) and when-not (batch work, unrestricted monitoring). It stops short of naming a specific alternative tool for those other cases, so the routing is not fully closed.

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 annotations, the description discloses important behavior: it returns a limited free result plus paid upgrade links, explains x402 payment via Apify without an account, and lists exact free-tier rate limits by IP and global pool. This is substantial operational context that the readOnlyHint/openWorldHint annotations alone do not provide.

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 purpose is front-loaded and the description stays reasonably compact, with quotas and payment details placed after the core use case. There is minor redundancy in saying 'Use for one audio base64' when the required parameter already makes that clear, but overall it is efficiently structured.

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 simple read-only, one-parameter transcription tool, the description covers the operation, input scope, output nature, payment model, and quota limits. No output schema exists, but the description sufficiently explains that the tool returns a limited free result and upgrade links, so nothing critical is missing for correct invocation.

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 the input schema already documents the single audio_base64 parameter as a base64 PCM WAV clip with a 60-second maximum. The description repeats this constraint but adds no new syntax, encoding, or format details beyond the schema, so the baseline 3 is appropriate.

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 gives a specific verb and resource: transcribes one WAV audio clip of at most 60 seconds. It also states the boundary explicitly, saying it is not for batch work or unrestricted monitoring, so the agent can distinguish correct use from incorrect scope without additional context.

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 clearly states when to use the tool, for one audio base64 clip, and when not to use it, for batch work or unrestricted monitoring. It does not name an alternative sibling tool, though none of the listed siblings appears to be a direct transcription alternative.

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 readOnlyHint/openWorldHint annotations: it discloses that results are a truncated free version plus paid upgrade links, how payment works (x402 via Apify, no account needed), and exact rate limits (1 per IP per UTC day, 20 shared per ASN pool, 20 globally per day). This is precisely the operational detail 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?

Five dense sentences, purpose front-loaded, and each sentence carries distinct information (purpose, output, payment, usage, quota). Ordering is slightly scattered – usage guidance sits between payment and quota details – but there is no filler.

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 only two params and no output schema, the description covers behavior, payment, and quotas well. The remaining gap is the omission of 'target_language' format expectations, which is the one thing an agent could plausibly get wrong when calling.

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 50%: 'text' is documented, 'target_language' has no description or enum. The description adds the 4,000-character cap for 'text' (not in the schema), but says nothing about the expected format of 'target_language' (code vs. language name) or source-language handling. Adequate but leaves the uncovered parameter unexplained.

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 (translates), resource (text), and scope (up to 4,000 characters, one text at a time). The exclusions 'not for batch work or unrestricted monitoring' separate it from siblings like classify_text, ai_extract, and summarize tools without needing the 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 for one text. Not for batch work or unrestricted monitoring' gives clear when-to-use and when-not conditions. It stops short of naming the alternative tool for batch translation, so it is strong guidance but not fully 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?

Annotations only declare readOnly and openWorld, so the description carries real weight: it discloses the return shape (limited free result plus paid upgrade links), the x402/Apify payment path requiring no account, and precise free-tier limits (1 per IP per UTC day, 20 shared pool, 20 global). None of that is in structured fields.

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?

Purpose is front-loaded, followed by return behavior, payment path, scope exclusions, then limits. Every sentence is on-topic, though the stacked rate-limit clause is dense and could read slightly cleaner.

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 single-parameter tool with no output schema, the description covers what comes back, payment requirements, and quota constraints. The return value is still somewhat vague (what exactly the 'limited free result' contains), keeping it just short of fully self-contained.

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 one parameter at 100% schema coverage, the schema already documents 'One public HTTP(S) URL.' The description reinforces 'one public image'/'one url' but adds no format or constraint detail beyond the schema, 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?

States a specific verb+resource+scope: "Upscales one public image by 2x." The 'one' and '2x' distinguish it cleanly from siblings like resize_image, convert_image, and compress_image, so an agent can route to it without opening another 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 for one url. Not for batch work or unrestricted monitoring" gives explicit scope and exclusions beyond the obvious. It stops short of naming a sibling alternative for batch/image-resizing cases, so it is clear context rather than a full when/when-not/alternative 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?

Beyond the annotations, the description discloses authentication requirements, billing behavior, free-result limits, paid upgrade links, x402 payment via Apify, and precise rate limits per IP and caller pool. These are operationally important details for an open-world read-only validation tool.

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 purpose and single-email scope are front-loaded, and the remaining sentences mostly carry useful operational details. It is somewhat dense with billing and rate-limit information, but the content is relevant and 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 simple one-parameter read-only tool with no output schema, the description is complete: it explains the check performed, result limitations, authentication, billing, and rate limits. An agent has enough information to decide whether and how to invoke it.

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 schema has one parameter with 100% description coverage, so the baseline is 3. The description reinforces that it must be a single email address, but it does not add format examples or validation constraints beyond what the schema already says.

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: it checks one email address's syntax and domain mail records. It also explicitly scopes the tool to a single email and contrasts that with batch work or unrestricted monitoring, so an agent can distinguish it from broader data-collection siblings.

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 clear usage boundaries: use for one email, not batch work, and not unrestricted monitoring. It does not name a specific alternative sibling for batch validation, but the exclusions are explicit enough to prevent common misuse.

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