Nullcone Threat Intelligence

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

No annotations exist, so the description carries full responsibility. It discloses that the check completes in <1ms with no network I/O, and outlines the return values. It could explicitly state it is a read-only, side-effect-free operation, but the behavior is well implied and sufficient.

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, a tier map, argument list, and return fields. It is front-loaded with the purpose. While somewhat lengthy, every sentence provides value; minor trimming could improve conciseness but it remains effective.

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 detailed return specification (7 fields with meanings). It covers staleness tiers, default behavior, and performance characteristics. All necessary information for correct invocation is present.

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?

With 0% schema description coverage, the description compensates fully. It explains the 'action' parameter with a tier mapping, default behavior for unknown actions, and the 'block_on_stale' parameter's effect (hard block vs. warning). This adds essential meaning beyond the bare schema.

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

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

The description clearly states the tool's function: 'Validate that IOC threat intelligence is fresh enough for the named action.' This specific verb-resource combination directly distinguishes it from sibling tools like check_prompt or freshness_limits.

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 instructs 'Call this before any high-risk agent action to ensure the TI snapshot is not stale.' It provides a clear usage context and a detailed action-to-tier mapping, though it does not mention when not to use it or alternatives among 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?

Describes internal mechanism (hash set, sliding window of 3,5,8,10 tokens, SHA256), performance characteristics (sub-1ms, cache warm-up ~300ms), and that it makes no network calls after warm. No annotations provided, so description fully carries the burden.

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?

Well-structured with sections for Args and Returns. While thorough, could be slightly more concise; however, every sentence provides value for agent understanding.

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?

Explains all return fields in detail despite absence of an output schema. Covers latency, cache size, and token offset, ensuring the agent knows exactly what to expect.

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 comprehensively explains each parameter: 'text' as the prompt to check (any length), 'auto_warm' with default True and clear behavior. Adds meaning beyond the schema's minimal property names.

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?

Clearly states it checks prompts for known PROMPT IOC patterns. Distinguishes from sibling tools like check_prompt_batch (batch) and warm_prompt_cache (caching) by positioning itself as the primary real-time endpoint.

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 advises to call it on every user-supplied prompt before passing to the LLM. Provides context for real-time use but doesn't explicitly mention when not to use it (e.g., for batch processing).

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

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

With no annotations provided, the description carries the full burden. It discloses that tokenization overhead is amortized and cache reference is shared, and specifies the return format (one result dict per input). No contradictions present.

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 concise with no wasted words. It includes an Args and Returns section, and each sentence adds unique value (purpose, efficiency, param, return).

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

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

Given the tool's simplicity and the presence of an output schema, the description covers the key aspects: purpose, efficiency benefit, parameter, and return format. It could mention possible limitations like batch size limits, but it is sufficiently complete for effective use.

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

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

Schema description coverage is 0%, so the description must compensate. It describes 'texts' as 'List of prompt strings to check,' which adds minimal meaning beyond the schema type. It does not specify constraints like max length or format, so it is adequate but not rich.

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 'Check multiple prompts for PROMPT IOC patterns in a single call,' specifying a specific verb and resource. It distinguishes itself from the sibling tool check_prompt by highlighting batching efficiency.

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 notes that this batch call is more efficient than a loop of check_prompt, providing clear usage context. However, it does not mention when not to use it or prerequisites, which would push it to a 5.

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

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

With no annotations, description discloses key traits: draining clears buffer by default, subscriptions are independent, and returns detailed info. Does not mention rate limits or auth, but is sufficient for safe usage.

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?

Concise, front-loaded summary, uses clear bullet points for args and returns. Every sentence adds value with no waste.

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?

Description covers return values (since no output schema), both parameters, and core behavior. Lacks mention of error conditions or prerequisites, but is otherwise complete for a simple 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?

Given 0% schema coverage, description fully compensates by explaining subscription_id and drain parameter with default and peek behavior. Adds significant 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?

Description clearly states it drains a stateful subscription's buffer and returns IOCs, with specific reference to subscribe_threats(). Distinguishes from siblings like subscribe_threats or get_new_threats.

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?

Effectively explains when to use the tool (to drain buffer) and the optional behavior of drain. Lacks explicit alternatives or when-not-to-use guidance, but usage is unambiguous.

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

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

No annotations are provided, so the description carries the full burden. It describes the parameters and the return of signatures but does not mention data freshness, pagination behavior, or potential performance implications of requesting all signatures. The mention of a limit parameter provides some 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?

The description is extremely concise with three short sentences, each earning its place: purpose, prerequisite, and parameter explanations. No superfluous text.

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), the description does not need to explain return values. It covers the prerequisite and parameters well. However, it doesn't indicate whether the 'all' signatures claim is subject to pagination beyond the limit parameter, leaving minor ambiguity.

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?

With 0% schema description coverage, the description fully explains both parameters: family_name is an exact name with examples, and limit is constrained to 1-500 with a default of 50. This adds significant meaning beyond the schema's type and default.

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 'Return' and the resource 'threat signatures associated with a known malware family'. It distinguishes itself from siblings like lookup_ioc and list_families by focusing on family-specific threats.

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

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

It explicitly directs the agent to use list_families() first to discover family names, providing clear prerequisite context. However, it does not explicitly contrast with other sibling tools or state when not to use 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?

With no annotations provided, the description carries full disclosure burden. It details detection capabilities, IOC feed checks, and drift tracking, which is stateful. Minor omission: does not explicitly confirm whether external calls are made for IOC lookups, but overall transparent.

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 front-loaded with the main purpose, followed by details in a structured Args/Returns format. It is verbose but every sentence adds necessary detail for a complex tool. Could be slightly more concise, but structure is sound.

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 3 parameters (one nested), the description adequately covers return fields, drift behavior, and IOC matching. It does not specify error conditions or handling of malformed inputs, but overall complete for the tool's complexity.

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

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

Schema coverage is 0%, so description must compensate. It explains the tool_def parameter's expected keys and mentions registry and track with defaults. This adds value beyond the raw schema, but the explanation of tool_def is minimal and does not cover nesting or optional substructure.

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 starts with a specific verb and resource: 'Analyze an MCP tool definition for instruction-injection and malicious patterns.' It clearly states the tool's function and distinguishes it from siblings like check_prompt or lookup_ioc, which handle different inputs.

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

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

The description implies usage context (when you have a tool definition to evaluate) and explains parameters and return values, but does not explicitly state when not to use it or provide direct comparisons to 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?

With no annotations, the description carries the full burden. It reveals that the tool shows max staleness, warn threshold, and tier-action mappings. However, it does not disclose potential side effects, data source, or performance implications, which are minimal for a read-only retrieval.

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

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

Three concise sentences, each adding value: main action, detailed output, and usage guidance. No redundant information is present.

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 explains what will be returned (staleness, thresholds, tier actions) and references a sibling tool for context. It could mention output format but is otherwise complete for a simple retrieval 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 no parameters with 100% coverage from the schema itself. Baseline is 3. The description does not add parameter information, which is acceptable since none exist.

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

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

The description clearly states it returns IOC freshness limits for all action tiers, using a specific verb ('Return') and resource ('configured IOC freshness limits'). It distinguishes itself from sibling check_freshness by providing configuration 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 explicitly advises using this tool to understand when check_freshness() will warn or block, providing clear context and a direct reference to a related sibling tool. It lacks explicit when-not-to-use guidance but is sufficient.

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

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

With no annotations, the description fully discloses behavior: zero-polling, server-maintained subscription, buffer draining, and parameter effects. Also explains return status push_active.

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?

Well-structured with three paragraphs: purpose, usage, details. Informative without being verbose. Minor room for tighter phrasing.

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?

Fully explains all return fields (signatures, count, buffered, push_active) despite no output schema. Completeness satisfies the tool's simplicity.

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?

Single parameter drain is fully explained: default True clears buffer, False peeks. Schema coverage is 0% (no param descriptions), so description provides all necessary 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?

Clearly states it drains a live push-subscription buffer of threats received since last call. Differentiates from siblings like poll_since by describing the zero-polling mechanism.

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 recommends using this instead of poll_since for sub-second latency without WebSocket maintenance. Lacks explicit when-not to use but provides clear 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?

Reveals output contents but lacks details like read-only nature, permissions, or performance. With no annotations, description carries full burden.

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, front-loaded purpose, no waste.

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?

Covers basic output without output schema. Lacks details on data freshness or format, but acceptable for simple stats.

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; baseline 4 is appropriate. Description adds no parameter info since none exist.

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

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

Description clearly states it returns aggregate statistics and lists included items (signatures, families, agents, detection events). Distinguishes from siblings that perform specific 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?

Implicitly for obtaining overview stats, but no explicit when-to-use or alternatives guidance. Could mention it's a general starting point.

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 carries burden. It states it is a read operation and O(1) lookup, implying no side effects. However, missing details like error handling (if hash is invalid) or permission requirements. 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?

Very concise: three sentences covering purpose, usage, and parameter/returns. Front-loaded with main action and performance. 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?

Simple tool (one parameter, no output schema). Description explains return format (bool + nullable event details). Lacks detail on event object structure, but sufficient for typical use. Could mention error cases, but overall 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?

Input schema only says 'value_hash' with type string. Description adds critical format: 'SHA256 of {ioc_type}:{value.lower()}.' This adds meaning beyond schema (0% coverage) and ensures correct usage.

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 'Check whether an IOC has been revoked' with specific verb+resource. Distinguishes from siblings like 'check_freshness' and 'lookup_ioc' by focusing on revocation status via hash. Performance note 'O(1)' 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?

Explicit guidance: 'Use this before acting on any cached threat intelligence to ensure the IOC has not been retracted since it was loaded.' Clearly states when to use it. Does not mention when not to use or alternatives, but for a focused check tool this is adequate.

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 full burden. It implies read-only behavior by listing families, but does not explicitly state no side effects, rate limits, or authentication needs. Adequate but not detailed.

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 front-loading the main action. No wasted words; 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?

For a parameterless list tool with an output schema, the description fully covers purpose, output, and related tool. No gaps given low 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?

Zero parameters so schema coverage is 100%. Description adds value by explaining output content and linking to the sibling tool, earning baseline 4.

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

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

The description clearly states the tool returns 'all known malware families' and specifies output fields (name, description, category). It distinguishes itself from the sibling 'family_threats' by directing users there for IOC retrieval.

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 guides the user to use 'family_threats(family_name)' for IOCs, indicating a primary use case. Could be improved by stating when not to use this tool, but it effectively differentiates from a key sibling.

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 carries full burden. Mentions ordering and default behavior, but lacks details on side effects, rate limits, or empty results. 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?

Very concise with clear sections (summary, Args, Returns). No unnecessary words, efficient for agent parsing.

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 2-param tool with no output schema, description covers basic functionality. Lacks details on return dict structure 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 has 0% coverage, but description explains each parameter with meaning, defaults, and special values (0 meaning no filter). Adds significant value beyond schema types.

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?

Clearly states 'List recent IOC revocations, newest first.' Identifies verb (list), resource (IOC revocations), and ordering, distinguishing it from siblings like is_ioc_revoked and revoke_ioc.

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?

Does not explicitly state when to use this tool vs alternatives. Parameter descriptions are clear but omitted context like 'for checking a specific IOC, use is_ioc_revoked.'

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 it returns metadata, not the buffered IOCs, and that it lists active subscriptions. No annotations are provided, but the description is transparent about the data scope and non-destructive nature.

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 with the main purpose, followed by additional 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?

For a simple list tool with no parameters and an output schema, the description fully covers what the tool does and its use case.

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?

There are no parameters, so schema coverage is 100%. The description adds no parameter details, but none are needed. Baseline 4 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 (List) and the resource (active stateful push subscriptions on this MCP server instance). It distinguishes itself from siblings like subscribe_threats and unsubscribe by focusing on listing existing subscriptions.

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 when to use: to inspect current subscriptions and their filters. While it doesn't explicitly mention alternatives, the context is clear, and for a zero-parameter tool, this is sufficient.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It states it returns records 'if found' but does not specify behavior on no match (e.g., returns null, empty, or error). No mention of read-only nature, authentication needs, or rate limits. The description is insufficiently transparent about side effects and edge cases.

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

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

The description is concise (under 100 words) and well-structured with a brief summary, a line about return value, and a parameter description. Every sentence provides useful information. Minor issue: a blank line after the title could be considered unnecessary, but overall 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 tool's simplicity (one parameter, no output schema), the description covers the core functionality and parameter. It lacks details on error handling (e.g., not found) and does not contextualize within the sibling tools, but for a straightforward lookup tool, it is nearly complete. Missing edge cases prevent a perfect score.

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

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

Schema coverage is 0%, so the description carries full burden. It adds context by stating the parameter is 'The exact IOC value to search for' and provides an example. This clarifies that the value must be an exact match and gives a concrete example. Could be improved by specifying allowed formats or length limits, but adds significant meaning beyond the raw schema.

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

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

The description clearly states the tool looks up a threat signature by exact IOC value, explaining it returns the full signature record including severity, family, detection count, and false positive votes. This distinguishes it from sibling tools like search_by_type (which likely does fuzzy or partial matching) and is_ioc_revoked (which checks revocation status only).

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 a usage example ('evil.example.com') and implies exact match needed. However, it does not explicitly state when to use this tool versus alternatives (e.g., search_by_type for partial matches, family_threats for family-based queries) or what to do if no match found. Some usage context is present but not exhaustive.

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

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

No annotations are provided, so the description carries the full burden. It discloses the sync pattern, pagination behavior, and parameter ranges. It mentions 'no persistent connection required.' However, it does not discuss idempotency or error handling, which could be valuable for a polling tool. Despite this, the description is quite transparent.

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, starting with the core purpose, then expanding on the sync pattern, and finally listing parameters. It is concise with no redundant sentences, and each 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 simplicity of the tool (3 integer parameters, no output schema), the description is complete. It explains the high-water mark pattern, how to start, how to paginate, and the parameter ranges. The return structure (next_id, count) is implicitly described, which 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?

With 0% schema description coverage, the description adds full meaning for all three parameters via the Args section: last_id (last signature ID seen, persist between calls), batch_size (max signatures 1-5000), min_severity (skip below severity 0-10). This compensates completely for the lack of 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 tool's purpose: 'Fetch new threat signatures since a high-water mark ID.' It specifies the verb 'fetch' and the resource 'threat signatures', and distinguishes it from siblings by calling it the 'recommended sync pattern' and contrasting it with 'no persistent connection required.'

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 usage guidance: start with last_id=0, persist next_id, and call again if count == batch_size. It also advises to disconnect after syncing. This effectively tells the agent when and how to use this tool vs 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?

No annotations provided; description indicates a read-only operation (returns statistics) without addressing side effects or permissions. Slight gap in 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?

Two concise sentences, no wasted words, front-loads the key output and use case.

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 enumerates returned statistics and provides context for its use, making it complete for a zero-param 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?

No parameters, so schema coverage is 100%. Description adds no param info but none 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 states it returns specific cache statistics (size, hit rate, latency, refresh status) and contrasts with check_prompt() for real-time detection, clearly distinguishing its 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?

Explicitly advises using this to verify cache health before relying on check_prompt(), providing clear when-to-use 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?

No annotations provided, so the description must disclose behavioral traits. It only describes the action and parameters, but omits whether the operation is read-only, safe, or has side effects, and does not mention authentication 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 concise and front-loaded with purpose. The Args block is structured. No redundant information.

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

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

Adequate for a simple, read-only tool with output schema present. However, given many siblings, it could provide more context to distinguish its use case.

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 adds parameter details (ranges, defaults, meaning) that are not in the input schema, which has 0% coverage. Both parameters are explained clearly.

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

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

The description clearly states it returns the most recently observed threat signatures, using a specific verb and resource. However, it does not differentiate from sibling tools like 'get_new_threats' or 'family_threats'.

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, no exclusions or prerequisites mentioned.

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

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

With no annotations provided, the description carries full burden. It discloses two categories of flagged tools (high-risk fingerprint and semantic drift), adding behavioral context beyond a simple 'return flagged tools.' No side effects or performance info, but appropriate for a read-only query.

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 filler. Front-loaded with the main purpose, then elaborates with specific categories. 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?

For a zero-parameter read tool with an output schema, the description adequately explains what is returned. Could optionally mention pagination or limits, but output schema likely covers return details.

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

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

Tool has zero parameters and schema coverage is 100%. Description adds value by explaining the two categories of results, which clarifies the return set beyond an empty schema.

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

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

Description clearly states the verb 'Return' and the resource 'MCP tools that have been flagged as suspicious or malicious,' and it distinguishes from siblings like 'recent_threats' or 'get_new_threats' by focusing specifically on flagged 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?

Description implies the tool is for retrieving flagged tools but does not explicitly state when to use it over alternatives like 'recent_threats' or 'get_new_threats.' No when-not or exclusion 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?

No annotations exist, so the description must bear full burden. It discloses the three output statistics but omits whether the operation is read-only, requires permissions, or has side effects. For a zero-parameter tool, this is adequate but minimal.

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 waste. It front-loads the action ('Return') and immediately states the content, making it efficient and scannable.

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

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

For a zero-parameter tool with no output schema, the description covers the purpose and returned statistics. However, it lacks the output format (e.g., JSON structure), which would improve completeness for an agent.

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

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

The input schema has 0 parameters, so schema description coverage is 100%. With no parameters, the description naturally adds no parameter information, earning the baseline score of 4.

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

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

The description uses the specific verb 'Return' and clearly states the resource ('MCP registry monitoring statistics'). It lists three concrete statistics (tool definitions tracked, flagged, drift detection rate), distinguishing it from siblings like 'registry_flagged_tools' and 'get_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 implies usage when needing registry monitoring stats, but provides no explicit when-to-use or when-not-to-use guidance. With 29 sibling tools, the lack of exclusion criteria or alternatives leaves the agent uncertain.

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?

Discloses key side effects: increments detection count and creates a ThreatEvent visible to all agents. However, with no annotations, it omits details on idempotency, permissions, rate limits, 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?

Highly concise: one sentence stating purpose, then bullet-like parameter descriptions. Front-loaded with core verb and resource. No unnecessary text.

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?

Covers purpose, effects, and parameters adequately. Lacks return value/response description and error conditions. Given no output schema, this is a gap 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 coverage is 0% with no parameter descriptions. The description compensates fully by explaining each parameter's purpose, valid values for action (as list), and example content for context dict. Adds significant meaning beyond 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?

Clearly states the tool reports detection and action on a known threat signature, with specific verb and resource. Differentiates from siblings by focusing on detection reporting vs. submission or revocation.

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

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

Provides clear when-to-use: after detecting a known threat signature. Mentions source for signature_id (submit_ioc or lookup_ioc) and lists action options. Lacks explicit when-not-to-use or alternatives like vote_false_positive.

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 carries full burden. Discloses real-time revocation event pushing to active subscriptions and agent behavior. Does not mention authorization or error handling, but main behavioral aspects are covered.

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?

Well-structured with first sentence stating action, then usage guidance, then agent behavior, then parameter details. For its length, it remains clear and front-loaded. Could be slightly more concise but still good.

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?

No output schema specified, but description includes return values (event, pushed). Explains integration with drain_subscription. Lacks error cases or idempotency details, but covers essential behavior for a revocation tool.

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

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

Schema description coverage is 0%, so description must compensate. Args section provides format for value_hash, allowed reason values, and optional ioc_type purpose. Adds significant meaning beyond schema properties.

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 'Revoke an IOC by its value hash' with specific use cases (false positive, expired, superseded). Distinguishes from sibling tools like submit_ioc and is_ioc_revoked.

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 says when to call: 'Call this when an IOC is determined to be a false positive, expired, or superseded.' Also explains effect on subscriptions and agent behavior. Missing explicit alternatives but context 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?

Despite no annotations, the description thoroughly discloses the tool's behavior: it is a read-only analysis function that detects specific malicious patterns, lists detection signals, and returns risk assessments. 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?

Well-structured with clear sections, front-loaded with purpose and usage. Slightly lengthy but every sentence adds value, earning a high score for organization.

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 annotations, low parameter count, and no output schema, the description is remarkably complete: covers purpose, usage, detection logic, all parameters, and return fields comprehensively.

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?

With 0% schema description coverage, the description fully compensates by explaining both parameters (content and source_url) in detail, including their purpose and usage context.

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 as a pre-execution content scanner for skill/instruction files, distinguishing it from siblings by focusing on security scanning and malicious pattern detection before execution.

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 call the tool ('on any skill/instruction content fetched from the web before executing any of its steps') and what action to take if should_block is True. Lacks explicit comparison to sibling tools, but the context is sufficient.

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

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

No annotations provided, so description carries full burden. Describes parameters but not permissions, rate limits, or pagination behavior. Output schema exists, so return format is inferred but not detailed.

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?

Concise and well-structured: first sentence states purpose, followed by usage context, then clear 'Args:' section with parameter details. No unnecessary words. Front-loaded with essential 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?

Covers all parameters thoroughly and hints at use cases. Output schema exists, so return values don't need elaboration. Lacks explicit mention of large result handling beyond 'limit', but acceptable.

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

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

Schema coverage is 0%, yet description compensates thoroughly: lists ioc_type with all allowed values, limit with range (1-1000) and default (50), min_severity with range (0-10) and default (0). Adds significant meaning beyond bare schema.

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

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

Description clearly states 'Return threat signatures filtered by IOC type' and gives concrete examples like 'pull all known-bad IPs, all malicious domains'. Distinguishes from siblings like lookup_ioc (single lookup) and recent_threats (time-based).

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?

Use case is implied with 'Useful for pulling all known-bad IPs...'. Does not explicitly contrast with alternatives, but context with sibling names provides differentiation. Could be improved by stating when not to use (e.g., single lookup).

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 carries full burden. It discloses return structure (one result dict per input in order) and parameter requirements, but does not mention auth needs, rate limits, or side effects.

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

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

Description is concise, well-structured with bullet points and clear sections. Every sentence adds value without repetition 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 tool complexity (batch submission), description covers purpose, usage, parameters, and return format adequately. Output schema exists, so return details are 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 has 0% description coverage; description compensates fully by specifying required keys (ioc_type, value) and listing optional keys (severity, confidence, etc.), adding rich 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?

Description clearly states the tool submits multiple IOCs in one call, and explicitly contrasts with looping submit_ioc for bulk ingest, distinguishing it from its sibling.

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?

Description provides specific use cases (honeypots, sandboxes, feed processing) and implies preferred alternative to submit_ioc for bulk, but lacks explicit when-not-to-use guidance.

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

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

With no annotations, the description discloses auto-classification, compression, deduplication, and instant propagation. However, it does not mention rate limits, authentication needs, or what the return value indicates.

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

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

The description is concise given the number of parameters, with a clear front-loaded purpose and a well-organized Args list. Minor room for improvement in formatting (e.g., bullet points).

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?

Covers purpose, behavior, and parameter details thoroughly. Missing return value specification, which is noticeable for a submission tool with no 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?

The Args section fully explains each parameter with allowable values, examples, and defaults, compensating for the 0% schema coverage. For instance, ioc_type lists all categories and severity includes 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 action (submit) and resource (threat indicator/IOC). While it distinguishes from many siblings, it does not explicitly differentiate from the sibling 'submit_batch'.

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 guidance on when to use this tool vs alternatives (e.g., submit_batch). The description only implies usage for individual IOC submission but lacks when-not-to-use 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?

With no annotations, the description fully handles behavioral disclosure. It states that subscriptions are stateful, isolated per caller, expire after 1 hour of inactivity, and require SSE mode. It also notes that multiple subscribers receive independent copies. This goes beyond annotations and provides important behavioral context.

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: purpose first, then behavior, filters, requirements, and Args/Returns sections. It is somewhat lengthy but every sentence adds value. No redundancy, front-loaded with key info.

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 (stateful subscription, multiple parameters, no output schema), the description is complete. It covers purpose, usage pattern, parameter details, behavioral traits, prerequisites (SSE mode), and return values (subscription_id, push_active, filters). An agent can correctly invoke this tool.

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

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

Schema description coverage is 0%, so description must compensate. It does so excellently: explains min_severity (0-10, default 5), lists valid ioc_types with examples, and clarifies that empty arrays mean 'all'. This adds significant 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 tool opens a named, stateful subscription to live threat push delivery. It distinguishes from siblings by detailing how the subscription ID is passed to drain_subscription() for IOC collection, and mentions unsubscribe as a sibling. The verb 'subscribe' and resource 'threats' are specific.

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 start a subscription for live threats) and provides lifecycle context (returns subscription_id, pass to drain_subscription, expires after 1 hour). It does not explicitly contrast with alternatives like poll_since or get_new_threats, but the context is clear enough for an agent to decide.

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 solely covers behavioral traits. It discloses that the cancellation frees buffer memory, returns status ('ok' or 'not_found'), and reports drained count. It also mentions auto-expiry, indicating idempotency. Could additionally note if it's reversible or affects other subscriptions.

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

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

The description is concise: a one-line action statement, a usage sentence, and a script-style Args/Returns section. Every sentence adds value, and the structure is clear and scannable.

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 tool with one required parameter and no output schema, the description covers the purpose, usage context, parameter source, return values, and auto-expiry behavior. It feels complete and self-contained.

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 provides only the parameter name and type. The description adds valuable context by specifying that the subscription_id is 'The ID returned by subscribe_threats()', linking it to a sibling tool. This compensates for the 0% schema description 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 uses the specific verb 'Cancel' and the resource 'stateful subscription', with the added detail 'free its buffer'. This clearly defines the tool's action and distinguishes it from sibling tools like subscribe_threats (which creates) and drain_subscription (which might not cancel).

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 'Call this when you no longer need the subscription to release memory', providing clear guidance on when to use. It also notes auto-expiry after 1 hour, implying an alternative scenario. However, it does not directly compare to sibling tools like drain_subscription or list_subscriptions.

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 full burden. It clearly discloses synchronous behavior, the check against threat feed, and the return decision structure (allow/warn/block). It does not mention potential side effects like logging, but for a read-like operation this is acceptable.

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 concisely structured: a core purpose sentence, followed by parameter details and return fields. Every sentence adds value with no redundancy. Front-loaded with the most critical 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 no output schema and 0% schema coverage, the description adequately covers input parameters and return structure. It lacks error handling details (e.g., what if hash is unknown and no manifest_url), but overall provides sufficient context for 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 0%, so the description must compensate. It explains each parameter's purpose and ordering preference (hash as identifier, name for logging, url as fallback). This adds meaningful context beyond the bare parameter names.

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

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

The description clearly states the tool's purpose: synchronous SKILL IOC lookup pre-invocation. It uses specific verbs ('lookup', 'check') and resources ('Nullcone threat feed'), and distinguishes itself from siblings by positioning as a pre-invocation enforcement hook.

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 says to call this tool before loading or invoking any MCP tool/skill, providing clear context. However, it does not mention when not to use it or contrast with alternative sibling tools like 'scan_skill_content' for deeper analysis.

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?

Discloses the threshold effect (flag becomes True after 20% votes) and that it's a vote, not an immediate ban. No annotations exist, so description carries full behavioral burden and does so adequately.

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 plus an Args list—concise and front-loaded. Could be slightly tighter by removing 'Args:' subheader, but overall 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?

Covers purpose, behavior, and parameters adequately for a simple voting tool. Lacks return value description, but output schema is absent and tool may not require it.

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

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

Schema coverage is 0%, but description adds meaning for both parameters: signature_id as the target ID and reason as optional explanation. However, explanations are minimal and don't include constraints like ID format or reason length.

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 'Flag a threat signature as a likely false positive,' specifying verb and resource. It distinguishes from sibling tools like report_detection or revoke_ioc by its voting mechanism.

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 context that a 20% voting threshold triggers the is_likely_fp flag, helping agents understand when the tool's effect materializes. Lacks explicit guidance on when to choose this over alternatives, but the voting context is clear enough.

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

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

No annotations provided, so the description fully covers behavior: it warms the cache, auto-refreshes every 5 minutes in the background, and returns specific metrics. 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?

The description is concise, front-loaded with the primary action, and includes a clear bulleted list of return fields. Every sentence adds value without redundancy.

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

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

Given the tool has no parameters and no output schema, the description is complete. It explains the purpose, usage, and return values, and fits well within the set of sibling tools.

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

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

There are no parameters, and the schema coverage is 100% by default. The description adds meaning by explaining the tool's purpose and return values, which is sufficient.

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: loading all PROMPT IOCs from SpacetimeDB into an in-memory hash set. It uses specific verbs and a distinct resource, differentiating it from sibling tools that check or query the cache.

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 says to call once at startup or after a major feed update, and explains the benefit (sub-1ms query cache). It implies when to use but does not explicitly state when not to use; however, the context is clear.

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