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

Annotations already indicate read-only and open-world behavior. The description adds value by detailing parameter matching rules and the output summary structure. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: first summarizes purpose and output, second details parameter behavior. It is concise, front-loaded, and every sentence adds value.

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 an output schema exists (though not shown), the description explains the summary output components and parameter behavior fully. Annotations provide open-world context. The description is complete for an agent to use correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the description adds detailed semantics: query matches across multiple fields, category and intention are exact case-insensitive, and days restricted to specific values with default. This goes beyond the schema 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?

The description clearly states the action (filter and aggregate), the resource (GreyNoise tags activity), and the output summary (total active IPs by classification, most active tags, per-tag detail). It distinguishes from sibling tools like get-tag-details and get-tag-activity by focusing on aggregation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidelines for parameter matching: query substring-matches name/description/slug/label, category and intention are exact case-insensitive, and days must be 1, 10, or 30. It does not explicitly state when to use this tool over alternatives, but the aggregation purpose is clear.

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?

Beyond annotations (readOnlyHint, openWorldHint), the description discloses order preservation, whole-request failure on IPv6, and license requirement—no contradiction with 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?

Two sentences with zero waste: first sentence states purpose and capacity, second covers order, failure mode, and prerequisites. Information is front-loaded and every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the existence of an output schema and full annotation coverage, the description still adds necessary constraints (IPv6 failure, license, order) and is complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema fully describes the 'ips' parameter (type, format, constraints). The description adds only behavioral context (order preservation) rather than clarifying parameter meaning, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (look up), resource (BSI provider matches), and constraints (up to 1,000 IPv4 addresses). It distinguishes this bulk tool from the likely single-IP sibling 'bsi-lookup'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit context: order preservation, IPv6 failure behavior, and license requirement. It does not directly name alternatives but the sibling list and task imply single vs bulk distinction.

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 and openWorldHint, so the safety profile is clear. The description adds the requirement for BSI entitlements, which is useful behavioral context. No contradictions.

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 front-load the core purpose and constraints with no extraneous content. 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 has an output schema, so return values are covered. The description is sufficient given the tool's simplicity (one optional parameter). It explains the data grouping and entitlement requirement, leaving no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a full description of the date parameter including pattern and default. The description adds no extra meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides counts of BSI IPs and CIDRs grouped by category, and mentions required entitlements. It distinguishes effectively from sibling tools like bsi-company-stats or bsi-trust-stats, which group by different criteria.

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 only notes that BSI entitlements are required. It does not provide guidance on when to choose this tool over siblings like bsi-company-stats or bsi-trust-stats, nor does it mention any scenarios where it should not be used.

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

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

Annotations already indicate readOnlyHint and openWorldHint, and the description adds the entitlement requirement. No further behavioral traits are needed; it does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the purpose and a constraint. Every word is necessary and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, output schema exists), the description adequately covers the purpose and a critical requirement. No gaps identified.

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 fully describes the `date` parameter. The description adds no additional parameter information, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it counts BSI IPs and CIDRs grouped by company name, which is a specific verb and resource. It distinguishes from sibling tools like bsi-category-stats and bsi-trust-stats.

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 mentions a prerequisite (BSI entitlements) but does not provide explicit when-to-use or when-not-to-use guidance compared to alternatives. Usage is implied by the verb and grouping, but no 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?

Annotations already provide readOnlyHint (safe read) and openWorldHint (data not authoritative). The description adds valuable behavioral context: IPv6 is rejected, results are in ascending precedence order (lower = higher priority), and a license is required. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of three short sentences that convey purpose, ordering, constraint, and license requirement. Every sentence carries essential information with no padding.

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 presence of an output schema, the description need not detail return values. It adequately covers input constraints, output ordering, and license requirement. It could optionally note error handling (e.g., invalid IP format), but the schema's pattern already handles validation hints. Overall, it is sufficiently complete for a simple lookup 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 input schema has 100% coverage with a clear description, format, and pattern for the 'ip' parameter. The description reiterates 'single IPv4 address' and mentions IPv6 rejection, but adds no new semantics beyond the schema. With full schema coverage, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'look up' and clearly defines the resource as 'Business Service Intelligence provider matches for a single IPv4 address'. It distinguishes from siblings like multi-ip-check (single vs. multiple IPs) and other bsi-*-stats tools (provider matches vs. aggregated stats).

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 the tool requires a BSI license, providing a key precondition. It implicitly suggests usage for single IPv4 lookups, and by naming 'single IPv4 address' it hints not to use for multiple IPs (use multi-ip-check) or for category/company/trust stats. However, it does not explicitly list alternatives or state when not to use.

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 provide readOnlyHint and openWorldHint, so the safety profile is covered. The description adds the requirement for BSI entitlements, which is beyond annotations. However, no other behavioral traits (e.g., rate limits, output format) are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two clear sentences with no extraneous information. It is front-loaded with the main purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering safety, the description is sufficient for a simple read-only tool. It states the main function and a requirement. Some context about trust levels or data scope might be helpful but is not critical.

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 does not add meaning beyond the schema; the 'date' parameter is fully described in the schema, and the description makes no additional reference to parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool counts BSI IPs and CIDRs grouped by trust level, using a specific verb and resource. It distinguishes from sibling tools like bsi-category-stats and bsi-company-stats, which group by different dimensions.

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 mentions 'Requires BSI entitlements' as a prerequisite, but does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by the title and the existence of sibling tools, but no when-not-to-use or alternative suggestions are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and external-data profile is covered. The description adds useful context about the enrichment dimensions returned, but does not discuss permissions, rate limits, or data freshness. Given annotation coverage, this is adequate but not rich.

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 packs the resource, cardinality, and enrichment dimensions without waste. Every clause contributes useful 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, among many similar IP/session enrichment tools, the description does not explain how this one differs from lookup-ip-context or quick-check-ip, leaving a meaningful selection gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema already defines the single required 'ip' parameter. The description reinforces that only one IP is handled but adds no format or validation details beyond the schema, so the baseline of 3 applies.

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 gives a specific verb and resource ('Look up a single callback/C2 IP') and enumerates the enrichment categories returned, so the tool's function is clear. It does not, however, distinguish this from sibling tools like lookup-ip-context or quick-check-ip, which likely have overlapping purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives such as lookup-ip-context, quick-check-ip, multi-ip-check, or callback-overview. The 'single IP' wording implies cardinality but does not state selection criteria or exclusions.

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

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

Annotations already declare readOnly and openWorld hints. The description adds the explicit time window constraint (1-7 days) and the performance overload warning, which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: one summarizing the tool's function and output dimensions, the other stating the crucial time window constraint. 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?

Given the complexity (9 optional params, no required) and the presence of an output schema, the description covers the key information: purpose, grouping dimensions, and important usage bound. Could benefit from noting that output is aggregate only, but overall 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?

Schema coverage is 100% with descriptions for all 9 parameters. The description reinforces the days constraint and lists the output dimensions, providing context beyond the parameter 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?

The description clearly states it aggregates statistics for callback/C2 IPs, listing the exact breakdown dimensions (attack stage, file analysis, etc.), which distinguishes it from listing tools like list-callback-ips.

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 aggregate stats with a recent window, but does not explicitly compare to siblings like list-callback-ips or bsi-trust-stats. The warning against wide ranges provides some guidance.

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

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

Annotations already indicate this is a non-read-only, non-idempotent, non-destructive action. The description adds the plan requirement and the basic behavior (runs query, notifies), but does not provide deeper behavioral details such as rate limits, idempotency guarantees, or consequences of creating an alert. With annotations present, the description adds some value but is not extensive.

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 contains two sentences that are front-loaded and to the point. No extraneous information. Every word contributes to the purpose and prerequisite.

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 create tool with a rich schema (7 parameters, nested objects, output schema), the description covers the core purpose and prerequisite. The output schema documents return values, so the description does not need to elaborate. Minor omission: it does not mention that workspace_id defaults to the bound workspace, but that is in the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so the schema already documents each parameter. The description only restates that the alert 'runs a GNQL query', which is already in the schema. It adds no additional semantic meaning or examples beyond what the schema provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Create', the resource 'scheduled alert', and what it does ('runs a GNQL query and notifies recipients'). It distinguishes itself from sibling tools like list-alerts, update-alert, etc., which perform different actions on alerts.

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 mentions a prerequisite ('Requires a plan entitled to alerts'), which provides usage context. However, it does not explicitly state when to use this tool vs alternatives like update-alert or delete-alert, though the tool name and purpose imply its usage for creation only.

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

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

Annotations already establish that this is a non-read-only, non-idempotent, open-world operation. The description adds useful behavior beyond the annotations by explaining that the blocklist is dynamic, auto-populates from matching IPs, and requires a plan entitlement.

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 short sentences with no wasted text. It is front-loaded with the core action and then adds the auto-population behavior and entitlement requirement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and annotations covering safety and idempotency, the description provides enough context to understand the tool's purpose and key requirement. It could be slightly more complete by referencing related update/delete tools, but nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all five parameters, including the GNQL query and optional fields. The description reinforces that the query drives IP population but does not add parameter-specific syntax, defaults, or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: create a dynamic blocklist from a GNQL query. It clearly explains that matching IPs auto-populate the blocklist, but it does not explicitly distinguish this from sibling tools such as update-blocklist or list-blocklists.

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 by saying it creates a dynamic blocklist from a GNQL query, and it notes the plan entitlement requirement. However, it does not state when not to use it or explicitly compare it with alternatives like update-blocklist or create-alert.

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

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

Annotations already indicate destructiveHint=true and idempotentHint=true. The description adds context by stating the deletion is permanent and cannot be undone, which reinforces the irreversible nature beyond what annotations provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the purpose and critical behavior. Every sentence is necessary and efficient.

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 delete tool with output schema present and comprehensive annotations, the description is sufficiently complete. It could mention what is returned, but output schema likely covers that.

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?

Input schema has 100% description coverage, so the schema already explains parameters. The description adds no additional parameter details. Baseline score 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Permanently delete an alert', clearly identifying the verb (delete) and resource (alert). It distinguishes from sibling tools like create-alert, update-alert, enable-alert, etc.

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 deleting alerts but does not explicitly state when to use this tool versus alternatives like disable-alert or update-alert. No guidance on prerequisites or when not to use.

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 provide destructiveHint=true and idempotentHint=true. The description adds valuable context about permanence ('cannot be undone'), which goes beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that efficiently communicates the action and its permanence. No unnecessary 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?

Given the tool's simplicity and the presence of annotations, the description covers essential behavioral aspects. However, it could mention side effects on related resources (e.g., blocklist entries) for completeness.

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 parameters are already fully documented. The description adds no additional meaning to the parameters beyond what is in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (delete) and resource (blocklist), and distinguishes from siblings like create, get, update. The phrase 'Permanently delete' adds specificity.

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 does not provide explicit guidance on when to use this tool versus alternatives like disabling a blocklist. The warning 'This cannot be undone' implicitly advises caution but lacks explicit usage context.

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

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

Annotations already indicate non-destructive and idempotent behavior. The description adds 'pause' and 'without deleting' but does not further elaborate on side effects or states. The bar is lowered due to annotations, but some extra context is provided.

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, clear sentence with no unnecessary words. Front-loaded with the action and resource.

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 mutation with good schema coverage and an output schema, the description is mostly complete. However, it does not mention that the alert must exist or what happens if already disabled, but this is minor given the annotations and schema.

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% with descriptive parameter names and descriptions. The tool description adds no additional meaning to the parameters, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Disable (pause)' and the resource 'alert'. It distinguishes from the sibling tool 'delete-alert' by explicitly saying 'without deleting 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?

The description implies when to use (to pause an alert without deletion) but does not mention when not to use, such as when the alert is already disabled, nor does it list alternative tools like 'enable-alert' or 'update-alert'.

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

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

Annotations already indicate idempotent, not read-only, not destructive. Description adds minimal behavioral context, e.g., no mention of prerequisites or behavior if already enabled.

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?

Single sentence, front-loaded with key information, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple toggle action with full param coverage and output schema present, the description is adequate though minimal. Missing context about idempotency? But annotations cover that.

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 covers both parameters with descriptions (100% coverage). Description adds no extra meaning 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 clearly states the verb 'Enable' (or 'resume') and the resource 'alert', distinguishing it from siblings like get-alert, list-alerts, update-alert.

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?

Implies usage for previously disabled alerts, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like update-alert.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating safe, standalone operation. The description adds that the output is a 'plain list', which is helpful but does not disclose additional behavioral traits (e.g., output format specifics, pagination, or limits). With annotations present, the description adds moderate context but not rich 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 two sentences, front-loaded with the main action and output type. The reference to 'Same filters as List Callback IPs' is efficient but slightly dependent on external knowledge. Overall, it is concise and structured well, earning a high score.

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 has 12 optional parameters, many sibling tools, and an output schema (present but not detailed), the description provides basic context ('plain list', date format). However, it misses details on how the export is delivered (e.g., file or stream) and any limits. The output schema reduces the burden, leaving completeness adequate but with 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?

The input schema covers all 12 parameters with descriptions (100% coverage). The description does not add any parameter-specific information beyond what the schema provides, so it meets the baseline for high coverage without enhancing semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Export', the resource 'callback/C2 IPs', and the output format 'plain list'. It explicitly distinguishes from the sibling tool 'List Callback IPs' by mentioning shared filters, providing specific and actionable 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 for exporting filtered IPs, referencing 'Same filters as List Callback IPs', but does not explicitly state when to use this tool versus alternatives like exporting sessions or searching. No when-not or alternative guidance is provided, leaving usage context implicit.

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

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

The description discloses a side effect: 'Saves the binary to a temp file and returns its path'. This adds behavioral context beyond annotations (readOnlyHint=false, openWorldHint=true). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that covers all essential information: action, resource, options, side effect, and a constraint. No unnecessary 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 tool with 3 parameters and an output schema (assumed), the description adequately explains the output (temp file path) and the demo scope limitation. It could briefly mention the return format structure, but overall is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with good descriptions for all parameters. The description adds minimal extra meaning, reaffirming the type enum and default pcap. It does not provide new semantic details beyond what the schema already offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Download a single session's data'), the resource ('for a given session ID'), and the output formats ('PCAP or raw payload'). It distinguishes from sibling tools like 'export-sessions-pcap' by specifying 'single session'. The constraint 'Not available when scope=demo' adds specificity.

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 a constraint ('Not available when scope=demo') but does not explicitly state when to use this tool versus alternatives like 'export-sessions-pcap' or 'get-session'. No context on when to choose pcap vs raw formats or when to avoid this tool.

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

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

The description discloses that the tool saves a binary PCAP to a temporary directory and returns the file path, which adds context beyond annotations. The annotations include readOnlyHint:false (indicating mutation) and openWorldHint:true, which align with the description. No contradictions found.

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 extremely concise at three sentences, each serving a distinct purpose: stating the action, detailing the behavior, and providing usage examples. It is front-loaded and contains no unnecessary 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?

Given the tool has an output schema (not shown but indicated), the description does not need to explain return values. It adequately covers the main purpose, output location, and query syntax. For a tool with 7 parameters and 2 required, the description is complete enough for effective usage.

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?

While the input schema already provides descriptions for all 7 parameters (100% coverage), the description adds value by giving concrete examples of Lucene query syntax for the 'query' parameter. This enhances understanding beyond the schema alone. Other parameters are not elaborated further, but the baseline is 3 due to high 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 it exports a PCAP file from GreyNoise sensor sessions and returns the file path. It uses a specific verb ('Export') and resource ('PCAP file from sessions'). However, it does not explicitly differentiate from sibling tools like 'export-session-data' or 'search-sessions', which limits clarity for selection.

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 explains when to use the tool (to export PCAP files matching query criteria) and provides guidance on using Lucene query syntax with examples. However, it does not mention when not to use it or suggest alternative tools for different needs, such as when only session data is needed instead of PCAP.

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

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

The description aligns with the readOnlyHint annotation, indicating a read-only operation. However, it adds no extra behavioral context beyond what annotations already provide (e.g., no mention of output format, pagination, or rate limits).

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 that front-loads the key information. Every word earns its place with no redundancy or fluff.

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 get-by-ID tool with an output schema, the description is sufficiently complete. It clearly communicates the tool's purpose and input requirements.

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 covers 100% of parameters with descriptions. The description adds no additional meaning beyond 'by ID'. Baseline 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (retrieve), the resource (alert configuration), and the method (by ID). It effectively distinguishes from sibling tools like list-alerts (which returns multiple) and update-alert (which modifies).

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 when you have an alert ID and need its configuration, but it does not explicitly state when to use this tool versus alternatives like list-alerts or update-alert. No when-not or exclusion criteria are provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and nothing contradicts it. The description adds only one useful nuance — 'configuration' signals it returns the blocklist's settings rather than its IP entries — but says nothing about auth, scoping, or missing-record 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?

One sentence, front-loaded with the action and resource, with zero filler. Sized appropriately for a simple single-record getter.

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, fully documented parameters, and an output schema exists, so return values need not be explained. The only shortfall is that an agent must infer the boundary with get-blocklist-ips and list-blocklists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters (blocklist_id, workspace_id) are documented, including the workspace defaulting rule. The description only restates 'by ID' and adds no syntax or scoping detail beyond the schema, so baseline 3 applies.

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?

Specific verb+resource ('Retrieve a single blocklist's configuration by ID'), and the word 'single' implicitly separates it from list-blocklists and get-blocklist-ips. It stops short of naming those siblings, so differentiation is left partly to 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?

The 'by ID' framing implies this is for fetching a known blocklist, but there is no explicit when-to-use versus list-blocklists (browse) or get-blocklist-ips (the entries themselves). No prerequisites or exclusions 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 provide readOnlyHint=true and openWorldHint=true. Description adds only 'current list', which is redundant with 'retrieve'. No disclosure of behavior beyond annotations (e.g., that the list may change, that size parameter limits results, or that results may be paginated). With annotations covering safety, the description contributes little.

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?

Single sentence, no wasted words. Front-loaded with verb and resource. However, it could be slightly more structured with a hint about required parameter or usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema (not shown) and clear annotations, the description provides minimal but functional coverage. It omits when to use the tool relative to siblings and does not mention that a blocklist_id is required, which is critical context for a 3-parameter tool with one required field.

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%, with each parameter described (size maximum, blocklist_id type, workspace_id default). Description does not add any extra meaning or context for parameters. Baseline 3 is appropriate as schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Retrieve the current list of IPs in a blocklist' – a specific verb and resource. It distinguishes from sibling 'list-blocklists' (which lists blocklists) and 'list-callback-ips' (which lists callback IPs). However, it does not mention the required blocklist_id parameter explicitly, missing an opportunity to reinforce 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?

No guidance on when to use this tool versus alternatives. For example, it doesn't say 'Use this to get IPs for a specific blocklist; for listing all blocklists, use list-blocklists.' The agent must infer usage from sibling names and context.

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

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

The description discloses that the tool provides vulnerability intelligence (read-only operation) and lists returned data categories (scores, stats, IP activity). No contradictions with annotations (readOnlyHint, openWorldHint).

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?

Single sentence, front-loaded with the core purpose, followed by specific details. No redundant words; every clause adds value.

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 single parameter and presence of an output schema, the description fully covers what the tool does and how to invoke it. No additional details needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter. The description adds format validation and case-insensitivity guidance, enhancing understanding beyond the schema's 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 identifies the tool's purpose: retrieving GreyNoise vulnerability intelligence for a single CVE. It lists specific data points (CVSS/EPSS scores, KEV status, etc.) and distinguishes itself from sibling tools that handle sessions, IP lookups, or bulk 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 specifies the required format for cve_id ('CVE-YYYY-NNNNN') and notes case-insensitivity. It implies single-CVE usage but does not explicitly state when not to use it or mention alternatives, though sibling context makes the scope clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety behavior is covered and the description's only added context is that it targets one session and touches external GreyNoise data. It says nothing about permissions, missing-ID behavior, or rate limits beyond the annotation. It also spends its behavioral budget restating return fields that the output schema already defines.

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, action-first, with the identifying constraint in the opening clause. The second sentence is largely a restatement of the output schema, so one sentence does not fully earn 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 single-record read with a rich output schema and read-only annotations, this is adequate, but the unmentioned optional scope parameter and the redundant return-field enumeration leave the definition slightly misallocated. An agent knows how to call it but not how the scope parameter changes 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 both parameters are already documented, and the description only echoes the required session_id. The optional 'scope' parameter and its 'default: workspace' behavior are never mentioned in the description, so no meaning is added 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?

Names a specific verb and resource ('Get full metadata and connection details for a single GreyNoise sensor session by its ID') and scopes it to one record, which implicitly separates it from search-sessions and the aggregation siblings. It stops short of explicitly contrasting with session-connections or session-fields, whose names overlap with the 'connection details' claim.

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 'a single ... session by its ID' implies this is the retrieval path when you already hold an identifier, versus the search/list siblings, but the description never states when to use it over alternatives such as search-sessions or session-fields. Use context is inferred rather than instructed.

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

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

The description adds beyond annotations by explaining the side effect of saving to a temporary directory and returning a file path, and suggests tools to open the file. No contradiction with annotations, which indicate non-read-only and open-world hints.

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 sentences, no wasted words. The key action is front-loaded, and the file format and usage context are efficiently provided.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description correctly omits return value details. It covers the essential behavior: download, temporary storage, file path return, and compatibility with analysis tools. No gaps identified.

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 description adds minimal extra meaning for parameters. It does not elaborate on 'scope' or 'session_id' beyond what the schema already describes.

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 'Download' and the resource 'raw PCAP capture for a single GreyNoise sensor session', which distinguishes it from sibling tools like 'export-sessions-pcap' that likely handle multiple sessions.

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 (need a single session's PCAP) but does not explicitly state when not to use or list alternatives. The presence of sibling 'export-sessions-pcap' provides context but not direct guidance.

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

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

Annotations already declare readOnly and openWorld hints. The description adds value by detailing the output type (time-series IP counts and intention activity) and constraints on time range (days) and granularity (1h vs 24h). No contradictions.

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, no filler. First sentence captures purpose and key constraint. Second sentence details parameter specifics. Well 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 three parameters (all described), high schema coverage, and presence of an output schema, the description sufficiently covers what the tool does, required inputs, and behavioral nuances. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds critical usage semantics: the exclusivity constraint between 'id_or_slug' and 'cve', and the relationship between 'days' and 'granularity'. This goes beyond the schema's individual property 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?

The description clearly states the verb 'Retrieve' and the specific resource 'time-series unique-IP counts and intention activity for a tag or by CVE'. It also highlights exclusivity of two parameters, distinguishing it from sibling tools like 'get-tag-details' or 'analyze-tags-activity'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Provide exactly one of id_or_slug or cve' and specifies allowed values for 'days' with default. However, it does not explicitly compare with alternatives or mention when not to use it.

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 and openWorldHint; description adds behavioral context: uses a cached list for lookups, case-insensitive slug matching. No contradictions. Provides useful details beyond 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?

Single sentence that conveys all essential information without redundancy or extraneous detail. Efficient and well-structured.

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?

Output schema exists, so return values are covered. Description mentions caching, adding context for data freshness. Could include cache refresh timing but not necessary for completeness.

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% with a basic description. Description adds meaning: exact match for id, case-insensitive match for slug, and the lookup is over a cached list, providing context beyond the schema's minimal 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?

Description clearly states the verb 'Get', the resource 'full record for a single GreyNoise tag', and the lookup method (by id or slug, case-insensitive, from cached list). It distinguishes from sibling tools like 'get-tag-activity' by specifying it retrieves the full record for a single tag.

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?

Implies usage over a cached list but does not explicitly state when to use this tool versus alternatives (e.g., get-tag-activity). No guidance on when not to use or prerequisites.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the data source (v3/tags) and a 1-hour cache window, which is real behavioral context an agent needs for freshness decisions. It does not cover rate limits or error behavior, but the annotations already establish the safety 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?

Three short sentences, all front-loaded: purpose first, then return shape, then the no-parameter note. No filler or repeated 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 parameterless read with an output schema, this is essentially complete; the source and cache note are useful extras. The only gap is routing guidance to search-tags when a caller actually wants a filtered subset rather than the whole catalog.

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?

Zero parameters, so the baseline is 4. The explicit 'Takes no parameters' line is redundant with the empty schema but harmlessly confirms there is nothing to supply.

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 ('Retrieve') and resource ('complete list of GreyNoise tags') and names the backing endpoint (v3/tags), so the agent knows exactly what data comes back. The word 'complete' implicitly separates it from filtered siblings like search-tags, but it never names that sibling explicitly.

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 only implied: fetch this when you need the full tag catalog. There is no explicit when-to-use, no exclusion, and no pointer to search-tags or get-tag-details for filtered or single-tag lookups, which are present among the 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?

Annotations already state readOnlyHint and openWorldHint, so the description adds value by detailing the two internal API calls and the resulting combined set with a 'source' field and total count. This goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with the purpose, and each sentence adds essential information (what, no params, internal mechanics, output details). No superfluous 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?

Given no parameters, readOnlyHint, openWorldHint, and an output schema (exists but not displayed), the description fully explains the tool's behavior: two calls, combined result with source field and total count. The agent has enough context to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters (100% coverage), and the description confirms it takes no parameters. Since there are zero parameters, a baseline of 4 is appropriate, and the description adds no extra meaning but is clear.

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 lists trending and anomalous GreyNoise vulnerability tags, specifies it takes no parameters, and explains the internal behavior of making two calls. It is distinct from sibling tools like 'get-tag-activity' which likely returns different data.

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 notes no parameters are required, making usage straightforward, but does not explicitly compare with alternative tools or provide when/when-not guidance. It is adequate for a simple list tool.

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

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

Adds substantial behavior beyond the readOnlyHint/openWorldHint annotations: pagination happens via a scroll token, quick=true truncates the payload, format='csv' changes only the text rendering, and structuredContent is invariant. It stops short of covering scroll-token expiry or error/rate-limit behavior, which would be the remaining useful disclosure for a paginated search 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 differentiator against gnql-query is front-loaded in the first sentence, followed by short scoped paragraphs for pagination, quick mode, and format. No sentence is 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?

With an output schema present, return values need not be explained, and the description covers the non-obvious parts: pagination, truncation, and output-format invariance. The one gap is that 'GNQL query syntax' is only referenced by pointer to gnql-query rather than characterized, leaving an agent to infer query construction.

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 exceeds it by enumerating the exact CSV columns produced by format='csv' and clarifying that format affects only the text response while structuredContent stays JSON. That is meaning the schema's one-line enum description does not convey.

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 ('Search GreyNoise data using GNQL, returning IP metadata without raw scan data') and explicitly contrasts the result payload against the sibling gnql-query. The distinction is resolvable without opening either schema.

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?

Gives both the positive condition ('when you need IP classification, tags, and metadata but not raw scan details') and the excluded payload ('ports, fingerprints, HTTP paths'), plus names gnql-query as the heavier alternative. This is explicit when/when-not/alternative guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful behavioral context: it returns full IP context with raw scan data and results are paginated via the scroll parameter. It does not discuss rate limits or authentication, but goes meaningfully beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well structured: purpose first, then facets, examples, and pagination guidance. The facet list is extensive, but it is useful reference material for a query language rather than 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?

Given the output schema and annotations, the description supplies the key missing context an agent needs: GNQL syntax guidance, representative fields, examples, and pagination behavior. Nothing essential for correct invocation appears absent.

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, but the description substantially enriches the query parameter by explaining GNQL facets and giving concrete query examples. It also reinforces the scroll parameter's pagination role, adding meaning beyond the schema's brief 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?

The description states a specific verb and resource: search GreyNoise data using GNQL, returning full IP context including raw scan data. It is clear what the tool does, though it does not explicitly distinguish itself from nearby query tools like gnql-metadata-query, gnql-stats, or lookup-ip-context.

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 examples imply when GNQL is useful for targeted IP-context searches, but the description does not explicitly say when to use this tool versus sibling query or lookup tools. It gives strong query examples but no explicit alternatives or exclusions.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, and the description does not contradict these. It adds useful behavioral context: data refreshes hourly, and explains facet subtraction. No destructive behavior is implied.

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 sections (facets, behavior, shortcuts, examples) and front-loaded with the purpose. However, it is lengthy; some introductory sentences about GNQL could be trimmed for conciseness.

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 and the presence of an output schema, the description covers query construction, facets, behavior, and examples thoroughly. It does not need to explain return values. No gaps are evident.

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% with clear descriptions for both parameters. The description adds significant context for the 'query' parameter by detailing GNQL syntax, facets, and examples, but for 'count' it only repeats schema info.

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 states 'Get aggregate statistics for results matching a GreyNoise GNQL query.' This clearly specifies the verb (Get), resource (aggregate statistics), and context (GNQL query), distinguishing it from siblings like gnql-metadata-query.

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 includes a 'Behavior' section noting how to subtract facets, data refresh frequency, and 'Shortcuts' with keywords like 'today' and 'interesting'. It provides many examples, giving strong usage guidance, though it lacks explicit contrast with sibling tools.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, which the description does not contradict. The description adds behavioral details such as hourly bucketing and ISO 8601 time format, but does not elaborate on the open-world nature or potential unknown results beyond what annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is highly concise with four sentences, each serving a distinct purpose: stating the action, explaining utility, specifying time format, and detailing the size parameter. No redundant information, and key points are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main purpose, time format, and size constraints, but it does not explain what happens when start_time or end_time are omitted (since they are optional). The output schema exists and may compensate, but the description leaves a gap in understanding default behavior for time bounds.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has 100% coverage with descriptions for all four parameters. The description adds an example of ISO 8601 format and clarifies size constraints (default, max), but these are already present in the schema. The description does not add significant new semantic meaning.

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 retrieves hourly GNQL records for a time range, specifying it is for temporal analysis of IP activity. It distinguishes the tool from its sibling 'gnql-timeseries-stats' by focusing on records rather than statistics, but does not explicitly name alternatives.

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 explains the tool is useful for investigating when IPs were active, but it does not provide guidance on when to avoid using it or compare it with other sibling tools like 'gnql-stats' or 'gnql-metadata-query'. No explicit when-to-use or when-not-to-use advice is given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's job is lighter. It adds value by specifying that results are aggregated counts per time bucket, that the interval must be 'hour' or 'day', and that time bounds use ISO 8601 format. These details go beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences: the first states the core purpose, the second elaborates on output and use case, and the third gives parameter constraints. Every sentence adds value; no wasted words. It is front-loaded and efficiently structured.

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 (4 parameters, output schema exists, annotations present), the description covers: purpose, use case, parameter constraints, and return value nature. It does not leave important gaps, and the output schema handles return details. The description is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds minimal extra meaning: it reiterates that interval must be 'hour' or 'day' (already in schema as enum) and that time bounds use ISO 8601 (also in schema). This is adequate but not exceptional.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get the number of unique IPs matching a GNQL query per hour/day over a time range', using a specific verb and resource. It distinguishes this tool from siblings like 'gnql-stats' and 'gnql-timeseries' by focusing on unique IP recall stats and trend analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states it is 'useful for trend analysis and understanding how scanning/attack activity changes over time', providing clear context for when to use it. However, it does not explicitly state when not to use it or suggest alternative tools.

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 provide readOnlyHint=true and openWorldHint=true. Description adds little beyond the title, but no contradictions.

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?

Single sentence, zero waste. Perfectly sized for the tool's simplicity.

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?

Simple tool with one parameter and output schema. Description is sufficient given low complexity and rich annotations.

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?

Only one parameter with full schema description coverage. Description adds no extra meaning 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?

Clear verb ('List') and resource ('alerts configured in a workspace'). Distinguishes from siblings like 'get-alert' (single alert) and mutation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives mentioned, but simple read-only list context is implied by readOnlyHint annotation and sibling set.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered, but the description adds no context of its own: nothing about default result size, pagination behavior, or ordering. It neither contradicts nor enriches the structured metadata.

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 front-loaded sentence with zero waste and no filler. It is appropriately sized, though its brevity borders on under-specification rather than crispness.

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: no required params, full schema coverage, an output schema that documents return values, and annotations covering the safety profile. The description is sufficient to invoke it correctly; only the relationship to get-blocklist and pagination expectations are left unstated.

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 all three parameters (limit, offset, workspace_id) carry their own descriptions including defaults and ranges, so the schema does the heavy lifting. The description contributes nothing about parameters, which is acceptable at baseline but no 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 specific verb ('List') and resource ('blocklists') with scope ('in a workspace'), so an agent knows exactly what it returns. It does not, however, distinguish itself from the sibling get-blocklist (single retrieval) or get-blocklist-ips, leaving the collection-vs-single distinction implicit.

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 only implied by the verb 'List' and the workspace scope; there is no explicit when-to-use, no exclusion, and no pointer to get-blocklist for single-record lookups. An agent can infer it is the enumeration endpoint, but must reason about alternatives itself.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds pagination and date-format context, but does not mention authentication, rate limits, or return behavior; the output schema covers return values.

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, front-loaded with the core purpose and followed by the key date-format constraint. No wasted wording.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the rich schema, output schema, and annotations, the description is sufficient for an agent to understand the tool's scope. It is slightly incomplete because it does not route the agent among closely related callback-IP siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 14 parameters are already documented in the schema. The description only restates filter categories and the YYYY-MM-DD date format, adding little semantic meaning 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?

States a specific verb and resource: "Paginated list of callback/C2 IPs," and names the filter dimensions. It is clearly a listing tool, but it does not explicitly distinguish itself from siblings such as callback-ip-lookup, export-callback-ips, or callback-overview.

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 explains what can be filtered but gives no guidance on when to use this tool versus callback-ip-lookup, export-callback-ips, or callback-overview. There are no exclusions or alternative-selection cues.

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 and openWorldHint. The description adds value by detailing the specific data categories returned (classification, tags, raw scan data, business service intelligence, geo, network metadata), which are not covered by annotations. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that front-loads the core action and lists all relevant data types. No redundant information; every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple single-parameter input, read-only annotations, and existence of an output schema, the description provides a comprehensive overview of the return data. Minor omission: could mention potential rate limits or authentication requirements, but these are likely covered by the API 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?

Schema coverage is 100% with a single required 'ip' parameter and a clear description in schema. The tool description does not add parameter-specific details beyond what the schema provides, so the baseline score of 3 applies.

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 'Get' and the resource 'detailed GreyNoise context for a single IP', and explicitly lists the types of data included (classification, tags, intelligence, geo, network). This sets it apart from sibling tools like 'multi-ip-check' which handles multiple IPs, and session/alert tools which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for a single IP lookup and hints at the rich data returned, but does not explicitly instruct when to use this tool over siblings like 'multi-ip-check' or 'get-session'. There are no 'when-not' or alternative recommendations, leaving the agent to infer context from sibling names.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by specifying the batch size limit (10,000) and the return structure. However, it does not disclose potential errors, rate limits, or how invalid IPs are handled, which would be useful for an agent.

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 with no fluff, front-loading the key capability (batch check) and then listing outputs. Every word adds value.

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 (context signal true), the description adequately covers inputs and expected outputs. It could be improved by mentioning error handling or performance considerations for large batches, but overall it 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 input schema already describes the only parameter ('ips') thoroughly, including format and constraints. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Check up to 10,000 IP addresses'), the resource ('IP addresses'), and the specific outputs ('classification, business-service status, trust level, summary breakdown'). This uniquely distinguishes it from sibling IP tools like 'lookup-ip-context' which handles single IPs.

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 no guidance on when to use this tool versus alternatives (e.g., 'lookup-ip-context' for single IPs). It does not mention circumstances where this batch check is appropriate or any prerequisite actions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'fast, lightweight' but does not disclose additional behavioral traits such as rate limits, data sources, or any side effects beyond what annotations convey.

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?

Single sentence, no unnecessary words, front-loaded with key information. 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 tool's simplicity, output schema exists (not shown but present), and annotations cover read behavior, the description is sufficient. It could mention the return type but is not required due to output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter 'ip' is thoroughly defined with format, pattern, and description. The description adds no extra meaning beyond 'single IP address', so the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Get' and resource 'classification and business-service check for a single IP address'. It is specific and distinguishes from siblings like multi-ip-check (multiple IPs) and callback-ip-lookup (different 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 with 'fast, lightweight' but does not explicitly state when to use this tool versus alternatives like lookup-ip-context or bsi-lookup. No exclusions or criteria provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the paginated result shape and the Lucene-syntax requirement, which is genuinely useful behavior context, but says nothing about time-range limits, rate limits, or result caps beyond what the schema states.

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 sentences, front-loaded with purpose, then return shape, then the query-syntax hint. The field enumeration in sentence two overlaps with the output schema, so it earns slightly less than a perfect score, but nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema, 100% parameter coverage, and annotations present, the description covers the remaining gaps (purpose, query syntax, result nature). Minor omissions such as scope=workspace vs demo and sort behavior are already handled by the schema, so the description is complete enough to call 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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by specifying Lucene query syntax and giving a concrete example ('destination.port:443'), which meaningfully constrains how the `query` parameter should be formed.

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 — 'Query and filter GreyNoise sensor network sessions over a time range' — plus what a result contains (IPs, ports, timestamps, byte/packet counts, classification). That is enough to distinguish it from single-session or export siblings, though no sibling is named explicitly.

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 implied by 'over a time range' and 'paginated list', which suggests exploratory/browsing use rather than fetching one session or exporting. However, the description never says when to prefer this over get-session, session-counts, gnql-query, or export-session-data, all of which sit adjacent in the tool list.

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

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

The description adds meaningful behavior beyond the annotations: it discloses that searching is client-side over a cached list, explains the matching modes, and notes that no filters returns the full tag set. Annotations already declare read-only/open-world behavior, and the description does not need to repeat that.

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, moving from the operation and data source to per-parameter matching semantics and default behavior. Every sentence carries useful information with no redundant restatement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple four-optional-parameter search surface, the presence of an output schema, and annotations covering safety behavior, the description supplies everything needed to invoke the tool correctly. It covers the data source, all matching semantics, and the no-parameter default.

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 already 100%, but the description adds matching semantics that the schema does not fully convey: query is a substring match across name/description/slug/label, category and intention are exact case-insensitive matches, and cve substring-matches associated CVEs. It also clarifies that all parameters are optional.

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 specific verb and resource: search GreyNoise tags, operating client-side over the cached v3/tags list. This clearly separates it from a generic tag-list or tag-detail tool, though it does not explicitly name a sibling alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains that all parameters are optional and that omitting them returns every tag, which gives useful usage context. However, it does not explicitly say when to use this instead of siblings such as get-tag-list or get-tag-details, so the guidance is implied rather than explicit.

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