Nullcone Threat Intelligence

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

With no annotations, the description fully discloses behavior: <1ms latency, no network I/O, default tier for unknown actions, effect of block_on_stale, and full return dict. 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 sections for purpose, usage, tier mapping, args, and returns. Each sentence adds value; 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?

Despite no annotations or output schema, the description covers all behavioral aspects, return details, error handling, and latency, making it fully informative.

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 significant meaning: action parameter is explained with tier mapping and default behavior, block_on_stale is clarified. Compensates fully for missing 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 'Validate that IOC threat intelligence is fresh enough for the named action,' with a specific verb and resource. It distinguishes itself from siblings by focusing on the freshness check for high-risk actions.

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 'Call this before any high-risk agent action' and provides a tier mapping. Doesn't explicitly mention when not to use it, but the guidance is clear enough for most scenarios.

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, but the description fully discloses behavioral traits: in-memory hash set, sliding window approach, sub-1ms latency when cache is warm, cache warming behavior, and detailed return fields. 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 sections and front-loaded purpose. Slightly verbose in explaining the algorithm, but every sentence adds value. Could be trimmed slightly without losing clarity.

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?

Thorough explanation of input parameters, return fields, and internal mechanics. Despite no output schema, the description details all return fields adequately. Complete for a tool of this complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It clearly explains 'text' as the prompt to check and 'auto_warm' with its effect (~300ms first call), adding 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 checks a prompt for known PROMPT IOC patterns. It is specific about the resource (prompt or text fragment) and the verb (check), and distinguishes from siblings like check_prompt_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?

Explicitly instructs to 'Call it on every user-supplied prompt before passing to the LLM,' providing clear when-to-use guidance. It also positions itself as the primary real-time endpoint, hinting at 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, so description carries full burden. It describes the batch processing behavior and output ordering, but could be more explicit about safety (e.g., read-only). The 'check' verb implies non-destructive, but not stated.

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

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

Description is succinct, front-loaded with purpose, then efficiency rationale, then args and returns. 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 single-parameter batch tool with an output schema, the description covers input, behavior, output order, and efficiency justification. Could mention error handling, 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?

The schema coverage is 0%, but the description provides clear parameter semantics: 'texts: List of prompt strings to check' adds meaning beyond the schema's type definition.

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 checks multiple prompts for PROMPT IOC patterns in a single call. It distinguishes from the sibling tool check_prompt by highlighting efficiency and amortization.

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 guidance on when to use: more efficient than calling check_prompt() in a loop, with tokenization overhead amortized and shared cache reference.

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?

Given no annotations, the description handles transparency well, explaining stateful nature, subscription independence, drain behavior (clear or peek), and background push. It lacks permissions or rate limits, but covers key traits.

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 a one-sentence summary, two args explained in minimal words, and four bullet points for returns. Every sentence earns its place 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?

The description covers tool purpose, parameters, and return values thoroughly for a tool with 2 params. It lacks error handling or edge cases, but is largely complete for typical 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?

With 0% schema coverage, the description fully explains both parameters: subscription_id links to subscribe_threats, drain with default true and the option to peek. This adds critical meaning beyond the empty schema.

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

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

The description clearly states the tool drains the buffer of a stateful subscription created by subscribe_threats(). It specifies the verb 'drain' and the resource 'buffer of a stateful subscription', and distinguishes from siblings by linking to subscribe_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?

The description explains the drain parameter and that draining is for consuming IOCs, but does not explicitly state when to use this tool versus alternatives like get_new_threats or poll_since. No usage exclusions are provided.

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

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

With no annotations, the description carries the full burden. It states it returns 'all threat signatures' but with a limit, implying it may be truncated. It does not disclose ordering, error handling, or rate limits. Basic transparency is present but lacks depth for a query tool.

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

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

The description is concise with no unnecessary words. It front-loads the purpose, provides usage guidance, and explains parameters in a structured manner. Every sentence adds value.

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

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

Given the tool's simplicity (2 parameters, simple query) and the presence of an output schema, the description is complete. It covers purpose, prerequisite, parameter details, and implicit behavior, leaving no major gaps.

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

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

The description adds significant value beyond the schema: it specifies that family_name is an 'Exact malware family name' with examples (e.g., 'emotet'), and limit is 'Max results to return (1-500). Default 50.' This covers constraints, examples, and valid ranges.

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', and specifies the condition 'associated with a known malware family'. It distinguishes itself from siblings like list_families (which lists family names) and lookup_ioc (which looks up by indicator).

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 to 'Use list_families() first to discover available family names', providing clear prerequisite guidance. It implies when to use this tool and mentions the limit parameter, though it does not explicitly exclude alternative scenarios.

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 full burden. It thoroughly discloses behavioral traits: semantic fingerprinting for specific malicious patterns, IOC feed checks, drift detection when track=True, and return fields. No contradictions or missing safety information.

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 and front-loaded with the main purpose. It uses paragraphs and a 'Returns' section. While it is somewhat lengthy, every sentence adds value. Minor point: could be slightly more concise, but it is clear and organized.

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

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

Given the tool's complexity (3 parameters, no output schema), the description is comprehensive. It covers tool purpose, parameter details, return fields (including risk score, signals, drift), and behavioral context. No missing critical information for an AI agent to use correctly.

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

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

The input schema has 0% description coverage (only titles and types). The description compensates fully by explaining each parameter in the 'Args' section: tool_def (keys expected), registry (allowed values), and track (drift detection behavior). This goes well 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's purpose: 'Analyze an MCP tool definition for instruction-injection and malicious patterns.' It specifies the verb ('analyze'), resource ('MCP tool definition'), and the specific analysis domain, distinguishing it from sibling tools that focus on prompts, IOCs, or 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?

The description implies usage: if you have a tool definition and want to assess its risk, use this tool. However, it does not explicitly state when to use it versus alternatives, nor does it provide when-not-to-use guidance. The context of siblings is not leveraged in the description.

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 fully carries the burden of behavioral disclosure. It clearly states the tool returns configured limits and includes details about the output (max staleness, warn threshold, actions per tier). There are no side effects mentioned, but none are expected for a read-only operation.

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

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

The description is three sentences long, each sentence providing essential information: what it does, what it shows, and how to use it. It is front-loaded with the main purpose and contains no unnecessary words.

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

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

Given no output schema, the description adequately explains the return value by listing the key fields (max staleness, warn threshold, actions per tier). It also contextualizes the tool within the sibling set by referencing check_freshness. This is complete for a simple getter 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 parameter count is 0, so the baseline is 4. The description does not need to add parameter information, and it correctly focuses on the output.

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 configured IOC freshness limits for all action tiers, specifying that it shows max staleness, warn threshold, and actions per tier. It distinguishes from the sibling check_freshness by explaining its use in understanding when check_freshness will warn or block.

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 use this tool to understand when check_freshness() will warn or block, providing clear context for when to invoke it. While it does not list alternative tools for comparison, the link to check_freshness is strong 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?

Describes delivery mechanism (SpacetimeDB WebSocket subscription, server-side buffering) and drain behavior. However, does not mention prerequisites (e.g., active subscription needed) or potential side effects. Without annotations, the burden is higher, but the description is mostly thorough.

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 yet complete. Front-loaded with purpose, then usage, then Args and Returns. No redundant sentences.

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, usage, parameter, and return fields thoroughly. Lacks error handling or prerequisite info, but adequate for 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?

Schema coverage is 0%, so description must explain parameters. The 'drain' parameter is explained: default true clears buffer, false peeks. Adds full semantic meaning beyond 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 action ('drain'), resource ('live push-subscription buffer of threats'), and mechanism ('zero-polling', 'WebSocket subscription'). It distinguishes itself from siblings like 'poll_since' and 'drain_subscription'.

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 when to use this tool instead of 'poll_since()' for sub-second latency, and contrasts with maintaining a WebSocket connection. This provides clear usage context and an alternative.

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 that the tool returns aggregate statistics and lists included items, implying a read-only operation. However, it does not mention auth requirements or rate limits, but for a simple read tool this is 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?

Two concise sentences with no waste. Every detail earns its place.

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

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

For a tool with no parameters and no output schema, the description fully explains what it returns and the included statistics. No gaps.

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

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

Zero parameters, and description does not need to add parameter info. Schema description coverage is 100% (empty). Baseline score of 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?

Clearly states verb 'Return' and resource 'aggregate statistics'. Distinguishes from siblings like list_families and recent_threats, which target specific subsets.

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?

Implied usage as the go-to for overall stats, but no explicit when-to-use or alternatives. Siblings are more specific, so context is clear but lacks explicit guidance.

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

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

No annotations are provided, so the description carries full burden. It discloses the performance characteristic (O(1) in-process lookup) and explains the return structure. It does not detail auth requirements or side effects, which are minimal for a read-only lookup.

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, three short paragraphs that front-load the purpose, then provide usage guidance, then parameter/return details. Every sentence serves a purpose with no filler.

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

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

For a simple one-parameter tool with no annotations or output schema, the description is complete. It covers what the tool does, when to use it, parameter details, and return format. No further information is necessary.

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

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

The single parameter 'value_hash' is well explained: it is a SHA256 hash of {ioc_type}:{value.lower()}. The schema only gives a title, so the description adds critical meaning on how to construct the hash, fully compensating for zero schema coverage.

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

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

The description clearly states the tool checks whether an IOC is revoked, using a specific verb and resource. It distinguishes from siblings like 'lookup_ioc' and 'revoke_ioc' by noting it's an O(1) in-process lookup for revocation status.

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 to use this before acting on cached threat intelligence, providing clear context for when to invoke the tool. It does not explicitly list when not to use it, but the context and sibling tools make alternatives obvious.

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 burden. It clearly states the tool returns all families with name, description, and category, implying a read-only operation. It does not mention potential pagination or performance, but for a parameterless tool it is sufficiently 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?

Two concise sentences: the first states the primary action, the second adds output details and a pointer to the related sibling tool. 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 no parameters and an existing output schema, the description fully covers what the tool does, what it returns, and how it relates to family_threats. No gaps.

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

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

There are no parameters, so baseline is 4. The description adds context by stating 'all known malware families,' which defines the scope and purpose, exceeding the baseline.

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, with specifics on what each entry includes. It also differentiates from the sibling tool family_threats by mentioning that family_threats retrieves IOCs for a specific family.

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 use family_threats(family_name) for IOCs linked to a specific family, giving clear guidance on when to choose this tool versus an alternative.

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, but the description implies a read-only operation by listing revocations. It explains return structure (revocations, total, stats) but lacks details on side effects, authentication needs, or rate limits. Adequate but not thorough.

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 structured with Args and Returns sections, but the Arg list could be slightly more concise. Main purpose is front-loaded. 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 2 parameters, no required params, no output schema, the description adequately covers return fields and parameter effects. No gaps for a simple list 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 has 0% description coverage; the description fully explains both parameters: limit (max number, default 50) and since_hours (time filter, 0 means no filter). This adds significant meaning beyond the schema's type/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 tool lists recent IOC revocations with newest first ordering. While it distinguishes the core action, it doesn't explicitly differentiate from sibling tools like revoke_ioc or is_ioc_revoked, but the purpose is unambiguous.

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

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

The description implies usage for fetching recent revocations but provides no guidance on when to use this tool vs alternatives (e.g., get_stats, recent_threats). No explicit when-not or context for selection.

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

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

Read operation described; states returns metadata not IOCs. No annotations provided, so description covers safety profile adequately, but could mention pagination or authentication.

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

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

Two sentences, front-loaded with action and resource, then details. No wasted words.

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

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

For a zero-parameter tool with output schema, description covers purpose, scope, and return type, providing sufficient completeness.

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

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

No parameters; baseline 4 is appropriate as description does not need to add param info.

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

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

Description clearly states verb 'List' and resource 'active stateful push subscriptions' with instance scope, distinguishing it from sibling tools like subscribe_threats or unsubscribe.

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?

Implied usage for inspecting subscriptions, but no explicit when-to-use or when-not-to-use guidance, and no alternatives 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 must carry the full burden of behavioral disclosure. It does not explicitly state that the tool is read-only or non-destructive, and lacks details on authorization 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 very concise: two sentences plus an Args line, front-loaded with purpose, no unnecessary words.

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

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

Without an output schema, the description explains the return fields (severity, family, etc.), but lacks error cases or authorization context. Adequate for a simple lookup but not fully comprehensive.

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 adds meaningful context: the parameter 'value' is described as 'the exact IOC value to search for' with an example, clarifying syntax 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 verb ('Look up') and resource ('threat signature by its exact IOC value'), distinguishing it from sibling tools like 'submit_ioc' or 'revoke_ioc' which write or delete.

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 an exact IOC value is known, but does not explicitly discuss when to prefer this tool over alternatives like 'search_by_type' or 'family_threats', nor provides 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, the description fully describes behavior: fetching new data, high-water mark pattern, no persistent connection required, and pagination. Could mention authentication or side effects, but sufficient for a read-like operation.

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?

Front-loaded with one-sentence summary, followed by well-organized usage pattern and parameter details. Every sentence provides value; 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?

Covers the sync pattern, parameters, and pagination loop. No output schema, but description doesn't detail return fields (next_id, count, signatures). Still complete enough for this 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 carries full burden. It explains each parameter in detail: last_id (persist between calls), batch_size (1-5000), min_severity (0-10 filter). Adds significant value 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?

The description clearly states 'Fetch new threat signatures since a high-water mark ID', providing a specific verb and resource. It distinguishes itself from siblings by being the recommended sync pattern.

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 describes when to use (recommended sync pattern), workflow (call with last_id=0, persist next_id, disconnect), and how to handle pagination (call again if count == batch_size). No explicit exclusions, but very clear 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 are provided, so the description must convey behavior. It clearly indicates a read-only operation returning statistics, with no mention of side effects or destructive actions. This is sufficient for a query tool.

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

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

Two sentences cover purpose and usage without extraneous detail. The first sentence lists returned fields, and the second provides a clear use case. Every word is useful.

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 what is returned (four stats) and when to use it (before check_prompt). No additional information is needed.

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

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

The tool has zero parameters, and the schema coverage is 100%. The description adds no parameter information, which is acceptable since there are no parameters to document.

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 PROMPT IOC cache statistics including specific fields (size, hit rate, latency, refresh status). It distinguishes itself from the sibling 'check_prompt' tool by mentioning its role in verifying cache health before real-time detection.

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 verify cache warmth before relying on 'check_prompt()', providing clear context. However, it does not explicitly state when not to use it or mention alternative tools for other purposes.

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 implies a read operation ('Return'), but with no annotations, it fails to disclose behavioral traits such as required permissions, rate limits, or whether it is destructive. The documentation is 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 extremely concise with a single front-loaded sentence and two argument descriptions. Every piece of text is essential and there is no 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 low complexity of the tool (2 simple params, output schema exists), the description is minimally adequate but lacks context on what constitutes a 'threat signature' or the recency window. It could be more complete for novice users.

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 meaning to the parameters by specifying the valid range for limit (1-200) and min_severity (0-10, default 5), which the schema does not provide. However, it does not explain the meaning of severity or other possible constraints.

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, which is a specific verb and resource. It distinguishes from sibling tools like family_threats or get_new_threats by focusing on recency and threat signatures.

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. There is no comparison to related siblings, nor any indication of prerequisites or limitations.

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 description carries full burden. It reveals the tool returns flagged tools and includes two criteria, but lacks details on authorization, rate limits, output pagination, or whether the list is dynamic. For a zero-parameter tool, this is adequate but not rich.

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

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

Two concise sentences, front-loaded with the core action, no redundant or extraneous 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?

With no parameters and an output schema present, the description adequately explains the return content. Minor gap: terms like 'high-risk fingerprint' and 'semantic drift' are not defined, but overall sufficient given tool 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?

Schema coverage is 100% (no parameters). Baseline 3 applies because description cannot add beyond what schema already provides regarding parameters.

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

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

The description clearly states the tool returns all MCP tools flagged as suspicious or malicious, and specifies two categories of flagged tools. It effectively distinguishes from sibling tools like 'check_freshness' or 'check_prompt' which serve different purposes.

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

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

The description implies usage for retrieving flagged tools but provides no explicit guidance on when to use this tool versus alternatives like 'family_threats' or 'recent_threats'. No when-not-to-use advice is given.

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

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

No annotations are provided, so the description must fully disclose behavior. It states the output but omits side effects (likely none), performance characteristics, or any constraints. For a monitoring tool, details like cost or freshness implications are missing.

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

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

Three short sentences, each providing essential information without redundancy. The main purpose is front-loaded, and the text is 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?

The description covers the primary return items but lacks detail on response format, potential errors, or whether additional stats exist. Without an output schema, more explicit structure would improve completeness.

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

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

There are no parameters, so the schema is fully covered. The description adds value by explaining that the tool returns three specific statistics, giving context to the zero-argument call. Baseline for 0 params is 4.

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

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

The description clearly states the tool returns registry monitoring statistics and lists specific data points (tracked definitions, flagged count, drift detection rate). The verb 'Return' and resource 'MCP registry monitoring statistics' are specific and 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?

No guidance on when to use this tool vs. siblings like 'get_stats' or 'registry_flagged_tools'. The description does not differentiate usage context or mention 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?

The description discloses key behaviors: increments the signature's detection count and creates a ThreatEvent visible to all agents. With no annotations provided, this information is essential. It does not cover authorization or rate limits, but the behavioral details are 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 concise, with a short introductory sentence followed by a clear list of parameter explanations. Every sentence adds value, and there is 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?

The description covers purpose, parameters, and side effects well. However, it does not specify the return value or response format (e.g., whether an ID or confirmation is returned). Since there is no output schema, a brief note on the return would improve completeness. Overall, it is nearly 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?

The description provides detailed meaning for all three parameters beyond the schema, which has 0% description coverage. It explains signature_id's origin, lists allowed actions for action, and describes context as an optional dictionary for additional info. This adds substantial value.

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: 'Report that you detected and acted on a known threat signature.' It specifies the verb (report) and resource (detection on a known signature), and distinguishes from sibling tools like submit_ioc by noting that signature_id comes from such 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 description implies prerequisites by stating signature_id is from submit_ioc or lookup_ioc, but does not explicitly state when to use this tool versus alternatives or when not to use it. It lacks clear a usage context beyond the basic action.

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 explains the behavior: pushing expiration events to active subscriptions in real-time and the subscriber received mechanism. It details return values (event and pushed count). It could mention side effects like irreversibility, but is mostly 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 with a clear action statement, usage guidance, parameter details, and return explanation. It is slightly lengthy but each sentence adds value; no wasted words.

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

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

Given the complexity of revocation with subscriber notifications and no output schema, the description covers the parameter semantics, return values, and behavioral effects. It could mention error conditions or what happens if the value_hash is invalid, but overall it is complete.

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

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

The input schema has 0% description coverage, so the description adds crucial meaning: the format of value_hash (SHA256 of ioc_type:value.lower()), an explicit list of valid reasons, and the purpose of ioc_type (optional filtering for subscribers). This goes well beyond what the schema provides.

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 'Revoke' and the resource 'an IOC by its value hash', and distinguishes this action from sibling tools like 'is_ioc_revoked' (check) and 'submit_ioc' (creation). The mention of real-time push to subscriptions differentiates it further.

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 when to call the tool: 'when an IOC is determined to be a false positive, expired, or superseded.' It provides clear context but does not mention when not to use or suggest alternatives, such as using 'is_ioc_revoked' for checking revocation status.

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 and excels. It details the analysis scope (malicious patterns), detection signals (e.g., download-and-execute chains, credential access patterns), and return fields including 'risk', 'should_block', 'kill_chain', and 'signals'. There is no contradiction with annotations.

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

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

The description is appropriately sized and well-structured: purpose upfront, usage instruction, detection signals, then structured Args and Returns sections. Every sentence adds value, with no fluff or repetition.

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

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

Given the tool's complexity (security scanning) and the absence of an output schema, the description is remarkably complete. It explains the tool's importance, when to use it, parameters, and a detailed return structure (risk, should_block, signals, etc.), leaving no gaps for an AI agent to misuse.

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

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

The input schema has 0% description coverage (no titles/descriptions), but the description provides full semantic meaning for both parameters: 'content' as 'Full text content of the skill file' and 'source_url' as 'URL where the skill was fetched from (for reporting)'. This compensates completely for the schema gap.

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

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

The description clearly states the tool's purpose: 'Pre-execution content scan for skill/instruction files' and specifies it analyzes for malicious patterns before execution. It distinguishes itself by focusing on security scanning against 'remote skill-mediated credential exfiltration', differentiating from sibling tools like 'check_prompt' or 'validate_skill'.

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 when to call this tool: 'Call this on any skill/instruction content fetched from the web before executing any of its steps.' It also instructs to 'refuse to proceed' if 'should_block is True'. However, it does not mention when not to use it or provide explicit comparisons to alternative 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?

No annotations are provided, so the description must disclose behavioral traits. It explains the filtering behavior and parameters but does not mention side effects, permissions, rate limits, or output structure.

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

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

The description is concise and well-structured: one sentence for purpose, then a clear list of arguments with details. 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?

Given the existence of an output schema, the description covers the tool's purpose and parameters adequately. It could mention ordering or pagination, but is otherwise complete for a 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?

With 0% schema description coverage, the description fully explains each parameter: ioc_type with valid values, limit with range and default, min_severity with range and default, adding significant value beyond the schema.

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

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

The description clearly states it returns threat signatures filtered by IOC type, with specific examples like IPs and domains, distinguishing it from sibling tools that serve different purposes.

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

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

The description provides usage context by mentioning it is useful for pulling all known-bad IPs or domains, but lacks explicit when-to-use or when-not-to-use guidance relative to 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 are provided, so the description must fully disclose behavior. It mentions the return format (one result dict per input in order) but does not discuss side effects like creation of IOCs, idempotency, authentication requirements, or error handling. This is adequate but lacks depth.

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

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

The description is concise with three sentences covering purpose, usage distinction, parameter details, and return format. It is front-loaded with the main point and uses efficient structure (args list-style). No redundant or vague wording.

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

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

Given the parameter complexity (array of objects) and existence of an output schema (not provided), the description adequately covers parameter structure and return behavior. However, it omits constraints like maximum batch size, error handling, or concurrency limits, which would enhance completeness for a batch 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 0% coverage (array of objects with no defined properties), so the description is essential. It explicitly lists required keys (ioc_type, value) and optional keys (severity, confidence, etc.), providing critical meaning that the schema lacks. This fully compensates for the schema gap.

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

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

The description clearly states the tool submits multiple IOCs in a single call and explicitly distinguishes it from the sibling tool submit_ioc by positioning it as the preferred method for bulk ingest. The verb 'Submit' and resource 'multiple IOCs' are specific and unambiguous.

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

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

The description explicitly recommends this tool over looping submit_ioc for bulk ingest from honeypots, sandboxes, or feed processing. It provides clear usage context but does not mention when not to use it or any exclusions, leaving some room for improvement.

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 automatic classification, metadata compression, deduplication, and instant propagation. However, it does not explain the return value, error handling, or side effects. With no annotations, more detail on behavior would be beneficial.

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

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

The description is concise and well-structured: a brief introductory paragraph summarizing the tool's effect, followed by a clear Args list. 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?

The description covers all parameters but lacks information about return value or output behavior. With no output schema, the agent needs to know what happens after submission. It also does not contrast with submit_batch.

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?

Despite 0% schema description coverage, the description's Args section thoroughly explains each parameter: ioc_type lists all allowed values, severity maps to enums, confidence range, and optional fields. This fully compensates for the schema gap.

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

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

The description clearly states 'Submit a threat indicator (IOC) to the shared intelligence network' and explains automatic classification, making the purpose specific. However, it does not explicitly differentiate from sibling tools like 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?

The description provides no guidance on when to use this tool vs alternatives (e.g., submit_batch). It does not mention prerequisites, when not to use, or typical scenarios.

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 fully carries the burden. It discloses key behaviors: stateful subscription, isolated streams per caller, expiration, composition filters, and required server mode. No contradictions or hidden traits.

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 clear sections (purpose, behavior, filters, args, returns). It is front-loaded and each sentence adds value. Slightly long but justified by the complexity of the tool.

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?

Despite no output schema, the description thoroughly explains what is returned (subscription_id, push_active, filters) and all critical behaviors. No gaps left for typical usage scenarios.

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 the description explains each parameter with defaults, valid values for ioc_types (enumerated list), and semantics for families and tags. This adds substantial 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 it opens a named, stateful subscription to live threat push delivery, with specific verb 'subscribe' and resource 'threats'. It distinguishes from sibling tools like drain_subscription, unsubscribe, and polling tools, making its unique function evident.

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

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

The description provides clear context: when to use (to receive live IOCs), expiration after 1 hour inactivity, and requirement for SSE mode. It implies alternatives (e.g., polling vs. subscription) but doesn't explicitly state when not to use it or list direct alternatives. Still strong 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 carries full burden. It discloses the cancellation, buffer freeing, return values (status, drained), and auto-expiry. This is thorough for a simple tool.

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

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

The description is concise, with clear sections for args and returns. Every sentence adds value, no wasted words.

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

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

For a single-parameter tool with no output schema, the description covers the return values and side effects thoroughly. It is 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 coverage is 0%, so description compensates. It explains 'subscription_id: The ID returned by subscribe_threats()', adding meaning beyond the schema's 'Subscription Id'.

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 'Cancel a stateful subscription and free its buffer.' It uses a specific verb and resource, and distinguishes from sibling tools like 'drain_subscription' and 'list_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 explicitly says 'Call this when you no longer need the subscription to release memory' and mentions auto-expiry as an alternative. It provides clear context but does not explicitly state when not to use.

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

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

With no annotations, description carries full burden. Discloses synchronous nature, return values (risk, action, confidence, etc.), and role as enforcement hook. Minor gap: no mention of side effects or potential rate limits, 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?

Front-loaded with purpose, then usage context, parameter list, and return details. Every sentence is necessary and well-structured. No 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?

Despite no output schema, the description fully documents return fields. Covers all 3 parameters and overall workflow. Complete for a validation tool with no missing 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 has 0% parameter description coverage; description fully compensates by explaining skill_hash as SHA256, skill_name for logging, and manifest_url as fallback. Adds essential meaning beyond schema titles.

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?

Explicitly states the tool performs a synchronous SKILL IOC lookup for pre-invocation enforcement. Distinguishes from sibling tools by specifying it is a pre-invocation hook against the Nullcone threat feed.

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?

Clearly instructs to call before loading or invoking any MCP tool/skill. Provides context but does not explicitly exclude scenarios or name alternative tools, though the overall purpose is well-defined.

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 explains the threshold effect (20% votes) and the resulting flag, but lacks details on whether votes are reversible, anonymity, authentication requirements, or rate limits. 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?

The description is brief and front-loaded with the main action. Every sentence provides value: the header, the threshold explanation, and the parameter list. No redundant or vague statements.

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 voting tool with 2 parameters and no output schema, the description covers the essential behavior. Minor gaps: no mention of return value, confirmation, or idempotency. Still sufficient 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?

Schema description coverage is 0%, so description must explain parameters. It clearly states signature_id is 'ID of the ThreatSignature to flag' and reason is 'Optional explanation for the vote', adding value beyond the schema. Does not mention the default empty string for reason, but acceptable.

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 ('Flag a threat signature as a likely false positive') and specifies the resource (threat signature). It also explains the threshold behavior (20% agents vote triggers is_likely_fp flag), which distinguishes it from sibling tools like report_detection or 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?

The description implies usage when a user suspects a false positive, but does not explicitly state when not to use this tool or provide alternatives. No direct comparison with sibling tools or exclusions for specific scenarios.

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 carries full burden. It discloses that the cache auto-refreshes every 5 minutes, and that the tool populates memory. Returns are specified (loaded count, duration, window sizes). No contradiction with annotations (none exist).

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

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

Concise and well-structured: first line states purpose, second gives usage guideline, third describes auto-refresh, then a bulleted list of returns. Every sentence adds value.

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

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

Given no output schema and no annotations, the description fully covers what the tool does, when to use it, and what it returns. For a cache-warming tool with zero parameters, no additional information is needed.

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

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

The tool has no parameters, so schema coverage is 100% by default. The description adds value by explaining the return fields, which are not in an output schema. Without params, a baseline of 4 is appropriate.

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

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

The description clearly states the tool loads PROMPT IOCs from SpacetimeDB into an in-memory hash set. It distinguishes itself from sibling tools like check_prompt by noting this is a cache-warming operation.

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 tells when to use: 'Call once at startup (or after a major feed update)'. Also explains the benefit (sub-1ms queries) and that subsequent check_prompt calls need no network.

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