Kilotest

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds minimal behavioral context ('full report', JSON format) but does not disclose behaviors such as error handling, required permission, or behavior when the report does not exist.

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. 'One full report' adds useful scope, and 'in JSON' specifies the output format without redundancy.

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 schema and annotations cover required parameters and safety behavior, and an output schema exists, so return values need not be described. However, the description lacks any usage context or alternative routing, which is a noticeable gap for a tool with several related siblings.

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 provides full coverage of both parameters, including descriptions and examples, so the description carries no additional parameter semantics. With 100% schema coverage, the baseline score 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 clearly identifies the operation (get), resource (report), scope (one full report), and format (JSON). It differentiates from the sibling listReports by emphasizing 'one full report,' though it does not explicitly name the sibling or describe the distinction.

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 guidance on when to use this tool versus alternatives such as listReports. The description neither states prerequisites, exclusions, nor conditions under which this tool should be selected, leaving usage entirely 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 declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by specifying that the tool returns rule-engine diagnoses about how the element exhibited the issue, going beyond just 'list diagnoses'.

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 sentence and stays reasonably compact. It is slightly wordy with phrases like 'reported as exhibiting one issue in one report,' but it avoids redundant detail and is structured to present the core purpose first.

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 the rich parameter schema, output schema, and safety annotations, most information needed to invoke the tool is present. The main gap is the lack of explicit relationship to sibling tools, but the description still conveys the precise scope of the lookup.

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 all four parameters documented and given examples. The tool description does not add parameter-level meaning beyond the schema, so the baseline score 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 names a specific resource (one element in one report exhibiting one issue) and explains the focus of the tool: providing diagnoses from rule engines. It is clear enough to distinguish from siblings like listReports and listViolators, though the verb 'provide details' is somewhat generic.

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 implies this is a drill-down tool for a specific existing report, issue, and catalog element, but it does not explicitly state when to use it over siblings like listIssues or listViolators, nor does it give exclusion criteria. Usage is inferable but not directly stated.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds a small amount of useful scoping by saying 'one report' and 'basics about the issues,' but it does not disclose additional behavioral details such as how much of the issue details are returned or any limitations.

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 with no wasted words and the core subject is front-loaded. It is concise and readable, though slightly vague in what 'details' means.

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 two-parameter read-only tool with an output schema and safety annotations, the description provides enough subject scope to be minimally viable. However, it still leaves ambiguity about how listIssues differs from getReport and listDiagnoses, which is a meaningful 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 description coverage is 100%, and both parameters already have meaningful descriptions and examples. The description does not add parameter-level nuance, but because the schema carries the full burden, a 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 names a resource ('one report') and a topic ('issues reported in it'), but the verb 'Provide details' is generic and doesn't clearly state that this tool lists issues. It also overlaps with sibling getReport, which likely also provides report details, so an agent cannot confidently differentiate them from the 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?

No explicit guidance is given about when to use this tool versus alternatives such as getReport or listDiagnoses. The only implied context is that the caller must identify a report via jobID and timeStamp, but there are no exclusions or conditions for choosing a sibling.

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 annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds modest context about returning 'basics' and covering 'all available' reports, but it does not disclose additional behaviors like pagination, permissions, or output shape beyond what annotations imply.

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, direct sentence with no filler or repetition. It front-loads the key information about scope ('all available reports') and result type ('basics').

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 parameter-less read-only listing tool with an output schema and strong annotations, the description is largely sufficient. The main gap is that 'basics' is slightly vague, but the output schema can clarify return values, so the description does not need to enumerate fields.

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 description does not need to explain parameter meaning. The baseline of 4 for a parameter-less tool applies here, and the description adds no conflicting or confusing parameter-related information.

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 clear verb ('Provide') and resource ('basics about all available reports'), which conveys an overview-list purpose. It is distinguishable from the sibling getReport by the word 'basics' and 'all available', though it does not explicitly call out the difference from other list* 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?

There is no guidance on when to use this tool versus alternatives. It implies use when you need an overview of all reports, but it does not mention getReport for detailed single-report retrieval or explain exclusions.

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 safety profile is covered. The description adds useful scope context by clarifying that the tool returns details for one issue and basic information about the page elements exhibiting the issue, though 'basics' remains somewhat vague.

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 sentence with no filler. The core scope is front-loaded, and the qualifying phrase about page elements adds necessary precision without over-explaining.

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 input schema explains all parameters, the output schema covers return structure, and annotations cover the read-only/idempotent nature. The description adds the missing scoping information about singleton issue details and exhibiting elements, leaving only sibling-routing guidance absent, which is more of a usage-guideline 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 description coverage is 100%: jobID, issueID, and timeStamp all have descriptive text and examples. The description adds no parameter-level meaning beyond what the schema already 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 description uses a specific verb ('Provide details') and clearly identifies the resource granularity: one issue within one report, plus the page elements exhibiting the issue. It is distinct from broad listing siblings like listReports and listIssues, though it does not explicitly name a sibling to differentiate from.

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 states what the tool does but gives no guidance on when to use it versus alternatives such as listIssues, getReport, or listDiagnoses. There are no exclusions, prerequisites, or explicit routing cues, so the agent must infer usage from the wording.

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 nothing about side effects, persistence, permissions, or follow-up behavior. Annotations only provide negative flags (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so an agent cannot infer whether the request creates a ticket, updates a backlog, or sends a notification.

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 short and free of filler, but it is essentially a restatement of the tool name with little added structure or front-loaded detail. It is concise, but its brevity comes at the cost of informative 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 an output schema and one fully documented parameter, the mechanical details are covered. Still, the description omits what the tool does with the request or what the expected outcome is, leaving an agent without enough behavioral context to use it confidently.

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%, so the 'feature' parameter is already well documented in the schema. The description adds only marginal framing by mentioning both additions and improvements, not enough to raise the score above baseline.

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

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

The description states the resource ('a feature') and the intended action ('add or improve'), which distinguishes it from sibling test/report tools. However, the verb 'process' is vague about what actually happens to the request, leaving the tool's core function under-specified.

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 implies use when a feature should be added or improved, but gives no explicit guidance on when to use this tool instead of requestTest, requestRetest, or other siblings. No exclusions or alternative routing are provided.

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 indicate a non-readonly, non-idempotent mutation (readOnlyHint=false, idempotentHint=false), but the description adds no behavioral detail. It does not disclose what 'process my request' entails, such as side effects, asynchronous behavior, or what triggers a retest. With minimal annotation context, this is a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, compact sentence with no filler. The key prerequisite (report availability) is included, though the phrasing 'Process my request' is slightly stilted and could be more direct.

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?

An output schema is present, so return values need not be described. The three required parameters are fully documented in the schema, and the description conveys the prerequisite that a report must exist. For a low-complexity tool, this is reasonably complete, though it could clarify the relationship between jobID and timeStamp.

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%, with clear descriptions and examples for jobID, reason, and timeStamp. The description adds no parameter-level meaning 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 identifies a specific action ('process my request to retest') and a resource ('a page about which a report is available'). It distinguishes from siblings like requestTest by emphasizing retesting and report availability, though it does not name the alternative 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 phrase 'about which a report is available' implies a prerequisite condition for using this tool, but no explicit guidance is given about when to prefer requestTest or requestFeature, nor any exclusions. The usage context is implied rather than stated.

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 indicate a mutating, non-idempotent, non-destructive operation; the description adds that this is a request-processing step rather than an actual test execution, which is useful. It does not disclose side effects, asynchrony, or prerequisites, but the output schema covers return details.

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?

Single sentence with no filler, but 'Process my request' is somewhat roundabout and the title is identical to the description. Still, the core constraint is 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 simple 3-parameter tool with full schema coverage, an output schema, and annotations covering the mutability profile, the description provides enough orientation: it states the resource (a page without a report) and the action (request a test). It lacks explicit routing to requestRetest, but that gap is minor given the context signals.

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?

Input schema covers all three parameters (URL, reason, description) with constraints and format notes, so the description adds no parameter-level information. Baseline of 3 applies because schema coverage is 100%.

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 identifies the action ('test a page') and the condition ('no report is available yet'), which separates it from read-only report tools and from requestRetest. However, it doesn't name a sibling explicitly and uses the indirect phrase 'Process my request,' so it falls short of full explicitness.

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 'about which no report is available yet' gives an implicit trigger for using this tool, and the sibling list includes requestRetest, which would be the alternative for pages with reports. But there is no explicit when-to-use/not-to-use guidance or named alternatives.

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