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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds a meaningful non-obvious behavioral fact: quota resets per calendar month and does not roll over. This extra context helps agents avoid misinterpreting stale quota values, which is more than the annotations alone provide.

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 concise sentences: the first states what the tool returns, the second gives actionable usage guidance and a key rule. No redundant words; every part earns its place.

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 status tool without an output schema, the description is complete: it explains the data returned, the timing caveat, and when to invoke it. Nothing an agent needs to correctly select and call this tool 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 and the input schema is complete, so the description has no need to explain parameters. Baseline of 4 is appropriate given the absence of parameters.

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?

Description clearly states the resource (account usage and quota) and the specific information returned: scans left, plan, and allowed categories. This distinguishes it from siblings like get_scan_report or list_scans by focusing on account-level quota rather than individual scans.

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 tells the agent to check this before bulk scan operations, providing a clear triggering condition. It does not name alternative tools for exclusions, but the context makes the tool's role as a pre-flight check 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 already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context beyond annotations: the tool does not spend quota on re-reads, and it returns full findings including executive summary and per-category results. This goes beyond what annotations alone communicate, though it does not describe the exact output shape.

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 filler. The first sentence states what the tool does and what is included; the second gives clear usage context. Key information is front-loaded and every sentence earns its place.

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 no output schema, the description is complete enough: it identifies the input (scan id), the returned content (full findings, executive summary, per-category results), and the relevant use cases. No critical operational context is missing for an agent to 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 description coverage is 100%, so the parameters scan_id and lang are already fully documented in the schema. The description adds no additional parameter-level meaning beyond referring to 'a scan by id'. With full schema coverage, 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 uses a specific verb ('Fetch') and a clear resource ('full findings for a scan by id'), and further specifies the contents as 'the executive summary and per-category results.' This clearly differentiates the tool from siblings like list_scans and get_scan_trends, which serve different reporting or listing purposes.

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 explicitly states when to use the tool: 'to collect a scan that run_scan left running' or 'to re-read an earlier scan without spending quota.' This names the originating sibling (run_scan), provides a concrete trigger condition, and explains the advantage over re-running a scan.

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 provide readOnlyHint=true and openWorldHint=true. The description adds the behavioral nuance that the tool returns nothing useful for a site scanned only once and that it surfaces trends, which goes beyond the annotations. However, it does not describe return shape, pagination, or any other noteworthy runtime 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?

Two sentences, highly efficient. The first sentence states the purpose, the second adds a crucial edge-case warning. There is no filler or repetition, and the main concept 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?

Given the simplicity of the tool (zero params, no output schema), the description gives enough for an agent to understand its purpose, expected data, and pitfall. It does not describe the exact output format, but the absence of an output schema and a straightforward read-only function makes that a minor 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 tool takes zero parameters and the schema is empty, so the description does not need to explain parameter meaning. The baseline of 4 for no parameters applies, and the description's focus on behavior aligns with the empty input 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 this tool returns score history per URL across repeated scans and indicates trend direction. It differentiates from siblings like get_scan_report through the 'repeated scans' framing, but it does not explicitly name or contrast any alternative tool.

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 use case is clear: use this when you need to see whether a site is improving or regressing across multiple scans. It also gives a when-not case ('site scanned only once'), but it does not explicitly mention sibling tools that should be used instead, such as get_scan_report or list_scans, so usage guidance is strong but not fully explicit.

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 mark the tool read-only, and the description adds meaningful behavioral context: results are plan-dependentchers, and run_scan refuses rather than skips unavailable categories. This goes beyond the annotations without contradicting them.

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, both information-dense. The first states the purpose, the second gives a precise usage directive. No redundancy 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 parameterless listing tool, the description completely covers what it returns (categories and plan inclusions), why to use it, and its relationship to run_scan. Nothing essential 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 input schema has zero parameters, so there is nothing for the description to add about parameters. The baseline of 4 fits because no parameter documentation is required, and the description still clarifies what the list contains.

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 resource ('analysis categories SyteCan can run') and adds plan-specific scope ('which of them this account's plan includes'). It reads as an explicit listing tool and is distinguishable from run_scan, which is about executing scans.

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 instructs the agent to check this tool before calling run_scan推理 and warns that requesting a withheld category is refused outright. This gives a clear decision rule for when to invoke the tool.

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 mark the operation as read-only, and the description adds useful behavioral context: account scoping, reverse chronological ordering, and the practical implication that the data can be consulted before launching a new scan. No contradiction exists.

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 tightly written sentences: the first states exactly what the tool does, and the second gives concrete use cases. No filler or repetition of schema details.

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 list operation, the description conveys scope, ordering, and typical usage. It does not describe the exact return fields or pagination behavior, but the schema explains filters and pagination, and 'find a scan id' implies the relevant output.

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 documents all four parameters with descriptions, constraints, and an enum, so the description needs to add little. The description does not expand on parameter behavior, but schema coverage is 100%, so a 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?

States a specific verb ('List'), a resource ('this account's scans'), and a behavior ('newest first'). The use cases 'find a scan id' and 'check whether a site has been scanned' clearly distinguish it from sibling tools like run_scan and get_scan_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?

Clearly tells the agent when to use this tool: to locate a scan id or avoid duplicate scans before starting a new one. It does not explicitly contrast with siblings such as get_scan_report, but the intended use cases are concrete and actionable.

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 that the tool is not read-only and not idempotent. The description adds crucial behavioral details: each scan consumes a monthly quota and incurs real cost, free accounts have three scans per month, scans take a few minutes, and the tool may return a scan id for an in-progress scan. This goes well beyond the annotations and is essential for correct agent 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?

Although the description is long, every sentence serves a purpose: the core action, the ten dimensions, the quota warning, the confirmation guidance, and the async fallback. It is front-loaded with the action and the most critical limitation (cost), and the structure flows logically from invocation to follow-up. There is no irrelevant 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 tool that creates a scan (a side effect with cost) and has no output schema, the description covers all critical context: what it does, what it costs, how long it takes, how to handle an async result by passing the scan id to get_scan_report, and how to avoid wasteful duplicates. Everything an agent needs to call it correctly and responsibly 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?

The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds little extra meaning: it mentions that categories are optional, that omitting them uses the plan's default, and that list_categories can be used to see available categories—but these are largely restatements of the schema descriptions. No new semantic nuance is provided that isn't already in 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 opens with a concrete verb and resource: 'Submit a URL to SyteCheck and wait for the report.' It enumerates the ten dimensions scanned, which are specific and informative. This clearly distinguishes it from sibling tools like get_scan_report, which retrieves an existing report, and list_scans, which lists previous scans.

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 explicit when-to-use guidance: it instructs the agent to check get_account_usage when quota is uncertain, and to confirm with the user before re-scanning the same URL. It also tells the agent to use get_scan_report if the scan is still running, rather than re-scanning. This directly points to alternatives and defines the conditions that trigger them.

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