99tests

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

With no annotations, the description carries the full burden: it usefully discloses the key behavioral trait that no card is charged directly and that payment happens via a hosted browser checkout. It omits other important traits such as whether the job is created before payment, auth requirements, or what happens to unpaid jobs.

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 short sentences with zero waste; the action and the key side effect (checkout link, no direct charge) are 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 three-parameter mutation tool with no output schema and no annotations, the description covers the essential output (a hosted checkout link) but leaves gaps about the returned job identifier, error conditions, and payment flow lifecycle.

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%, with email, country, and the starter/standard/deep package values already documented in the schema. The description adds no additional meaning about parameters, 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?

States a specific verb and resource ('Create a 99tests test job') and adds the outcome ('return a hosted checkout link to pay in a browser'), which makes it distinguishable from the read-only siblings like get_job_status and list_packages. It does not name or explicitly contrast with any sibling, so it stops 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?

There is no explicit when-to-use guidance, no prerequisite flow (e.g., call list_packages first to pick a package), and no statement of what to do if the user abandons checkout. Usage is only implied by the fact that a checkout link is produced.

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

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

With no annotations, the description carries the full behavioral burden; it does disclose a polling/rate constraint, which is genuinely useful context beyond the schema. It omits whether the call is read-only, what happens with an invalid or expired token, and how long tokens remain valid.

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 short sentences: purpose first, operational constraint second. No filler, nothing redundant with the schema.

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

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

For a single-parameter read tool with no output schema, the description covers what is retrieved (stage and progress) and the key usage constraint. Only token failure modes are missing, which is a minor gap at 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 the single parameter is already documented as 'The customer's status link or its token'. The description repeats this phrasing without adding format, validation, or error-handling 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 states a specific verb and resource ('Check a job's stage and progress'), which clearly separates it from siblings like get_report and create_test_job. It stops short of explicitly naming those siblings as alternatives.

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 operational guidance ('Poll at most every 10 minutes'), which tells the agent how to use the tool once selected. It does not say when to prefer it over get_report or what to do when the job is finished, leaving the routing decision implicit.

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

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

With no annotations, the description must carry behavioral load, and it does supply two useful facts: the operation is scoped to the customer's own status link/token (an authorization prerequisite) and the result is packaged as fix prompts. It omits what happens when the job is not yet delivered, whether access is read-only, and failure behavior for an invalid token — gaps that matter for a token-authenticated retrieval 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?

One sentence, no filler, with the action and the input mechanism front-loaded and the output form appended as a modifier. Nothing could be removed without losing 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 does the right thing by characterizing the return as 'verified findings ... as ready-to-paste fix prompts'. For a one-parameter read tool this is close to sufficient; only edge cases (job not delivered, bad token) are 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?

Schema description coverage is 100% and the single parameter already documents that it accepts 'the customer's status link or its token'. The description restates that same duality ('using the customer's own status link or token') without adding format, token-extraction, or validation details, so it stays at the baseline for fully covered schemas.

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 ('Get the verified findings for a delivered job') and adds the output form ('ready-to-paste fix prompts'), which is concrete enough to distinguish it from get_job_status and get_sample_report by implication. It never names those siblings, so differentiation relies on the agent inferring 'delivered job' means the terminal state, not a live status check.

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 phrase 'for a delivered job' implicitly bounds when it is applicable (only after completion), which is useful. However, there is no explicit when-not guidance and no naming of the alternatives an agent should use for in-flight status (get_job_status) or sample output (get_sample_report), leaving 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?

No annotations exist, so the description carries the disclosure burden, and it does state what comes back (a description and a link). It is implicitly a safe, non-destructive read with no side effects, though that is never said outright and nothing is mentioned about link validity or whether it requires auth.

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?

A single front-loaded sentence with zero redundancy: purpose (sample report), payload (description + link), and motive (preview before paying) all land at once.

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 preview tool with no output schema, the description covers both intent and return shape adequately. A little more on the format of the returned link (e.g. URL vs. reference) or on what happens if no sample is available would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case; there is no parameter meaning to add or omit. Nothing in the description conflicts with 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?

States a specific verb and resource: it returns a description plus a link to an example 99tests report. The word 'example'/'sample' plus 'before paying' makes it distinguishable from the sibling get_report, which presumably returns a real report, though the description never names that sibling explicitly.

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 clause 'so you can see the format before paying' gives a clear situational trigger: call this when you want to preview report structure prior to purchase. It does not explicitly exclude or route to alternatives (e.g. get_report) or note any prerequisites, so it stops short of a full when/when-not treatment.

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

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

No annotations exist, so the description carries the full burden. 'List' implies a read-only, non-destructive operation and the text discloses the returned data fields, but it says nothing about result volume, currency-selection behavior, or whether GST is shown separately or bundled.

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?

A single dense sentence front-loads the verb and resource, then packs the returned attributes. Every clause adds information; nothing is repeated from the name or 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 zero-parameter read-only listing with no output schema, the description compensates well by naming the fields returned. The only residual gap is that it does not flag whether prices appear in both currencies side by side or which one is primary.

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 the baseline is 4; there is nothing to disambiguate and the schema requires no explanation. The description correctly implies an unfiltered, complete listing rather than a search.

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 plus resource ('List 99tests packages') and enumerates what each entry contains (prices in INR+GST and USD, session counts, devices, turnaround). This clearly separates it from the job/report siblings, though it never names them.

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?

Usage is only implied: 'List' signals a catalog lookup with no parameters, and the sibling set (create_test_job, get_job_status, get_report) makes the distinction obvious by resource. There is no explicit when-to-use statement, prerequisite, or named alternative.

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