QuantumScan PQC Scanner

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

With no annotations, the description carries the burden for behavioral disclosure. It usefully reveals that the check is 'no DB, no scan' (non-persistent, lightweight) and gives rate limits (100/day free, 500/day paid). However, it does not clarify the return format (e.g., boolean vs per-algorithm results) or error handling, leaving some behavioral ambiguity.

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 efficiently convey the core function, speed, use case, and rate limits. Every clause adds value: 'No DB, no scan' sets lightweight expectations, 'before calling scan_repository' gives context, and rate limits are critical for planning. No wasted words.

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 one-parameter tool with no output schema, the description covers the essential context: what it does, when to use it, and operational constraints. It misses describing the exact return structure, which would be nice but is not critical given the tool's simplicity. Overall, it is complete enough for effective use.

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 schema already provides comprehensive documentation for the single parameter with examples (e.g., ["ECDSA", "RSA-2048"]), covering 100% of the schema. The description merely repeats 'list of algorithm names' without adding new semantic detail, so it meets the baseline but does not elevate above it.

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 tool checks whether algorithm names are quantum-vulnerable, using a specific verb ('returns whether') and resource ('list of algorithm names'). It distinguishes itself from sibling tools by explicitly positioning it as a quick pre-check before scan_repository, and notes it is 'Instant check' with no DB/scan.

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?

Provides clear usage context: 'Useful for quick risk assessment before calling scan_repository.' This gives an explicit when-to-use and implies the alternative (scan_repository). However, it does not specify when not to use the tool or compare it to other siblings like scan_contract, so it lacks full exclusion 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?

The description discloses return statuses (submitted, working, completed, failed), CBOM compliance standard, quantum risk score range, and rate limit, which is comprehensive behavioral detail. Since no annotations are provided, the description fully carries the transparency burden and meets it admirably.

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 the primary action in the opening clause; no redundant information. The description is concise and 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?

The description fully explains what the tool returns and any constraints (rate limit), compensating for the lack of output schema. For a simple retrieval tool, this is 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 schema already covers scan_id with a description referencing scan_repository, so the description adds no new parameter details. With 100% schema coverage, 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 clearly states 'Get the result of a previously submitted scan', specifying the action (get) and resource (scan result). It distinguishes from sibling tools by focusing on retrieval rather than submission or direct risk checking.

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 indicates this is for retrieving results of a previously submitted scan, implying use after scan_repository. It doesn't explicitly name alternatives or exclusion criteria, but the context is clear enough.

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 provided, the description fully carries the burden and delivers: synchronous behavior ('result is immediate (no polling needed)'), prerequisite verification on Sourcify, return payload breakdown (risk score, agent risk score, findings, PQC steps), and rate-limit details. This is rich, actionable behavioral information beyond any structured field.

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?

Four sentences, each with a distinct purpose: core scan targets, usage timing, sync behavior + prerequisite, return values + rate limit. Front-loaded with the action, no wasted words. The paragraph format is acceptable given the density of necessary context.

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?

Despite no output schema, the description covers what, when, prerequisites, behavior, return fields, and limits. It also implicitly distinguishes from get_scan_result by stating no polling needed. For a two-parameter tool with no annotations, this is comprehensively specified.

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% for both parameters, so the baseline is 3. The description adds the Sourcify verification prerequisite, which gives context to contract_address, but it does not add syntax or format details beyond what the schema already provides. It marginally enhances parameter understanding but doesn't compensate significantly 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 opens with a specific verb+resource: 'Scan a verified on-chain smart contract' and enumerates distinct detection targets (quantum-vulnerable cryptography, rug pulls, honeypots, etc.), which clearly differentiates it from sibling tools like check_pqc_risk (likely narrow PQC-focused) and scan_repository (repository scan).

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 states when to use: 'BEFORE signing a transaction, interacting with a DeFi protocol, or integrating a contract into an agent workflow.' It also gives a precondition (verified on Sourcify) but does not explicitly name alternative tools or when-not-to-use, so it lacks the explicit exclusion part that would merit 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?

With no annotations provided, the description carries the full burden. It discloses the return value (scan_id), the asynchronous polling behavior via get_scan_result, and rate limits (10 scans/day per IP) plus paid tier registration. This is substantial behavioral information, though it does not mention error handling or auth token requirements.

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 concise sentences, front-loaded with the core purpose, followed by return value, follow-up instruction, and rate-limit info. Every sentence adds value with no redundant wording.

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 with only one parameter and no output schema, the description covers the key aspects: what it does, what it returns, how to obtain the result, and usage limits. It is complete for the tool's complexity.

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 schema already provides 100% coverage for the single parameter repo_url, including an example. The description adds no additional parameter-specific semantics, so a baseline score of 3 is appropriate per the rubric.

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 tool's purpose: submitting a GitHub, GitLab, or Bitbucket repository for PQC vulnerability scanning. It uses a specific verb ('Submit') and resource ('repository'), and distinguishes from sibling tools by targeting repositories specifically, while get_scan_result is mentioned as a follow-up.

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 explicit guidance to call get_scan_result to poll for the result, which clarifies a common usage pattern. It also gives context on free and paid tiers, implying when to use the tool. However, it does not explicitly contrast with scan_contract or check_pqc_risk, so it's not a full when-to-use vs alternatives.

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