Prescan

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the no-cost trait ('Free.') and by naming the content payload — pricing, endpoints, docs — which tells the agent why the call is worth making. It stops short of describing the response 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?

A single sentence with the key qualifier 'Free.' front-loaded, and the content list follows immediately. Every clause carries information, though the sentence is compressed to the point of being slightly telegraphic.

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?

There is no output schema, so the description is the only source of information about the return value, and it says only that there are 'links to docs' and prices without indicating format or structure. For a zero-parameter info tool this is close to sufficient, but the agent cannot predict what it will actually receive back.

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 an empty object at 100% coverage with no enums or nesting, so there is nothing for the description to clarify. Baseline 4 applies to zero-parameter tools; no parameter gaps exist.

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 enumerates exactly what the tool returns: what Prescan does, prices of paid tools, HTTP endpoints, and doc links. Combined with the name 'about' and title 'About Prescan (free)', the intent is unmistakable. It lacks an explicit verb, which keeps it from a 5, but it is clearly distinguishable from the action-oriented 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?

The leading 'Free.' implies this is the zero-cost discovery call an agent should make before touching paid tools like scan_text or check_x402_endpoint, but that routing is never stated. There are no explicit when-to-use or when-not-to-use instructions, so the agent must infer the sequencing.

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 readOnly/idempotent/non-destructive, and the description adds material context beyond them: the $0.003 USDC per-call cost charged only on success, the single-GET no-payment guarantee, the go/caution/no_go verdict vocabulary, and what a caller without a wallet receives. That is precisely the pricing, side-effect, and output-shape information an agent cannot infer from 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 framing question and the no-payment/cost guarantees are front-loaded, and the checklist is compressed into one dense clause. The enumeration of checks is long but every item is a distinct signal an agent would want before paying; only slight tightening is possible.

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?

There is no output schema, and the description compensates by naming the verdict values, the recommended payment option, and the findings it returns. Combined with the cost model and the no-wallet fallback, an agent has everything needed to decide whether and how to call it.

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 the baseline is 3; the description earns one more by tying max_usd to a concrete outcome ("amount vs your budget", above budget = no_go) and by framing url as the endpoint about to be paid. It adds relationship semantics rather than merely restating field descriptions.

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?

Opens with a specific question the tool answers ("Is this x402 endpoint safe to pay?") and then enumerates exactly what it inspects (payTo checksum, OFAC, canonical USDC, budget, price cross-checks against OpenAPI/x402scan, HTTPS, RDAP domain age). The resource and operation are unambiguous, and no sibling (about, list_rules, scan_text, scan_tools) overlaps with it.

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 clearly implied and reinforced: call it before paying an x402 endpoint, and it explicitly states "never pays" and only sends one GET. It also covers the fallback case ("Without an x402 wallet you get the payment terms and the paid HTTP URL instead"). It does not name a sibling alternative, but the siblings are unrelated utilities, so no routing ambiguity exists.

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, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds the cost signal ('Free') and scope of returned content, but says nothing about output size, whether the ruleset is static, or versioning.

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 the cost qualifier and the subject front-loaded and no filler. The telegraphic fragment style ('The detection categories, rule counts and thresholds used by...') is slightly clipped but every phrase carries 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?

For a zero-parameter, read-only reference tool with no output schema, the description adequately conveys what an agent gets back: categories, rule counts and thresholds. Only minor gaps remain, such as whether the ruleset changes over time.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. The description does not introduce any input semantics that conflict 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?

Names the resource precisely (detection categories, rule counts, thresholds) and ties it to the sibling tools that consume it, so an agent can tell it apart from scan_text and scan_tools. It reads as a noun phrase rather than an explicit verb+resource, which keeps it just 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?

'Free.' signals a cost distinction versus paid siblings and the reference to scan_text/scan_tools implies this is supporting documentation rather than a scanning action. However, it never states when to call it (e.g., before scanning to understand what will be detected) or any when-not condition.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds value beyond that by disclosing the free/paid tiering and what the response contains (verdict, score, categories, rule ids), which is important since no output schema 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 sentences with zero filler; the key constraint ('Free', 1000-character cap) and the paid alternative are both front-loaded. Every clause carries information an agent needs.

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 usefully enumerates the return fields, and it clarifies the free-tier limit and the escalation path. It does not describe error behavior or what 'suspicious' vs 'malicious' implies for follow-up action, but nothing critical for correct invocation 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?

Schema description coverage is 100%, including enum values for source and the 1000-character maxLength, so the schema does the heavy lifting. The description restates the character limit but adds no semantics for the source parameter beyond what the schema's own description already explains.

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 (prompt-injection pre-check), the input limit (1000 characters), and the return shape (verdict, score, categories, rule ids). It also names the sibling scan_text and the boundary between them, so an agent can tell the two apart without inspecting schemas.

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 routes long texts, batches, spans, and sanitized copies to scan_text (paid), making the free-tier boundary concrete. Both the when-to-use and when-to-use-something-else conditions are 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 cover read-only/idempotent/non-destructive, and the description still adds substantial behavioral context beyond them: deterministic rules with no LLM, batch ceiling of 100 texts, cost of $0.002 USDC per call charged only on success, and what happens without an x402 wallet. It also discloses the full return payload (verdict, action, score, findings with spans, decoded payloads, sanitized copy), which is a lot of load-bearing detail for a no-output-schema 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?

The lead clause front-loads the purpose and the use context, and the remaining length is spent on concrete detection categories rather than filler. The long enumeration of threat classes is dense but each item carries information; it could be broken into a list for readability but nothing is genuinely wasteful.

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 takes on responsibility for describing returns, and it does so thoroughly — verdict values, action values, score range, findings with character spans, risky links, decoded payloads, sanitized copy. Combined with the pricing and wallet fallback behavior, an agent has everything needed to decide whether to call and how to interpret the result.

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 `text`, `items`, `source`, and `sanitize` are all already documented, and the enum tuning note lives in the schema itself. The description adds only the batch ceiling ('up to 100 texts per call'), which is already in the schema as maxItems, so it stays at the baseline 3 rather than earning more.

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 precise verb and resource (scan text for prompt injection) and enumerates the exact threat classes covered, so an agent knows exactly what the tool does. It does not explicitly contrast itself with the sibling `preview_scan_text`, so the only thing separating free preview from this paid call is the cost sentence, which requires inference.

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 a clear trigger condition — text your agent is about to read — with concrete examples (tool output, web page, email, document, token metadata). It never names an alternative tool such as `preview_scan_text` or `list_rules`, and offers no when-not-to-use guidance, so the alternative-selection half of the dimension is missing.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: it discloses price ($0.002 USDC per call via x402, charged only on success) and the exact fallback behavior when no wallet is present (payment terms plus paid HTTP URL returned instead of a scan). It also describes what the response contains (per-tool verdict, findings with location, capability flags).

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?

Purpose is front-loaded in the first clause, followed by the threat taxonomy and then pricing/fallback. The threat enumeration is long but each item contributes concrete signal about what is detected; a slightly tighter list would still convey the same coverage.

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 paid, open-world scan tool with no output schema, the description supplies everything an agent needs: what is analyzed, what is returned, what it costs, and what happens without a payment wallet. Nothing material about invocation or outcome is left to guesswork.

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 nested tools/server structure is documented in the schema itself, so the description does not need to restate it. It adds no format guidance beyond the schema (e.g., it never mentions the 200-tool cap or that server is an echoed label), so this sits at the baseline for a fully documented 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?

A specific verb and resource — a poison scan over MCP tool definitions / function schemas — plus an explicit scope ('before your agent connects or calls them'). It naturally reads as distinct from text-oriented siblings like scan_text and preview_scan_text because the input is declared to be a tools/list result or function schema set.

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 a clear timing condition ('before your agent connects or calls them'), which is exactly the decision point an agent needs. It does not explicitly name when to prefer scan_text or preview_scan_text instead, so the routing to siblings is left implicit rather than stated.

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