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

With no annotations, the description carries the full burden and discloses key behavior: periodic re-scanning and flagging of threat-status changes. It doesn't cover auth requirements, rate limits, or whether additions are idempotent, which limits it from a 5.

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

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

Two sentences with zero waste; the behavioral trait (periodic rescan / change flagging) is front-loaded immediately after the core action.

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?

Complete enough for a 3-parameter mutation tool: it explains the watch-list mechanism and what the tool will do over time, and an output schema exists so return values need no explanation. It could be richer on auth or error behavior, but nothing critical is missing.

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

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

Schema coverage is 100%, so the schema already documents ioc, label, and alert_on (including severity options and defaults). The description adds no parameter-level detail beyond what the schema provides. Baseline 3 applies.

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

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

States a specific verb (Add) and resource (IOC to the real-time watch-list), and contrasts with siblings like analyze_ioc (one-shot) and remove_watch/list_watches (lifecycle counterpart). An agent can identify it as the creation operation for the watch-list without opening the schema.

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

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

The description implies when to use it (to track an IOC over time via periodic re-scan) versus one-shot siblings like analyze_ioc. However, it doesn't explicitly state when not to use it or name the alternatives, leaving some inference to the agent.

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 behavioral burden. It discloses that analysis spans 'all available threat intelligence sources' (implying multiple external lookups), but says nothing about permissions, rate limits, latency, network egress, or how unknown/malformed indicators are handled.

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 short, front-loaded sentences: purpose first, then supported formats. Every line earns its place 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?

An output schema exists, so return-value explanation is not required. However, with zero annotations on a tool that fans out to external intelligence sources, the description omits operational context (external calls, failure/unknown-indicator behavior) that an agent would benefit from.

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

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

Schema description coverage is 100%, so both the 'ioc' and 'include_raw' parameters are already documented in the schema, including the supported formats. The description's list of supported IOC types duplicates rather than extends that, so baseline 3 applies.

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

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

States a specific verb (analyse), resource (Indicator of Compromise), and scope ('a single ... IOC across all available threat intelligence sources'), and the word 'single' implicitly contrasts with the bulk_analyze sibling. It stops short of naming that alternative explicitly, so it is clear but not sibling-differentiating at the highest level.

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 when-to-use guidance is offered: nothing tells the agent when to prefer this over bulk_analyze or detect_iocs_in_text, and no prerequisites or exclusions are stated. Usage is only inferable from the word 'single'.

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 disclosure burden. 'Concurrently' and 'consolidated summary' hint at parallel execution and aggregated output, but there is no information on auth requirements, throttling, partial-failure behavior, or cost, which matter for a 50-item batch 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?

A single front-loaded sentence with no filler; the action, target, and result are stated immediately. Nothing is wasted.

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

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

An output schema exists, so explaining return values is unnecessary, and the schema covers both parameters fully. However, for a batch/concurrent tool with zero annotations, the silence on concurrency limits, error semantics, and sibling choice leaves gaps.

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

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

Schema description coverage is 100%, so both 'iocs' and 'max_concurrent' are already documented in the schema, including the max-50 cap and default of 5. The description adds nothing beyond that, so the baseline of 3 is correct.

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

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

The description gives a specific verb ('Analyse') plus a clear resource ('multiple IOCs') and states the output shape ('consolidated summary'). It implicitly separates itself from the singular analyze_ioc through 'multiple', but never names the sibling explicitly, so differentiation is left to inference.

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

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

There is no when-to-use guidance: nothing says to prefer this over analyze_ioc for batches, nor when a single analyze_ioc call is more appropriate. No mention of prerequisites, rate limits, or failure handling that a batch operation would normally need.

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 behavioral burden. It discloses the extraction scope and IOC types, but omits details such as whether extraction is deduplicated, ordered, limited by input size, or whether auto_analyze triggers side effects.

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

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

The description is a single front-loaded sentence with no wasted words. It states the action, resources, and input context efficiently.

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

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

Given the output schema exists, return values need not be explained. Parameter semantics are covered by the schema, and the description adequately frames the tool's purpose, though it could add more when-to-use guidance for the sibling analysis 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?

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description adds no parameter-specific syntax or behavior beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: extract all IOCs from freeform text. It names the IOC types (IPs, domains, URLs, hashes) and input sources, making it distinguishable from sibling analysis tools like analyze_ioc and bulk_analyze.

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 through examples such as log files, incident reports, and paste-bin content, but it does not explicitly say when to use this tool instead of analyze_ioc or bulk_analyze. No alternatives or exclusions are named.

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 behavioral burden, and it discloses almost nothing beyond 'retrieve'. Critically, mark_read defaults to true, meaning a nominally read-shaped call mutates state (marking alerts read) — the description never warns about this side effect, nor about the default 60-minute window or volume 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?

A single front-loaded sentence with no filler. It is tight, though arguably under-specified rather than genuinely concise for a tool with a mutation side effect.

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

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

An output schema exists, so return values need not be described, and parameter semantics are fully covered by the schema. However, the mark_read write side effect and the relationship to the monitor cycle are absent, leaving the agent with gaps a single sentence could have closed.

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

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

Schema description coverage is 100%, so the schema already documents severity, mark_read, and since_minutes with defaults. The description adds no parameter meaning beyond that, which is the baseline 3 when the schema does the heavy lifting.

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

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

States a specific verb (Retrieve) and resource (alerts) with the source scoped to 'real-time monitor for watched IOCs'. It is understandable on its own, though it does not explicitly distinguish itself from siblings like run_monitor_cycle or list_watches.

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 versus run_monitor_cycle (which presumably produces these alerts) or list_watches. There are no prerequisites, no mention of ordering or freshness relative to monitoring cycles.

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

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

No annotations exist, so the description carries the full disclosure burden. It usefully states that it returns a markdown table including last-known status, but says nothing about permissions, freshness of the status data, or pagination. For a read-only listing tool the risk profile is low, so this is adequate rather than alarming.

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 short sentences, the action front-loaded and the return shape stated second. No filler, no restatement of the title.

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

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

An output schema exists, so the return values need not be spelled out, and with no input parameters the description is nearly complete. The only thin spot is the absence of any usage context, which keeps it short of full marks.

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 takes zero parameters, so there is nothing for the description to disambiguate beyond confirming it is unfiltered. Baseline of 4 applies for a parameterless tool.

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

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

Specific verb ('List') plus a well-scoped resource ('IOCs currently on the watch-list') with the returned attribute (last-known status) named. It is clearly distinguishable from siblings like add_watch, remove_watch, and analyze_ioc, though it never explicitly contrasts itself with them.

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 says what the tool returns but gives no when-to-use guidance, no conditions, and no mention of alternatives such as get_alerts or the watch-modification siblings. The agent must infer the intended invocation context.

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

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

No annotations are provided, so the description bears the full burden. 'Remove' implies a destructive mutation and notes the watch-list is real-time, but it doesn't address reversibility, side effects on active monitoring, or whether removal requires authorization. The output schema is present, but behavioral context for a mutation tool remains thin.

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

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

A single efficient sentence with no waste. It is appropriately sized for a simple one-parameter removal tool, though it could front-load a bit more operational 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?

With an output schema and full parameter coverage, the definition is minimally complete, but for a mutation tool with no annotations it should convey more about effects and prerequisites. It does enough for an agent to act but leaves behavioral questions unanswered.

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

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

Schema coverage is 100%, and the schema itself explains watch_id originates from add_watch or list_watches. The description adds no further parameter detail, so the baseline 3 is appropriate since the schema does the work.

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

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

States a specific verb (remove) and resource (IOC from the real-time watch-list), which clearly distinguishes it from siblings like add_watch and list_watches. The action and target are unambiguous, though it doesn't explicitly reference the sibling relationship.

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

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

There is no explicit guidance on when to use this tool versus alternatives. An agent could infer it's the inverse of add_watch, but the description doesn't say so, and no preconditions or context for removal are given.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose a meaningful side effect — that a manual run re-scans all watches and can produce alerts — but says nothing about cost, rate limits, permissions, or whether it can collide with an in-flight scheduled cycle.

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 tight, front-loaded sentences with no filler, and the trigger semantics come first. The 'Returns:' block is mildly redundant given that an output schema already exists, which keeps it short of a 5.

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 trigger with an output schema, the description covers the only things an agent needs: what it does, that it affects all watches immediately, and that alerts may follow. Nothing essential is missing.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool 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?

States a specific verb and resource ('manually trigger a monitoring cycle') and clarifies scope ('re-scans all watched IOCs'), which separates it from the single-IOC siblings like analyze_ioc. It never names a sibling tool outright, so differentiation is implied rather than explicit.

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

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

The phrase 'rather than waiting for the next scheduled interval' gives a clear condition for reaching for this tool (need an immediate rescan). There is no explicit when-not guidance, no mention of the alternative tools, and no note on whether it should be run alongside a scheduled cycle.

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 behavioral burden. It discloses the return content and format ('Markdown status card'), but does not explicitly state read-only safety, side effects, authentication needs, or rate limits. 'Return' implies a safe read, but this is not made fully explicit.

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

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

The description is two short sentences, front-loaded with purpose and followed by return format. It is appropriately sized and contains no wasted 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 low complexity, empty input schema, and presence of an output schema, the description is nearly complete. It names the included status fields and return format, though it lacks explicit usage routing and safety details.

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

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

The tool has zero parameters, so there are no parameter semantics to document. Per the scoring rule, zero parameters establish a baseline 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?

States a specific verb and resource: 'Return the current ThreatWatch server status.' It also enumerates what the status includes (configured API sources, watch-list size, pending alert count), distinguishing it from sibling tools like analyze_ioc or get_alerts.

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

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

Usage is implied by the status-checking purpose, but the description does not explicitly say when to use this tool versus alternatives or when not to use it. An agent can infer it is for server health/status, but no routing guidance is provided.

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