bulk-url-checker

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations by specifying the exact fields of each result, including that status code is null if unreachable and that results include response time and error messages. It also mentions pagination, which is not in the annotations.

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 two sentences, front-loaded with the action, and every word adds value. It avoids redundancy with the annotations and schema, presenting only the necessary information about result contents and pagination in a compact form.

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 paginated listing tool, the description is almost complete. It explains what each result contains, fills in the absence of an output schema, and implies pagination. It does not explicitly mention offset/limit semantics, but these are defined in the schema. Given the sibling tools and the straightforward nature of the operation, no critical context 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 0%, so the description must compensate for parameter meaning. It mentions 'paginated results' but does not explicitly explain that limit and offset control pagination, nor does it define job_id. While these are inferable from the schema's names and defaults, the description leaves room for ambiguity. It partially compensates by hinting at pagination, but lacks explicit parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Fetch') and resource ('paginated results for a job'), clearly distinguishing it from sibling tools like get_job_status and get_usage by focusing on actual result data (URL, status code, response time, errors). This is unambiguous and directly answers 'what does this tool do?'.

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 clearly implies usage context: to retrieve the results of a job rather than its status or usage. However, it does not explicitly name alternatives or state when not to use this tool. Given the sibling tool names, an agent can infer the distinction, but explicit guidance 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?

Annotations already cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description doesn't need to repeat that. It adds a slight behavioral cue by mentioning 'progress,' but doesn't disclose response format, error behavior, or any other traits. It's adequate but shallow.

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 one sentence, immediately front-loaded with the verb and object. There is no filler or irrelevant information, making it highly concise.

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?

The tool has no output schema, so the description should explain what 'status and progress' means in practical terms. It doesn't mention possible statuses, return format, or error cases. For an AI agent, this leaves too much ambiguity about the tool's behavior.

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 has a single required parameter job_id with no description, and schema_description_coverage is 0%. The description only says 'a job,' which adds minimal meaning beyond the parameter name. It fails to explain what job_id represents or how it relates to other tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Get' and identifies the resource as 'current status and progress of a job,' which clearly distinguishes it from sibling tools like get_job_results (results) and submit_urls (submission). The purpose is unambiguous.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that this is for checking job progress or that get_job_results is for retrieving outputs. No exclusions or contextual hints are given.

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, idempotentHint=true, and destructiveHint=false, so the agent knows it is a safe read. The description adds scope context ('for this API key') but does not disclose response format or any additional behavioral traits. The bar is lower with annotations, and this adequately aligns.

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 a single, focused sentence with no wasted words. It delivers the essential information immediately and is appropriately sized for a simple tool.

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 no-parameter, read-only tool with strong annotations, the description is sufficient. It clearly states the purpose and scope, though the return value format is not explicitly described. Given the simplicity, this is acceptable but could mention output format for full completeness.

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 has zero parameters, so the baseline is 4. The description adds meaningful context that the API key is the implicit authentication context, which is useful. No parameters need further explanation.

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 the verb 'Return' with a specific resource 'current credit balance' and scope 'for this API key'. This distinguishes it from sibling tools focused on job results, status, and submission.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use guidance or alternative comparisons are provided. The usage is implied by the description's clarity, but there is no mention of exclusions or relation to sibling tools.

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 readOnly, idempotent, and non-destructive behavior. The description adds behavioral context beyond that by stating the verification process is interactive and happens in the web dashboard, not through the API, while also explaining the performance benefit of verified domains. This is genuinely useful disclosure.

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 yet fully uses its sentences: one sentence states the purpose, one explains performance impact, one gives concrete user-facing behavior, and one explains how verification works. No sentence is wasted or 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?

For a zero-parameter, read-only list operation, the description is remarkably complete. It covers purpose, scope, performance implications, how the verification process works, and practical guidance for the user. The tool's trivial, provides no output schema, so few other details are needed.

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 are zero parameters and the input schema confirms it, so no parameter documentation is needed. The description adds the natural implication that the result is scoped to the authenticated API key's owner, which gives semantic context beyond the empty 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 opens with the specific verb-resource pair 'List domains' and clarifies exactly what is being listed: domains whose ownership this API key can demonstrate. This clearly differentiates the tool from siblings like get_job_results, get_job_status, and submit_urls, which concern jobs and usage.

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 by saying verified domains are checked 'substantially faster' and explicitly advises recommending verification when a single site keeps being checked but is missing from the list. It does not name alternatives or explicitly say when not to use it, but the caller can infer this is the correct tool for auditing verified domains.

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 discloses important behavioral traits beyond annotations: return value (job_id), synchronous vs asynchronous behavior depending on job size, timeout, and how to retrieve results via sibling tools. This is valuable context for the agent's decision-making.

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?

Two sentences with no redundancy. The first sentence states the purpose, the second explains return behavior and polling. Well-structured and front-loaded.

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 job-submission tool with no output schema, this description covers all essential aspects: the action, the return value, how to use sibling tools, and how to handle different job sizes. It gives an agent complete guidance for correct invocation and follow-up.

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 fully documents the 'urls' parameter including the scheme requirement. The description adds a meaningful constraint (~200 URL threshold for synchronous processing) that affects how the parameter value is used, going 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 clearly states the tool submits a list of URLs for checking, using a specific verb and resource. It also distinguishes itself from sibling tools by mentioning the resulting job_id and the polling/fetching options.

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 explains the behavior for two cases: small jobs (≤~200 URLs) wait up to 60s and return results directly, larger jobs return early with a job_id to poll. This gives concrete when-to-use and how-to-proceed guidance, differentiating it from the sibling polling tools.

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