Kilotest

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

Annotations already disclose readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the result is a 'full report in JSON', which gives some response-format context, but it does not address pagination, size limits, or failure behavior.

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 front-loaded sentence with no filler or repetition. It communicates the verb, resource, scope, and output format economically, and every word contributes to the meaning.

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 simple two-parameter schema, existing output schema, and strong safety annotations, the description is nearly complete for invocation purposes. The main missing element is explicit guidance on when to use getReport versus listReports, but the tool is simple enough that this is not a critical 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 include type and example values, so the schema already carries the semantic weight. The description adds no parameter-specific meaning beyond what the schema provides, which matches the baseline for full 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 clearly states the action ('Get'), the resource ('one full report'), and the output format ('JSON'). The phrase 'one full report' helps distinguish it from the sibling listReports by implying a detailed single-item fetch rather than a list operation, though it does not explicitly name 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?

The description gives no guidance about when to use this tool versus alternatives like listReports. It relies entirely on the tool name and input schema to imply the use case, with no explicit context, prerequisites, or 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 establish readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is clear. The description adds useful context that the result includes rule-engine diagnoses explaining how the element exhibited the issue, but it does not disclose other behaviors such as pagination, ordering, or missing-diagnosis behavior.

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, front-loaded sentence with no filler or repetition. Every clause earns its place by narrowing the scope to one element, one issue, one report, and rule-engine diagnoses.

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 output schema, complete parameter schema, and safety annotations, the description provides enough context for an agent to invoke the tool correctly. It does not explain how to choose this tool over sibling tools, but that gap is more about usage guidance than about missing invocation details.

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 all four parameters are already documented with examples. The description's references to 'one element', 'one issue', and 'one report' map conceptually to catalogIndex, issueID, and timeStamp/jobID, but it adds no new parameter-level 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?

The description uses a specific verb ('Provide details about') and a precise resource scope: one element exhibiting one issue in one report, with rule-engine diagnoses. This differentiates it from sibling tools like listIssues and listViolators, though it never names them explicitly. It is slightly broader than the tool name 'listDiagnoses' suggests, focusing on element details rather than the diagnoses list itself.

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 the tool is for retrieving a single diagnosed element's rule-engine findings, but it gives no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as listIssues or listViolators or explain how this tool fits into a workflow.

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, destructiveHint:false, idempotentHint, and openWorldHint:false, so the safety profile is covered. The description adds only a mild scope limitation ('basics about issues'), which is some added context but does not meaningfully explain how the tool behaves beyond what annotations and the tool name 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, front-loaded sentence with no filler. It is not bloated and can be scanned quickly. It earns a slight deduction because its vague wording means its brevity comes at the expense of precision rather than packing useful detail into 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?

Given 100% schema coverage, strong annotations, and an output schema, the description is complete enough for input invocation. However, it lacks the context an agent needs to decide between this and the seven sibling tools, especially getReport and listDiagnoses. It does not fill the selection 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?

The input schema has 100% coverage, so both jobID and timeStamp are already described clearly with examples. The description doesn't add new meaning to the parameters; it just combines them into a one-report context. This matches the baseline for fully documented 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?

The description states a broad action ('Provide details about one report') and mentions issues only as 'basics about the issues reported in it.' It is somewhat clear, but a potential agent reading it won't know that the tool's primary output is a list of issues, and it doesn't distinguish this from siblings like getReport or listDiagnoses.

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 no explicit guidance about when to use this tool versus alternatives. It doesn't mention prerequisites, selection criteria, or cases where another sibling tool should be preferred. The phrase 'one report' faintly implies a single-report scope, but that is not actionable 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'basics' qualifier, suggesting the output is a summary rather than full details, which is useful but minimal. No additional behavioral traits like pagination or filtering are disclosed.

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, direct sentence with no redundant words. The core action and scope are front-loaded, making it immediately scannable and appropriately sized for a simple parameterless 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 parameterless, read-only list tool with an output schema and safety annotations, the description is largely sufficient. An agent can invoke it without ambiguity. However, it lacks any indication of when to prefer it over sibling list tools, which 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 has zero parameters, and the schema is empty with 100% coverage. Since there are no parameters to document, the baseline of 4 applies. The description does not need to add parameter semantics.

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 ('all available reports'), defining the tool's scope as delivering basic information about every report. It implies a listing operation and is distinguishable from getReport, though the term 'basics' is somewhat vague and it doesn't explicitly differentiate from sibling list 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?

No guidance is given on when to use this tool versus alternatives such as getReport, listDiagnoses, listIssues, or listViolators. The description simply states what it does, leaving the agent to infer selection criteria. There are no exclusions or explicit 'use this when' instructions.

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 read-only safety profile is clear. The description adds the content scope (elements exhibiting the issue) but discloses no additional behavioral traits such as pagination, limits, or authentication needs, which is acceptable given 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 a single sentence with no filler, and it front-loads the core action. It is concise and readable, though 'details' and 'basics' leave some precision on the table.

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 complete input schema, output schema, and annotations, the description provides enough context for a read-only tool that returns element details for a single issue in a report. It lacks explicit sibling differentiation, but the core context an agent needs to invoke it is present.

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?

All three parameters are described in the schema with examples, so schema description coverage is 100%. The description provides no additional parameter-level information, 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 identifies a clear resource (one issue in one report) and states that it returns details about elements exhibiting the issue, which distinguishes it from listReports and listIssues. However, 'details' and 'basics' are somewhat vague, and it does not explicitly name sibling tools to sharpen 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?

The phrase 'one issue in one report' implies when this tool should be used, but there is no explicit guidance about when not to use it or which sibling tool to prefer in other scenarios. No alternatives such as getReport or listIssues are mentioned, so the usage context is only implied.

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 the operation is not read-only and not destructive; the description adds no behavioral detail such as whether a request is created, stored, forwarded, or requires authorization. 'Process' is too generic to disclose meaningful side effects, and there is no contradiction with 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 one short sentence with no wasted words and the key qualifier 'add or improve a feature' appears at the end, still sufficiently front-loaded. The first-person 'my request' is slightly redundant given the tool name, but the overall size is appropriate.

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?

This is a simple one-parameter tool with complete schema coverage and an output schema present, so the description does not need to cover return values. It lacks explicit side-effect information, but the low operational complexity and clear feature scope make it adequate for an agent to invoke 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 single parameter is fully described in the schema (20-1000 character feature description), so the schema carries the semantic weight. The description's 'add or improve' phrasing slightly reinforces the parameter's meaning but adds no material 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?

The description states the resource ('feature') and indicates intent ('add or improve') with the verb 'process', which is somewhat generic but clear enough. It is distinguishable from siblings like requestTest and requestRetest because it explicitly targets features rather than tests or reports.

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 'add or improve a feature' gives clear context for when the tool applies: any feature-request style input. It does not explicitly enumerate exclusions or alternatives, but the sibling tool names and the feature qualifier make the selection case obvious.

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 indicate this is not read-only, not idempotent, and not destructive, but the description does not explain what side effects occur, whether the retest is queued or immediate, or whether repeated calls create duplicate retest requests. The description adds little behavioral context beyond what the annotations already communicate.

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 short sentence with no filler fluff, but 'Process my request' is conversational and adds little technical value. It is concise but lacks strong front-loaded, tool-centric structure.

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?

Although the input schema and output schema cover parameters and return values, the description omits how to choose this tool over requestTest and fails to convey behavioral implications of a non-idempotent, non-read-only operation. An agent would need more context to confidently invoke 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?

Schema coverage is 100%, and each parameter already has a clear description with an example. The tool description does not add new parameter meaning, 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 identifies a specific action ('retest') and resource ('a page about which a report is available'), which distinguishes it from the sibling requestTest. However, the phrase 'Process my request' is vague and does not state what invoking the tool actually accomplishes beyond submitting a request.

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 and suggests this is for retesting an already-tested page, but it never explicitly says when to use requestRetest versus requestTest, nor does it name alternatives. 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 only indicate this is not read-only, not idempotent, and not destructive; the description adds no side-effect information such as whether a test is immediately triggered, whether a report is created, or whether the operation is asynchronous. Since annotations are minimal, the description carries the burden and does not satisfy it.

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 that is easy to parse. The phrase 'Process my request' is slightly filler-heavy and could be replaced with a more direct verb, but overall it is appropriately 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?

With an output schema and fully documented parameters, the description supplies the core purpose and the key condition of no existing report. However, it does not clarify when to choose this over requestRetest or requestFeature, nor what side effects the 'processing' entails, leaving notable gaps.

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 all three parameters are already documented with types and length constraints. The description adds only the contextual hint that the page should lack a report, which is enough given the schema already explains each parameter.

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 indicates the tool handles requests to test a page that has no report yet, which distinguishes it from sibling requestRetest. However, 'Process my request' is somewhat indirect and does not explicitly state whether it creates a task, queues a test, or produces a report.

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' implies this tool is for untested pages, giving useful contextual guidance. But it does not explicitly name alternatives like requestRetest or mention when not to use this tool, leaving usage boundaries mostly implicit.

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