Rösti Threat Intel

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only that tag values come with descriptions and that the risk scale is explained, which is modest extra context; it says nothing about output size or how the taxonomy is versioned. With annotations carrying the behavioral load, a 3 is appropriate.

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, zero filler: the first enumerates what is returned and the second states the intended use, with the enumeration front-loaded. Every clause 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?

An output schema exists, so the description is not obliged to describe return values and instead summarizes the four content areas at a useful level. For a zero-parameter, read-only reference tool this covers everything an agent needs to call it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly does not waste space on parameter discussion.

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 names a specific verb ("List") plus four concrete resource categories (IOC types, IOC tags with descriptions, IOC categories, export formats) and adds an explanatory component (the false-positive risk scale). That is far more specific than the title alone and no sibling tool covers reference enumeration, so an agent can identify it unambiguously even without an explicit contrast sentence.

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

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

"Use these values for the filters of the search and list tools" tells the agent exactly when to reach for this tool: before filtering via search_iocs, search_reports, list_report_iocs, etc. It gives clear positive guidance but no exclusions or caveats about when this tool is unnecessary.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the result ordering ('most shared IOCs first'), which is genuine behavioral context, but says nothing about edge cases such as reports with no shared IOCs or how ties are broken.

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 tight sentence that front-loads the action and the resource, then adds ordering and return content with no filler. Nothing could be removed without losing 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 only two simple parameters, full schema coverage, present annotations and an output schema, the description covers what the tool does and how results are ordered. Only minor gaps remain (zero-overlap behavior, tie-breaking), which are low-risk for this complexity level.

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

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

Schema description coverage is 100% and both parameters (report_id with its pattern and example, limit with default and bounds) are documented in the schema. The description adds no meaning beyond that, so the 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 ('find'), a specific resource ('other Rösti reports'), and the exact relation criterion ('share IOCs with one report'). It also specifies ordering and payload ('most shared IOCs first, with the shared values'), which distinguishes it cleanly from get_report, search_reports and lookup_ioc siblings.

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 IOC-sharing criterion implies the use case (pivoting from a known report to others), but no sibling is named and no exclusion is stated — an agent must infer that this is not the tool for IOC-level lookups or free-text search. Adequate but implicit.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description still adds genuinely non-obvious traits: the link is signed and expires after 15 minutes, which materially affects how an agent should handle and relay the result.

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, front-loaded with the core action, followed by the operational caveat. No redundant restatement of the tool name or padding.

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

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

For a two-parameter read-only tool with an output schema and full schema coverage, the description covers what is needed: what it returns, its lifetime, and who should consume it. Only the fallback path when a requested format is unavailable is left implicit.

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

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

Schema description coverage is 100%, and the schema already defines both fields with patterns, examples, and a pointer to get_report for valid formats. The description's 'e.g. CSV or MISP' merely echoes the schema's format examples, adding no new meaning.

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

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

States a specific verb and resource: 'Get a download link for one report export', with concrete format examples (CSV, MISP). It is clearly distinct from the sibling get_report, which enumerates available formats, though the description itself does not name that sibling explicitly.

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

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

Gives a clear usage constraint: the link 'is meant to be opened by the user, not downloaded here', which tells the agent not to attempt consumption itself. It lacks an explicit routing statement to get_report for discovering available formats, leaving that only in the schema text.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds the important scoping fact that IOC data is returned only as counts per type and per tag, not as records, which prevents a caller from expecting full IOC objects and explains the need to chain to list_report_iocs.

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, zero filler: the return contents are front-loaded and the sibling routing follows. Every clause carries operational information.

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

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

An output schema exists, so return-shape explanation is optional, yet the description still summarizes the key fields and the counting behavior. Combined with full annotation coverage and a fully documented parameter, an agent has everything needed to call this 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 single parameter is fully documented in the schema (coverage 100%), including a format pattern and example id, so the schema carries the burden. The description adds only the implicit constraint of fetching one report at a time, with no extra syntax or format guidance 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?

States a specific verb and resource ("Get one Rösti report") and enumerates the payload: metadata, MITRE ATT&CK ids, CVEs, export formats, and IOC counts per type and per tag. It also explicitly distinguishes itself from sibling retrieval tools that return the underlying IOCs and YARA rules, so an agent can select it without opening any schema.

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

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

Gives clear routing for the two most likely confusions: use list_report_iocs for the IOCs themselves and get_yara_rules for its YARA rules. It stops short of addressing search_reports or find_related_reports, so discovery-side alternatives are left implicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds one useful detail, that the rules come with their full source, but says nothing about empty results or errors for unknown report ids.

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

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

One sentence, front-loaded with the verb and resource, with the report scoping and return content in the same clause. Nothing is redundant or padded.

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

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

For a simple single-parameter read tool with full annotations and an output schema, the description plus structured fields give an agent everything needed to call it correctly. The only minor gap is unstated behavior for reports with no published rules.

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

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

Schema description coverage is 100% and the single parameter is documented with a pattern and an example, so the schema carries the load. The description only reinforces that the id refers to one report, adding no format or error semantics beyond what is structured.

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 (get) plus resource (YARA rules) scoped to a single Rösti report, which separates it from sibling list/search tools and from get_report. It stops short of naming the sibling it complements, but an agent can tell what it retrieves 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 phrase 'published with one Rösti report' implies the precondition of having a report_id and the context in which to call it, but there is no explicit when-to-use versus get_report or list_report_iocs, and no statement about what happens when a report publishes no rules.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds domain behaviour the annotations cannot: IOCs sharing an entity_ref are related (MD5/SHA-1/SHA-256 of one file) and each IOC exposes an IDS flag and false-positive risk — both genuinely useful for interpreting results. It says nothing about pagination behaviour or default ordering, though the cursor and limit parameters are documented in the schema.

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 paragraphs with the core action and scope front-loaded and the filters enumerated immediately after. The closing sentence on IDS flags and false-positive risk borders on restating output fields that the published output schema already covers, which is the only mildly redundant content.

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 7-parameter, read-only list tool with full schema coverage and an output schema, the description supplies the non-obvious pieces an agent needs: report scoping, the entity_ref grouping concept needed to read results correctly, and the filter dimensions. It omits any mention of pagination despite the cursor parameter and does not point at competing IOC tools, leaving small gaps for a tool with ten siblings.

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

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

With 100% schema description coverage, the schema already documents every parameter including examples for types, tags and categories and the cursor semantics. The description restates the same filter set (type, tag, category, text) without adding format, matching or precedence rules, e.g. whether multiple filters AND together. 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 and resource ('List the IOCs') together with the scope ('of one Rösti report') and the filterable dimensions, so an agent can tell this is report-scoped IOC retrieval rather than a global search. It never names the adjacent tools (search_iocs, lookup_ioc, lookup_iocs), so the differentiation is inferable from the scope phrase rather than stated.

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

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

Usage is only implied: 'of one Rösti report' signals this is the tool for pulling everything attached to a known report_id, and the optional filters suggest narrowing within that set. There is no explicit guidance on when to prefer search_iocs or lookup_iocs instead, and no statement of prerequisites such as needing a report_id obtained from get_report or search_reports.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds value beyond that by specifying what the listing surfaces (counts, recency, active flag) and by stating the downstream contract with search_reports. It does not mention pagination behavior, though the cursor parameter covers that.

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

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

Two sentences, front-loaded with the operation and its payload, followed by the cross-tool hint. 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?

With an output schema, full parameter coverage and safety annotations present, the description only needs to add purpose and cross-tool linkage, which it does. Pagination via cursor is left to the schema, which is acceptable given the output schema exists.

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%: limit, query and cursor are all documented inline with examples and bounds. The description adds no parameter-level detail such as substring-matching semantics for query or cursor expiry, 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 and resource ('List the publishers whose reports Rösti collects') and immediately enumerates the returned fields: report counts, newest report date, active status. It also draws the boundary with search_reports by explaining that source ids serve as that tool's filter, so the agent can tell the two apart without opening schemas.

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

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

Implies the discover-then-filter workflow: call this to obtain source ids, then pass them to search_reports' sources filter. That is a concrete routing cue to a named sibling. It stops short of explicit when-not-to-use guidance (e.g., use search_reports directly if you only need reports), so it is not a 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior: defanging is refanged before matching, matching is exact with a case-insensitive fallback, and results come newest-first. The one gap is what happens when no report matches.

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 the core question in the first sentence, then matching behavior, then return shape — a sensible order with little waste. The inline formatting reference to `input` is slightly cryptic but does not bloat the 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?

With full schema coverage, complete annotations and an output schema, the description covers nearly everything an agent needs. Only the no-match/empty-result behavior is left unspecified, which is a minor omission for a read-only lookup.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns extra credit by explaining that defanged values are refanged before lookup while `input` echoes the value as given, and that results are newest-first capped at max_matches. It adds real semantics on top of the schema rather than restating it.

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 — 'Check whether one IOC ... appears in Rösti's threat-intelligence reports' — and the singular 'one IOC' implicitly separates it from the plural lookup_iocs and search_iocs siblings. It never names those alternatives explicitly, so an agent must infer the split from the singular/plural distinction.

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 phrasing 'Check whether one IOC ... appears,' which suggests a single-value verification use case. There is no explicit when-to-use/when-not guidance and no named alternative for batch or fuzzy lookups, even though lookup_iocs and search_iocs sit right beside it.

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

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

Annotations already declare readOnly, idempotent and non-destructive behavior, and the description adds genuinely non-obvious traits: defanged inputs are refanged before lookup with a `refanged` indicator, and matching is exact with a case-insensitive fallback. The enumeration of returned report fields is largely redundant with the existing output schema, which keeps this 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?

Front-loaded with the core action, then matching semantics, then return shape, then the sibling pointer. Tight overall, though the list of per-IOC return fields is the one stretch that restates structured output rather than adding meaning.

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 read-only batch lookup with a full input schema and an output schema, the description covers the important unknowns: refanging, match semantics, and how misses are surfaced via `not_found`. Nothing essential to calling it correctly 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 description coverage is 100%, so both `values` and `max_matches_per_value` are already documented in the schema, including defanged formats and limits. The description adds no format, syntax or edge-case detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb and resource: checking many IOCs at once against Rösti's threat-intelligence reports. It also explicitly separates itself from the single-value sibling by saying 'Use lookup_ioc for all matches of a single value,' so an agent can route correctly without opening either schema.

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

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

Gives a clear batch context ('Check many IOCs at once') and names the alternative for the single-value case. It does not address how this differs from sibling search_iocs, which is a plausible source of confusion, so it stops short of full when/when-not coverage.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is settled. The description adds value beyond that by disclosing the no-filter default scope and the shape of a result row (report id, type, category, tags, IDS flag, comment, false-positive risk) plus the follow-up call for report context. It stops short of mentioning pagination flow or rate limits, though cursor handling is already in the schema.

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 paragraphs, front-loaded with scope and default behavior, with the routing advice in the second. It is efficient overall, though the enumeration of result fields overlaps with the existing output schema and could be trimmed without loss.

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 an eight-parameter, all-optional search tool with a full output schema and read-only annotations, the description supplies everything needed to decide and call: scope, default behavior, and alternatives. The only gap is that pagination sequencing (using next_cursor for further pages) is left entirely to the schema.

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

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

Schema description coverage is 100%, so every one of the eight parameters already carries its own explanation, including refanging, exact-match semantics and cursor chaining. The description only restates the filter dimensions at a high level and adds no syntax or behavior detail beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific verb and resource ('Search IOCs across all Rösti reports') and enumerates the filter dimensions (text, type, tag, category, creation time). It also distinguishes itself from lookup_ioc/lookup_iocs and get_report, so an agent can pick the right sibling without opening any 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?

It explicitly states the no-filter behavior ('lists IOCs from all reports') and routes the agent elsewhere with a clear condition: 'Use lookup_ioc or lookup_iocs to check whether specific values are known.' It also points to get_report for report detail, so when-to-use versus alternatives is covered rather than implied.

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 annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is carried by structured data. The description adds value beyond that by disclosing the shape of each result row (title, date, source, authors, tags, and IOC/YARA/MITRE counts) and the presence of outbound links, which tells an agent this is a lightweight summary endpoint. It omits pagination behavior (the limit/cursor interaction) and any maximum-result guidance.

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 paragraphs, front-loaded with the search capability and followed by the return shape and the sibling pointer. The enumerated return fields are somewhat verbose given an output schema exists, but they are informative rather than redundant 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 nine-parameter, zero-required search tool with full schema coverage, full annotations, and an output schema, the description supplies everything an agent needs: what can be filtered, what comes back, and where to go for full detail. 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?

Schema description coverage is 100%, so every one of the nine parameters is already documented with examples and formats in the schema. The description restates the filterable dimensions but adds no syntax, default, or combination semantics beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (search) and resource (Rösti's threat-intelligence reports) and enumerates the filter dimensions: text, source, CVE, MITRE ATT&CK id, publication date. The closing sentence naming get_report makes the boundary between the two tools unambiguous without opening either schema.

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

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

It gives a clear when-to-use context (searching across many reports by filter) and explicitly routes to get_report for single-report details, which is the most likely confusion point. It does not address other plausible siblings such as find_related_reports or search_iocs, so the alternative coverage is partial rather than exhaustive.

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