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

With no annotations provided, the description carries the burden of explaining behavior. It describes the two modes (pull a class page or search) and the default behavior of listing pages with no args. It's clearly a read-only lookup, and the description adds context beyond the schema.

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 efficient and front-loaded with the main purpose. The args list is well-structured and every sentence provides useful information. Slightly longer than necessary but still appropriately sized for the amount of guidance offered.

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 tool's simplicity and the presence of an output schema, the description covers the essential context: when to use it, what parameters mean, and what to do when uncertain. It doesn't need to explain return values because the output schema exists. Slightly more detail on the type of content in the arsenal could push it to a 5.

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 0%, but the description fully compensates. It enumerates valid values for vuln_class, notes aliases, explains query as free-text search, and clarifies the behavior when neither parameter is provided. This goes well beyond the bare 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 it's a bypass/technique reference to consult when a hunt is blocked, with a specific verb 'Consult' and a named resource 'Novelty's arsenal'. It distinguishes itself from sibling tools by being a knowledge-base lookup rather than an active scan or request 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?

Provides explicit usage context ('when a hunt is blocked by a control') and offers conditional guidance ('if you don't know the class' use query, 'call with neither' to list pages). Lacks explicit mention of alternatives or when not to use, so not a full 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?

No annotations are provided, so the description must carry behavioral context. It describes the reasoning/combination behavior and gives examples, but does not disclose whether this is read-only, what input constraints apply, or what the returned output contains. The presence of an output schema partially mitigates the missing return-value detail.

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 compact and front-loaded with purpose and examples, followed by a brief parameter clarification. No filler or redundant repetition of schema fields.

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 single-parameter tool with an output schema, the description covers the core purpose and input source. However, it lacks details about the finding object structure and any preconditions or result expectations, making it slightly incomplete for an agent invoking it in unusual contexts.

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 only says 'string' for findings_json, and schema description coverage is 0%. The description adds that it is a JSON array of finding objects from hunt/review/report, but does not specify the shape or required fields of those objects, so parameter semantics remain partially ambiguous.

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 ('Reason') and identifies a clear resource ('findings for exploit CHAINS') with concrete examples of impact escalation. It clearly distinguishes this tool from sibling finding-generation tools like hunt/review by focusing on chaining existing findings.

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 that input should come from hunt/review/report, strongly implying the right context for use. It does not explicitly name alternatives or exclusions, but the source hint provides sufficient 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?

With no annotations provided, the description carries the behavioral transparency burden. It states the tool reports status (which reasoning model and tools are available), implying a non-mutating read operation. However, it does not explicitly state that it is read-only, lacks side effects, or mention any authentication or failure conditions. This is adequate for a simple status tool but lacks explicit reassurance.

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 that immediately states the action ('Show') and the subject ('Novelty MCP status'), then expands with two specific details. 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 zero-parameter health check tool, the description is sufficient: it states what the tool reports and the context (status check). An output schema exists, so return values need not be described. It does not cover edge cases like failure responses, but for a health tool this is acceptable.

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 coverage is trivially 100%. The description adds no parameter-specific semantics, but none are needed. Baseline for 0 parameters is 4.

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 the specific verb 'Show' and clearly identifies the resource: 'Novelty MCP status'. It further specifies the exact contents of that status (which reasoning model is wired in and the tools available), which clearly distinguishes it from sibling tools like recon or review_file.

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 usage for checking the health/configuration of the Novelty MCP server, but it does not explicitly compare to alternatives or state when not to use it. Given the sibling tools, no other tool serves a status-query purpose, so the usage context is clear but not explicitly 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?

No annotations are provided, so the description carries the burden. It discloses the output nature (headers and body) and implies a read-only operation by saying 'Show', but it does not mention what happens if the request_id is invalid or whether any side effects occur. For a read tool this is acceptable but minimal, so a 3 is appropriate.

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 conveys the action, target, and content without extraneous words. Every word 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?

The tool is simple with one parameter and an output schema, so the description covers the essential behavior. It omits how to obtain request_id, but given the sibling http_history and the low complexity, the context is sufficiently complete. An explicit pointer to http_history would raise it to a 5.

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 has only one parameter, request_id, with 0% description coverage. The description adds meaning by saying 'one logged entry', which clarifies that request_id refers to a logged entry ID. However, it does not explain how to find that ID or provide format details, so it only partially compensates for the lack of 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 a specific action ('Show') on a specific resource ('one logged entry') and specifies the content ('full request and response (headers + body)'). This differentiates it from siblings like http_history (list) and http_send (send), making the tool's purpose unambiguous.

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 logged entry' provides clear context that this tool is for inspecting a specific entry from a logged session, implying it should be used after http_history. It does not explicitly name alternatives or exclusions, but the scope is clear enough for an agent to select it over siblings.

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, the description carries the full burden. 'List' implies a read-only operation with no side effects, but the description doesn't elaborate on any nuances like pagination, date ranges, or persistence. It is adequate but minimal, lacking extra context beyond the obvious.

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, well-structured sentence that immediately conveys the tool's purpose. There is no redundancy or filler. Every word 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 listing tool with an output schema, the description is largely complete. It states the core functionality and the scope ('HTTP history'). The only gap is the undocumented 'limit' parameter, but its purpose is reasonably inferable from the schema. Overall, it gives the agent enough to use the tool 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 0% and the description does not mention the 'limit' parameter at all. The agent is left to infer its meaning solely from the parameter name and default value in the schema. The description adds no value 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 clear verb ('List') and specific resource ('recently logged requests'), and adds context with 'HTTP history / Logger view'. This distinguishes it from sibling tools like http_send or http_get, which perform actions rather than listing history.

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 when to use it (when the user wants to see recent HTTP requests), but it does not explicitly state alternatives or exclusions. For instance, it doesn't say 'use http_send to send a request instead'. The context is clear enough for basic inference, 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?

With no annotations provided, the description takes on the full burden of behavioral disclosure. It clearly states that blank arguments preserve original values, supplied headers are merged, and a new history entry is logged. These are concrete side effects and merge semantics beyond what the schema reveals.

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 two sentences plus a parenthetical. It is front-loaded with the core purpose, followed by essential behavioral notes. Every sentence earns its place, with no redundant 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 replay tool with 5 parameters and no annotations, the description covers the primary workflow: select a logged request, optionally modify fields, and understand that it logs a new entry. It does not mention return format or error handling, but an output schema exists, lowering the burden. Overall, it is appropriately 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 input schema has 0% description coverage, so the description must add meaning. It does: 'Any argument left blank keeps the original request's value' explains the role of optional parameters, and 'Supplied headers are merged onto the original' clarifies headers_json behavior. It doesn't explicitly describe each parameter individually, but the blanket rule compensates well for the schema gap.

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 'Re-send a logged request with optional edits', which gives a specific verb and resource. The parenthetical 'Repeater tweak-and-resend' further distinguishes it from net-new send tools like http_send. This clearly conveys what the tool does.

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 establishes that this tool operates on a previously logged request (via request_id), implying it is for replay/modification rather than fresh requests. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to choose between this and sibling tools like http_send.

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 that requests are logged and returns the logged entry id, status, timing, and response preview. However, it does not mention potential side effects of sending requests (e.g., modifying target state), rate limits, or error behavior, which are important for a tool that makes network requests.

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 well-structured with an Args section and a Returns section, front-loading the core function. Each parameter gets a concise line. It is slightly longer than strictly necessary but earns its place by covering all parameters and return values.

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 tool's complexity (sending arbitrary HTTP requests) and the presence of an output schema, the description covers the key aspects: parameters, return values, and an authorization guard. It could mention error handling or response size limits, but it is sufficiently complete for an AI agent to understand and invoke the tool.

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 0%, so the description must compensate. It explains method with examples, url with a clear 'full target URL' and authorization caveat, headers_json as an optional JSON object, and body as optional for POST/PUT. This adds significant meaning beyond the bare schema definitions.

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 sends an HTTP(S) request and logs it to history, with a Burp Repeater + Logger analogy that distinguishes it from siblings like http_get (likely a simple GET) and http_replay (replaying logged requests).

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 context for when to use it (custom requests with logging) via the Burp analogy and includes an authorization note ('a target you're authorized to test'). It does not explicitly state when not to use it or name alternative tools, 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, the description fully carries the transparency burden. It explicitly states non-destructive, authorized targets, the sequence (recon then hunt), the scope of vulnerability classes, and the return value structure. This goes beyond what is minimally required.

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 tight sentences, front-loaded with the core action, and every sentence adds functional value (what it does, safety, return format). 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?

The description covers purpose, workflow, safety, target authorization, vulnerability classes, and return contents. Given an output schema exists, it needn't detail the return schema further, but it omits any guidance on URL input and prerequisites, leaving 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 single required parameter 'url' has no schema description (0% coverage) and is not mentioned in the tool description. The description does not explain what URL format is expected or any constraints, leaving the agent to infer the meaning solely from the parameter name 'url'.

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 ('Run') and names the resource ('recon then an AI vulnerability hunt') with explicit vulnerability classes. It clearly distinguishes from sibling tools like secrets_hunt or param_discover by describing the combined recon-and-hunt workflow.

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 a clear usage context: 'authorized targets only' and 'non-destructive', implying it is safe to use on authorized engagement targets. It does not explicitly mention when not to use it or alternatives, but the context is sufficient.

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?

No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: 'Secrets are never logged,' which is a significant privacy guarantee. The verb 'Read' also indicates read-only behavior. However, it does not mention whether authentication is needed, any side effects, or the return format, though those are less critical for a log-read 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 description is a single sentence that front-loads the core purpose ('Read Novelty's persistent hunt memory'), then adds essential context (milestone types and filter) and a security guarantee. Every word earns its place; 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 simple read-only tool with two optional parameters and an output schema, the description covers the core behavior, content, filtering, and a security note. It could mention the default limit or explicitly state pagination, but these are minor given the tool's simplicity and the presence of an output schema to define return values.

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 has zero description coverage for both parameters. The description explains 'target' via 'optionally filtered to a target,' but 'limit' is not explicitly described. The word 'recent' hints at limiting entries, and the default of 20 is visible in the schema, but the description does not add explicit semantic detail for 'limit.' Overall, partial compensation for the schema gap.

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 reads Novelty's persistent hunt memory, with specific verb 'Read' and resource 'persistent hunt memory'. It lists the content categories (recon/hunt/finding/report) and an optional filter, which distinguishes it from sibling tools like hunt or recon that perform actions rather than read logs.

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 'recent milestones' implies this is for reviewing past activity, and the optional target filter suggests use cases like checking history for a specific entity. While it doesn't explicitly name alternatives or exclusions, the context makes it clear this is a read-only retrospective tool versus action-oriented siblings, so usage is implied 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?

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal that this is an active replay/enumeration operation and that it is intentionally bounded to a small payload list. However, it does not explicitly note whether it sends live network requests, what authorization is needed, or any other side effects beyond replaying the request.

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 compact and front-loaded: the main behavior appears in the first sentence, followed by a one-line usage boundary and a concise Args list. Every sentence adds value, and there is no filler or repetition.

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 tool is a focused active-replay operation with three well-documented parameters and an output schema present. The description covers its purpose, scope, parameter semantics, and usage constraints without needing to detail return values. 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?

Schema description coverage is 0%, so the inline Args section is essential. It explains each parameter clearly, adds a practical tip for marker ('put it in the URL/body first'), and provides a concrete example for payloads_json, making the parameters immediately usable.

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 specifies the tool's function: 'Replay a logged request substituting `marker` with each payload' and brands it as 'Intruder-lite'. It includes a concrete use case ('enumeration/IDOR/auth checks') and a boundary ('not stress testing'), distinguishing it from broader or stress-testing 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?

It explicitly states when to use the tool ('for enumeration/IDOR/auth checks') and when not to use it ('not stress testing'). However, it does not name a specific alternative for stress testing or general replay, so the guidance is clear but lacks direct sibling differentiation.

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, the description carries the full burden. It discloses that the tool returns messages and links and that the inbox is a throwaway, which implies non-persistent and read-oriented behavior. However, it doesn't explicitly state whether polling is destructive, whether any authentication is needed, or what happens if the inbox doesn't 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, front-loaded sentence that conveys purpose, usage context, and output in a compact form. Every word adds value, with no 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 simple one-parameter tool with an output schema, the description is nearly complete. It explains the tool's role, ties it to mail_new, and notes the returned links. It falls slightly short only by not explicitly linking the 'address' parameter to the inbox, but otherwise the context is sufficient.

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 has one required parameter 'address' with no description, and schema description coverage is 0%. The description doesn't explicitly define 'address' as the inbox email address, though it can be inferred from 'throwaway inbox created by mail_new()'. Since coverage is 0%, the description should compensate more clearly.

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 verb 'Poll' and the resource 'a throwaway inbox created by mail_new()', distinguishing it from sibling tools like mail_new which creates the inbox. It also specifies the output: messages and links (e.g., verification link).

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 a clear usage context: poll an inbox that was created by mail_new(), likely after signup to retrieve a verification link. It doesn't explicitly exclude alternatives or state when not to use it, but the sibling context and 'created by mail_new()' provide solid 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the inbox is throwaway, external (mail.tm), and that a return address is provided for polling. This is meaningful behavioral context. It does not mention potential limitations like expiry or external service failures, but for a simple creation tool, the key behaviors are adequately 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?

The description is a single well-structured sentence. It front-loads the primary action and includes the most important details without any filler or 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?

This is a simple zero-parameter tool with an output schema. The description covers the purpose, the expected output, and how to use that output. It is complete for the tool's complexity and integrates well with the sibling tool mail_inbox.

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 no parameter documentation is needed. The description adds value by explaining what the tool returns (an address) and how to use that return value, which is more useful than an empty schema alone.

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 ('Create'), names the resource ('throwaway inbox'), specifies the provider (mail.tm), and states the intended use case (registering a test account). It clearly distinguishes this tool from siblings like mail_inbox by explaining what it produces and how the result is used.

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 clearly states when to use the tool: when registering a test account on an app you are authorized to test. It also explains how the returned address should be used (poll with mail_inbox), which provides usage context. It does not explicitly mention when not to use it or list alternatives, but none are needed given the unique purpose.

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, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only,' which is a key safety trait, but it doesn't detail the scanning behavior (e.g., number of requests, whether it executes JavaScript or just parses static content, potential noise on target). This is a moderate gap for a security 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 description is a single sentence, front-loads the main functionality, and uses a dash to clearly state the tool's purpose. No wasted words or 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?

Given that an output schema exists (per context signals), the description needn't explain return values. It covers the core functionality, the read-only nature, and the relationship to subsequent probing tools. It could add more detail on how JavaScript is processed, but the essentials are present for an attacker with basic context.

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 has only one parameter (url) with 0% description coverage, but the description implicitly clarifies it as the target's URL ('a target's HTML + JS'). It doesn't specify format or protocol constraints, but with a single obvious parameter, the description compensates adequately.

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 ('Mine') with a clear resource ('parameters, endpoints, and forms from a target's HTML + JS'), and distinguishes its role from siblings like http_send and intruder by framing the output as the attack surface to probe. It's unambiguous and immediately conveys the tool's function.

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 when to use this tool—before probing with http_send/intruder—by stating it discovers the attack surface. It doesn't explicitly discuss when not to use it or name alternatives, but the connection to sibling tools provides sufficient context for selection.

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, the description carries the full burden. It discloses the 'read-only' nature and specifies the types of checks performed, providing some behavioral context. However, it does not explain whether the tool makes active network requests, potential side effects, rate limits, or how results are structured, which would be valuable for a recon 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 description is a single, well-structured sentence that front-loads the core action ('Read-only recon of a web target') and then lists the specific checks in a compact, comma-separated list. Every word adds value; no filler or 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 tool is reasonably complex (covers many areas), but the description lists all major categories of checks. An output schema is present, so return values need not be described. The description could benefit from mentioning whether the recon is purely passive and any prerequisites, but overall it is sufficiently complete for an agent to grasp the tool's scope.

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 0%, so the description must compensate. It refers to 'a web target,' which implies the required 'url' parameter, and the context is clear given the tool's purpose. However, it does not specify URL format (e.g., https:// required), default behavior, or any additional nuance, so the description only partially compensates.

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 performs 'read-only recon of a web target' and enumerates specific checks (tech stack, headers, forms, script bundles, services, security headers, exposed files). This precisely identifies the tool's function and distinguishes it from sibling tools like http_get or hunt, which target specific HTTP operations.

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 for initial reconnaissance by calling it 'read-only recon' and listing the scope of checks, but it does not explicitly state when to use this tool compared to alternatives or when not to use it. No alternatives are referenced, despite many sibling tools existing.

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 reveals that credentials/tokens would be scrubbed (a security behavior) and implies persistence across sessions. This is valuable beyond the schema, though it does not detail return values or side effects.

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 two sentences: a clear action statement followed by a critical security warning. Every word earns its place, with no unnecessary detail.

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 tool has 3 parameters and an output schema, so return values are covered elsewhere. The description covers purpose and security but leaves parameter meanings unexplained, creating a notable gap in understanding how to properly use the tool.

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 0%, so the description must compensate. It only mentions 'milestone/lead' generically but does not explain the specific roles of 'lead', 'note', or 'target'. The parameter names are self-explanatory to some degree, but no detailed semantics are provided.

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 appends a milestone/lead to Novelty's hunt memory for later sessions, using a specific verb and resource. This distinguishes it from siblings like hunt or hunt_log by emphasizing memory persistence.

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 indicates when to use the tool (to save leads/milestones for later) and includes a warning against storing credentials/tokens, implying when not to use it. However, it does not explicitly name alternative tools for different use cases.

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, the description carries the full burden. It discloses that the tool expects pre-collected findings and that save_html optionally writes a file. This is useful, but it does not explicitly state whether the tool is read-only, what happens if save_html is empty (e.g., returns HTML string), or any side effects beyond file writing. The description is moderately transparent but lacks depth.

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 concise and well-structured. A single opening sentence states the purpose and input sources, followed by a clear Args block that maps each parameter to its meaning. Every sentence earns its place, and the information is easy to scan.

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 covers all input parameters and gives a clear picture of the tool's behavior. An output schema exists, so return values are handled. The main gap is that it does not address the relationship with sibling tools report_web and report_source, which could confuse an agent about which tool to choose. Otherwise, the description is complete for a report-generation tool.

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 description provides detailed semantics for each parameter, far exceeding the schema. It explains findings_json as a JSON array with a specific shape (title, severity, vuln_class, etc.), target as the assessed target's name/URL, kind as 'web' or 'source', and save_html as an optional path. This is essential because schema description coverage is 0%, and the description fully compensates.

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: 'Render a report from findings you have ALREADY collected.' It names specific verbs ('Render') and resources ('report') and provides context about the input (findings_json). However, it does not explicitly differentiate this tool from the sibling tools report_web and report_source, which likely serve specialized versions of the same purpose.

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 usage context: it should be used after findings have been collected, e.g., from 'hunt/review' or 'http_send/intruder.' This gives a clear when-to-use signal. However, it does not mention any exclusions or alternatives, such as when to use report_web or report_source instead. The guidance is implied rather than explicit, so it falls short of a 4.

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 must fully disclose behavior. It does mention the optional save_html side effect, but it does not state whether the source file is modified, any permission requirements, or other operational constraints. The core security-review behavior is only implicit.

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 concise and well-structured, opening with the main purpose and then listing parameters in a clear format. Every sentence serves a purpose 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?

For a simple two-parameter tool with an output schema, the description covers the essential invocation details: purpose and argument meanings. It lacks usage context, but the availability of an output schema reduces the need to explain return values, making it sufficiently 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?

Schema descriptions cover 0% of parameters, but the description compensates thoroughly by defining path as 'local source file to review' and save_html as 'optional path for the styled HTML report.' This adds meaningful semantics beyond the bare 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 the tool's function: 'Security-review a source file and produce a polished report (Markdown + optional HTML).' It identifies a specific verb and resource, but does not explicitly distinguish from sibling tools like review_file or report, so it falls short of a perfect 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?

There is no guidance on when to use report_source versus other tools such as review_file, review_code, or report. No alternatives or exclusion criteria are mentioned, leaving the agent without context for tool selection.

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 burden and does well by disclosing 'Authorized, non-destructive; authorized targets only' and noting the optional file-writing side effect for HTML reports. It adds useful safety context but could have detailed authentication or rate-limit considerations.

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 well-structured with a clear summary, workflow, safety note, and an Args section. Each sentence contributes value, though it is slightly lengthy; it remains efficient and easy to parse.

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 existence of an output schema, the description correctly avoids re-explaining return values. It covers the overall workflow, output format, and safety constraints. It could mention more about the 'AI hunt' but is sufficient for the agent to decide when to invoke.

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 0%, but the description compensates by explaining 'url' as the target and 'save_html' as an optional path for the styled HTML report with an example. This adds meaningful semantics beyond the raw schema fields.

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 'Hunt' with a clear resource 'web target' and states the precise output as a 'polished security-assessment report'. It distinguishes itself from siblings like report_source or hunt by explicitly stating it combines recon + hunt into a report workflow.

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 clearly implies usage for web target security assessments and describes the internal workflow (recon + AI hunt + report). However, it does not explicitly state when not to use this tool or list alternative tools for different scenarios, such as report_source or recon alone.

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 present, the description carries the full burden. It reveals method (Claude, whole-file reasoning, not regex), which is a non-obvious approach, and the output shape (line-referenced findings with exploit + fix). It does not mention whether it's read-only or any side effects, but for a security review that's arguably implicit.

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?

Three concise sentences pack in purpose, usage, output, and a distinguishing trait. There is zero wasted wording and the key info 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 tool's moderate complexity, the description covers purpose, method, output, and usage context. It also references line-referenced findings, which aligns with likely output schema. It could mention prerequisites or size limits, but the presence of an output schema reduces the need to explain return 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 coverage is 0%, so the description must compensate. It clearly explains the 'code' parameter as 'the file text you have open', but says nothing about the 'filename' parameter or its default. Partial coverage is provided, but one of two parameters remains undocumented.

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 function: security-reviewing a source file's contents with Claude, listing specific vulnerability categories (BOLA/BFLA/XSS/SQLi/business-logic/RCE/auth). It distinguishes itself from sibling tools by emphasizing whole-file reasoning over regex and specifying the output format (line-referenced findings with exploit + fix).

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 context on when to use: 'Pass the file text you have open' implies using the tool with an open file and describes the returned findings. However, it does not explicitly mention alternative tools (e.g., review_file) or state when not to use it, so it lacks explicit 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?

No annotations are provided, so the description carries the full burden. It discloses that the tool reads from a local path, but it does not mention any side effects, permissions, return format, or error behavior. For a tool with no annotations, this is minimal disclosure.

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, concise sentence with no filler. Every word contributes to the meaning, and it is appropriately short for a tool that leverages review_code's description.

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?

Even though an output schema exists, the description is extremely minimal. It does not explain what kind of review is performed, what the output looks like, or any prerequisites. Compared to the complexity of a file review tool, this description lacks sufficient context.

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 has one 'path' parameter with 0% description coverage. The description adds that the path is a 'local path,' which gives some meaning beyond the raw schema, but it does not explain expected format, required nature, or semantics. It provides marginal compensation for the low 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 specifies the action 'review' and the resource 'file', and distinguishes itself from the sibling tool review_code by noting it reads from a local path first. This clearly conveys what it does, though it relies on the reader knowing what review_code does.

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?

By saying 'Same as review_code, but reads the file from a local path first,' it implies this tool is for reviewing code from a local file, while review_code likely handles code passed directly. However, it does not explicitly state when to use this over alternatives or mention any 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?

No annotations are provided, but the description discloses side effects (tools refuse out-of-scope hosts), wildcard behavior, and input format. It doesn't mention overwrite/persistence details, but the core state-changing behavior is clearly stated.

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?

Three compact segments: purpose, enforcement effect, and parameter format. No filler, front-loaded, and each 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 single-parameter setter with an output schema present, the description covers purpose, input format, and behavioral effect on related tools. Missing details are minor and easily inferred from the output schema or sibling tools.

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 only says hosts_json is a string with 0% description coverage; the description compensates by specifying JSON array or comma list, showing wildcard support, and giving a concrete example. This fully conveys parameter semantics 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?

Description opens with a specific verb+resource ('Set the authorized testing scope — an allowlist of hosts'), clearly distinguishing it from sibling scope_show and explaining its effect on traffic 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?

It explicitly names the traffic tools (http_send, recon, hunt, secrets_hunt, param_discover) that will enforce the scope, telling the agent when this tool matters. It doesn't give 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 carries the full burden of behavioral disclosure. It implies a read-only action via 'Show' and adds an important behavioral nuance: an empty scope indicates it is not enforced. While it does not explicitly state 'no side effects' or discuss permissions, the tool's simplicity and zero-parameter design make this sufficient for a clear behavioral profile.

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 a useful parenthetical clarification. Every word earns its place, and there is no redundancy or unnecessary detail.

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 tool's simplicity (zero params, read-only nature), the description is complete. It clearly explains what the tool shows and interprets an edge case (empty = not enforced). The output schema is present, so return values are documented separately, and the description does not need to cover them.

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 baseline for parameter semantics is 4. The schema is trivially complete (100% coverage) and there is no parameter-specific information expected or needed in the description.

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 function with a specific verb+resource ('Show the current authorized scope') and adds a clarifying note about empty output meaning 'not enforced'. This distinguishes it from sibling scope_set, which is about modifying scope.

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 clear context that the tool is used to display the current authorized scope, making it obvious when an agent would invoke it. However, it does not explicitly mention alternatives (e.g., scope_set for changing scope) or provide explicit exclusion criteria, so it falls short of 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly discloses 'Read-only, non-destructive' and describes the action of pulling page and JS bundles, which indicates network fetching. However, it does not detail potential side effects like rate limiting, nor the output structure, though an 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?

The description is a single, information-dense sentence. It front-loads the main action, lists secret types, and includes safety information. Every word earns its place with 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?

The tool is relatively simple: one parameter, no annotations, but an output schema exists. The description covers the operational behavior (pulling and scanning) and safety (read-only, non-destructive). It lacks explicit usage alternatives, but for the tool's core function, the description is sufficiently complete given the output schema covers return 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?

The schema has one required parameter (`url`) with 0% description coverage, so the description must compensate. The description says 'Pull a target's page' which implies the URL parameter, but it does not explain the URL format, whether full URL is required, or any constraints. This adds little meaning beyond the schema's bare type and name.

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 function: it pulls a target's page and JS bundles and flags leaked secrets. It lists specific secret types (cloud keys, tokens, JWTs, private keys, provider keys), making the purpose unambiguous. It distinguishes from generic siblings like `hunt` and `http_get` by focusing on secret scanning from page and JS bundles.

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 use case (finding leaked secrets in a target's page or JS bundles) but does not explicitly state when to use it over alternatives like `hunt` or `http_get`, nor does it mention any exclusions or when not to use it. This is implied usage, not explicit 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?

Without annotations, the description carries the full behavioral burden. It discloses the return payload (verdict, dup-likelihood, adjusted severity, and SAFE negative control) and indicates the control is to be run by the caller, not the tool itself. It does not explicitly state read-only status, but the wording strongly implies analysis-only 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 plus an Args line cover purpose, return values, and parameter semantics without redundancy. The most important information is front-loaded, and every word 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?

Given the simplicity (one param) and presence of an output schema, the description is complete for an agent to select and invoke the tool. It states what the tool does, what it returns, and what the input should be, with no unresolved 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 0%, so the description must compensate. It fully describes the only parameter 'finding_json' as 'a single finding object as JSON', providing both format and meaning beyond the schema's bare string type. This is exactly what the agent needs.

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 'triage' targeting 'ONE finding' and clarifies the evaluation criteria (real, exploitable, non-duplicate). This clearly distinguishes it from sibling tools like 'hunt' or 'review_file' by focusing on verdict and severity adjustment.

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 clear context that this is for single-finding adversarial triage and mentions the SAFE negative control to run, implying follow-up action. However, it does not explicitly state when not to use it or name alternative tools, so it stops short of a 5.

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