Scry

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

With no annotations, the description carries full burden. It discloses the output metrics (observation count, actor counts, protocol breakdown) but does not mention side effects, read-only nature, authorization needs, or performance implications.

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 main purpose and enumerates key output fields without 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 no output schema, the description lists the returned metrics, which is helpful. However, it lacks input parameter details and usage context, making it somewhat incomplete for agent decision-making.

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

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

Schema description coverage is 0%, but the description does not explain the 'asn' format or the 'since_ms' parameter (purpose, unit, behavior when omitted). It only indirectly implies the ASN is a 'single ASN'.

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 explicitly states it rolls up corpus activity for a single ASN and lists specific metrics (observation count, distinct IPs, actor count, etc.). This clearly distinguishes it from siblings like scry_campaign or scry_country.

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 is provided on when to use this tool versus alternatives. The sibling list is provided externally but not referenced. The description does not mention prerequisites or 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?

No annotations are provided, so the description must disclose behavioral traits. It only states it returns 'detail' (implying a read operation) but lacks information about authentication, rate limits, or any side effects. The ID format is the only extra 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 a single, well-structured sentence that front-loads key information (verb, resource, ID format). No unnecessary words; every part is relevant.

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 required parameter, no output schema, no annotations), the description provides the essential purpose and ID format. However, it omits return value details, potential errors, and usage context relative to sibling tools. It is adequate but not thorough.

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

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

Schema description coverage is 0%, so the description must add value. It clarifies that the 'id' parameter is a campaign ID with a specific format, which marginally supplements the schema's pattern constraint. However, no further semantics like field descriptions or example values are provided.

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

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

The description clearly states that the tool retrieves a single campaign detail by its ID, and explicitly provides the ID format (c[0-9a-f]{15}). This distinguishes it from the sibling tool 'scry_campaigns' which presumably lists multiple campaigns.

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 is given on when to use this tool versus alternatives like 'scry_campaigns' or other scry tools. The description does not mention prerequisites, context, or cases where this tool is inappropriate.

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

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

No annotations provided. Description explains the filtering logic but not behavioral traits like auth needs, rate limits, or what happens with parameters. It covers the definition of campaigns adequately but lacks broader transparency.

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 efficient sentence plus criteria. Every word serves a purpose. No 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?

With no output schema and zero parameter documentation, the description is too minimal. It omits return values and parameter behavior, making it incomplete for an agent to fully understand 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?

Schema description coverage is 0% for 2 parameters (limit, include_inactive). Description does not explain these parameters or their effects, leaving them completely undocumented.

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

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

Description clearly defines what the tool does: it retrieves active threat campaigns meeting specific criteria (≥5 actors, ≥3 ASNs, ≤5 ports, ≥1h). This distinguishes it from siblings like 'scry_campaign' (singular) and other 'scry_*' 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?

The criteria imply when to use (detecting coordinated activity) but no explicit guidance on when not to use or alternatives. Sibling names are listed but no differentiation. Context is clear but lacks 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?

With no annotations, description carries full burden. It lists returned fields but does not disclose side effects, rate limits, authentication needs, data freshness, or error behavior. Lacks critical behavioral context for a tool with no annotation coverage.

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?

Description is two paragraphs: first details output fields, second provides usage guidance. No redundant sentences, but could be more structured (e.g., bullet points) for easier scanning.

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 lookup tool with one parameter and no output schema, description covers purpose, input, output fields, and usage guidelines. However, lacks details on rate limits, error states, and data freshness, which are absent from 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?

Schema coverage is 100% and parameter description is clear. Main description adds no extra semantic value beyond restating IPv4 constraint and listing fields, 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?

Description clearly states it returns corpus knowledge for a single IPv4 address with specific fields. It does not explicitly contrast with siblings like scry_asn or scry_campaign, but the verb 'scry_check' and input parameter 'ip' make the purpose unambiguous.

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

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

Explicitly states when to use (IP triage, hostility assessment) and what not to use (raw payloads, IPv6). Lacks explicit alternative tool names, but the guidance is clear and practical.

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

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

With no annotations, description carries full burden. Discloses max IP count and per-IP shape, but omits rate limits, auth requirements, error handling, idempotency. Adequate but not comprehensive.

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 crisp sentences with zero wasted words. Front-loads purpose and constraint ('Up to 100 IPs'). Highly 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?

Given no output schema, description references scry_check output shape, assumes known but acceptable. Lacks details on failure modes or partial results. Nearly complete for a simple bulk 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?

Only one parameter 'ips' with no schema description (0% coverage). Description adds context (IPv4 addresses, up to 100) but does not specify exact format or validation (e.g., CIDR vs plain IP). Partially compensates but incomplete.

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 it looks up many IPv4 addresses in one request, distinguishing it from the single-IP scry_check and other sibling tools. Specifies IP range and limit.

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?

Notes up to 100 IPs per call and compares to scry_check ('Same per-IP shape as scry_check'). Implies bulk use case but lacks explicit when-not-to-use or alternatives beyond scry_check.

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

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

With no annotations provided, the description must fully disclose behavioral traits. While 'roll-up' implies a read-only aggregation, the description does not explicitly state idempotency, side effects, or performance characteristics. Missing critical details like whether it requires authentication or has 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 very short (two sentences) and front-loads the key purpose. It avoids unnecessary fluff and uses a helpful reference to scry_asn. However, it could be slightly expanded to include parameter details without losing 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 simplicity (2 parameters, no output schema), the description should fully cover usage and behavior. It fails to explain parameter semantics and usage context, leaving the agent with incomplete information. The reference to scry_asn helps but does not compensate for the lack of parameter documentation.

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

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

Schema description coverage is 0%, and the description fails to explain any parameters. The country parameter's pattern (2-letter ISO code) is not mentioned, and since_ms is completely undocumented. The description adds no value beyond the schema itself, which is insufficient for effective parameter understanding.

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 a 'roll-up of corpus activity by ISO country code,' identifying the specific resource and grouping dimension. The reference to 'Same shape as scry_asn' further clarifies the output structure, distinguishing it from siblings like scry_top or scry_asn.

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 the shape is the same as scry_asn, implying similarity, but does not provide explicit guidance on when to use this tool versus alternatives like scry_asn or scry_top. There is no mention of prerequisites, forbidden scenarios, or contextual factors.

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

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

No annotations provided, so description bears full burden. It mentions aggregation and cursor-pagination but omits read-only nature, rate limits, auth, error behavior, or time window duration.

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

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

Two sentences with no wasted words. Front-loaded purpose, followed by pagination detail. Could be slightly longer to cover all parameters, but remains concise.

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 5 parameters, no output schema, and many siblings, the description is too sparse. It fails to clarify return format, all parameters, or typical use cases.

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

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

Schema coverage is 0%, so description must compensate. It only explains since_ms (pagination) and implicitly limit. Parameters country, protocol, include_noise are left unexplained, leaving significant ambiguity.

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 it's a 'Recent observations feed' aggregated by source IP within a time window, which clearly indicates the resource and action. The name and sibling list further imply cybersecurity context, making the purpose fairly clear.

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 siblings like scry_asn or scry_country. Lacks when-to-use, when-not-to-use, or alternative suggestions.

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?

In the absence of annotations, the description fully discloses behavioral traits: free, anonymous, rate-limited, low latency, and lists exact return fields. No hidden behaviors.

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?

Every sentence adds value; uses bullet-like formatting for clarity. 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?

Given no output schema, the description enumerates all return fields and provides usage context. Completely covers what an agent needs to invoke and interpret results.

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?

No parameters exist, and the description explicitly states 'Inputs: none.' Baseline 4 is appropriate as no additional parameter meaning is needed.

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 returns aggregate Scry corpus telemetry (total observations, distinct IPs, timestamps, etc.). It explicitly distinguishes from sibling tools like scry_check, which is for specific IP queries, making the purpose unambiguous.

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

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

Provides explicit 'Use this tool when' and 'Do NOT use this tool when' sections, including alternative tools (scry_check) and clear scenarios (liveness check, dashboard).

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

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

No annotations exist, so the description carries the full burden. It implies a read-only query but does not disclose side effects, authentication needs, rate limits, or limitations. Only basic behavioral hints are 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?

The description is highly concise—two sentences with no wasted words. The first sentence states the core function, and the second adds use cases. Front-loaded 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?

Given no output schema and no annotations, the description provides adequate context for a simple timeseries query: it returns counts and indicates granularity options. However, it omits details about the time range parameters and default behavior, leaving gaps for an agent invoking the tool.

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

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

Schema coverage is 0%. The description implicitly mentions the 'bucket' enum via the granularities listed, but does not explain 'since_ms' or 'until_ms' (e.g., what unit, expected format), adding little 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 ('get bucketed observation counts') and resource ('observations over time'), and provides specific use cases ('detect bursts, plot trends'), distinguishing it from sibling tools like scry_stats or scry_recent.

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

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

The description gives clear context for usage ('detect bursts, plot trends, sanity-check whether attacker activity is rising or falling'), but lacks explicit when-not-to-use guidance or mention of alternative tools for similar tasks.

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

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

No annotations are provided, and the description offers minimal behavioral context (e.g., whether it is read-only, authorization needs, or error handling).

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

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

The description is a single, front-loaded sentence with 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 tool's simplicity (one parameter, no output schema), the description covers the basic purpose but lacks information about the returned data structure.

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

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

The description mentions the '16-char hex id' which is already encoded in the pattern; it adds no additional meaning about what a 'tool' is or how the ID is used.

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 retrieves a single tool detail by its 16-char hex ID, distinguishing it from sibling tools like 'scry_tools' which lists all tools.

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

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

It implies use when you have a specific hex ID and need details, but does not explicitly state when not to use it or suggest alternatives.

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

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

With no annotations, the description carries the full burden. It discloses that only aggregate metadata is returned (not member actors), implying a read-only operation. However, it lacks explicit safety or destructiveness indications.

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

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

Two sentences with no wasted words. The key functionality is front-loaded ('List detected attack tools') and constraints are succinctly stated.

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 output schema, the description provides a reasonable overview of return values (aggregate metadata) and constraints (3+ source IPs). However, it lacks detailed structure or format hints for the returned tuples.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'protocol' in the context of output tuples but does not explain the parameters (limit, protocol, since_ms) or how they affect results. Only 'protocol' is implied as a filter.

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 detected attack tools as aggregate metadata, specifically (protocol, payload, path) tuples from at least 3 source IPs. It distinguishes from sibling tools like scry_tool (singular) and others by focusing on aggregated tool 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 implies usage for querying aggregated attack tool information but does not provide explicit when-to-use or when-not-to-use guidance. Alternatives are not mentioned, though sibling names offer some 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 reveals the tool is 'over a time window' (using since_ms) and returns top-N dimensions, but does not explain ordering, default behavior, or the effect of include_noise. With no annotations, the burden falls entirely on the description, which is insufficient.

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 plus a tagline, with no redundant information. It is appropriately front-loaded 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?

Given the complexity (4 parameters, no output schema, no annotations), the description is too sparse. It lacks details on return format, default limit (1?), ordering, and the meaning of 'top' (by count?). Complete guidance would require more behavioral and parameter information.

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

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

Schema coverage is 0% (no parameter descriptions). The description only hints at 'time window' (since_ms) and 'source dimensions' (dimension enum), but does not explain limit, include_noise, or their interactions. It adds minimal value beyond the enum values.

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 returns 'Top-N source dimensions over a time window' and provides a concrete use case ('where is the noise coming from right now?'). This distinguishes it from sibling tools like scry_asn or scry_timeseries by specifying it aggregates sources across 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 implies usage for situational awareness but gives no explicit guidance on when to use this tool vs alternatives (e.g., scry_asn for a specific ASN). No exclusions or prerequisites are mentioned.

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