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 cover read-only, idempotent, and non-destructive behavior, so the description only needs to add context. It adds account-level scope and the 'currently available' dynamic aspect of the value, which is useful; auth or rate-limit details are not needed for this simple quota read.

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 14-word sentence with the verb front-loaded and no filler. Every word adds meaning, and it does not repeat annotation content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, this description still provides the essential contract: the return value is a count of URL checks currently available on the account. For a simple zero-parameter quota tool, nothing necessary 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?

The tool takes zero parameters, so baseline 4 applies. There is no parameter detail the description needs to compensate for, and the text introduces no parameter ambiguity.

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 ('Returns') and names the exact resource: the number of URL checks available on the account. This separates it from the job- and domain-focused siblings, so an agent can tell get_usage from get_job_results, get_job_status, and get_verified_domains.

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?

There is no explicit statement about when to call this tool or when to choose a sibling instead. The sibling names and the word 'available' imply a quota-check use case, but the description leaves that inference entirely 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds valuable behavioral context: that verified domains yield faster checks, and that verification is interactive and performed outside the API. This goes beyond annotations without contradicting them, providing useful operational insight.

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 three sentences, each with a distinct purpose: the main function, the performance benefit, and the verification method. It is front-loaded with the core action and contains no filler or redundant phrasing.

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 list tool with no parameters and no output schema, the description covers all necessary aspects: what it lists, why it matters, and how verification works. An agent would know exactly what to expect and when to use it. No critical 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?

The tool has zero parameters, so the schema fully covers them (100% coverage). The description adds no parameter-specific details because none are needed. Per the baseline for zero parameters, a score of 4 is appropriate; there is nothing to compensate for.

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 ('Lists') and resource ('the domains this account has proven ownership of'), clearly distinguishing it from siblings like get_job_results or submit_urls which deal with jobs and URL submissions. The scope is unambiguous and immediately understandable.

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 explains when this tool is relevant: to retrieve verified domains for faster checks, implying usage before operations that benefit from verified status. It also clarifies that verification itself is not done through this API but via the web dashboard, setting expectations. While it doesn't name alternative tools explicitly, the context makes its purpose distinct from siblings.

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 substantially enriches what annotations alone provide. It discloses exact batching behavior: up to about 200 URLs complete inline after waiting up to 60 seconds, while larger lists return immediately with only a job_id and results arrive asynchronously. This goes well beyond the readOnlyHint, openWorldHint, idempotentHint, and destructiveHint flags.

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 packs the action, return value, threshold, timeout, and async behavior into two compact sentences. It is front-loaded with the core purpose and every sentence adds information without repetition or 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 tool with no output schema, the description covers the essential behavior: what is submitted, what is returned, when results are direct, and when the caller must wait for job progress. A small gap is that it could explicitly point to get_job_status for monitoring larger jobs, but that sibling tool likely carries its own documentation.

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 for the single 'urls' parameter is 100%, including the requirement for http:// or https:// schemes, so the schema already carries the parameter semantics. The description adds threshold context (about 200 URLs) but does not add further meaning to the parameter itself, matching the baseline for high schema coverage.

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 action ('Submits a list of URLs'), the resource ('URLs to be checked'), and the key output ('returns a job_id'). It clearly differentiates this from the sibling get_* tools, which retrieve job results, status, usage, or domains rather than submitting work.

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 context on when inline results are returned versus when the caller should expect only a job_id, based on list size and the 60-second wait. It does not explicitly name alternatives or exclusions, but the sibling tools are complements rather than competing submit endpoints, so the lack of an explicit when-not is a minor gap.

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