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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does well by stating side effects: clearing health cache, resetting circuit breaker, and attempting a fresh connection. It could add more about potential disruption or authentication requirements, but for a zero-parameter tool this is solid.

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 sentences of dense, useful information. The main purpose is front-loaded, followed by concrete effects and a clear usage trigger. No filler or 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 zero-parameter force-action tool with no output schema, the description gives sufficient context: what the tool does, which internal state it affects, and when to invoke it. It does not describe the return value or failure behavior, but the action is straightforward and the given context is enough 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 has zero parameters and the schema is empty, so the baseline of 4 applies. There is no parameter ambiguity to resolve, and the description correctly focuses on behavior rather than 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 states a clear, specific action: force reconnection to the OpenCTI server. It also enumerates concrete internal behaviors (clears health cache, resets circuit breaker, attempts fresh connection), which distinguishes it from read-oriented siblings like get_health or get_network_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 says when to use the tool: after configuration changes or to recover from persistent errors. It does not name alternative tools or exclusion criteria, but the context is clear enough for an agent to select it appropriately.

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 carry the behavioral burden. It describes what the tool returns and frames it as non-destructive by using 'Get,' but it does not explicitly state whether the call has side effects, requires special permissions, or reflects real-time vs. cached values. This is adequate but not detailed.

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

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

The description is two short sentences with no wasted words. The core resource and output content are front-loaded, and the use case is stated succinctly.

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 no-parameter, no-output-schema tool, the description is reasonably complete: it names the resource, the key statistic categories, and a practical use case. It could be more precise about formats or which cache is being queried, but the low complexity means these are minor 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 tool has zero parameters, so there is nothing for the description to explain. The schema description coverage is trivially 100%, and the baseline of 4 is appropriate for a no-parameter 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?

The description clearly states a specific verb and resource: 'Get cache statistics.' It also enumerates the exact kinds of data returned (hit rates, sizes, evictions), which makes the tool's purpose concrete and differentiates it from sibling search and status 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 gives clear usage context: 'Useful for debugging and performance tuning.' It does not mention alternatives or exclusions, but the tool has no parameters and a unique resource, so the implied when-to-use guidance is sufficient.

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

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

With no annotations, the description must convey behavior itself. 'Get' clearly implies a read operation, and 'full details' gives some sense of the return, but the description does not disclose error behavior, permissions, or whether all entity types are equally supported. Basic transparency is present, but depth is 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?

A single clear sentence with no filler; the key scoping condition ('by its OpenCTI ID') is front-loaded and the purpose is immediately understandable.

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 one-parameter get-by-ID tool with no output schema, the description plus schema is nearly sufficient: it names the input and the expected result ('full details'). However, without an output schema, a slightly more explicit statement of what 'full details' includes or error behavior would make it fully 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?

Schema description coverage is 100%: entity_id is already documented as an OpenCTI entity ID in UUID format. The description repeats this concept without adding new semantic detail, so it stays at the baseline for schema-covered 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 states a clear action ('Get full details') on a specific resource ('any entity') keyed by the OpenCTI ID, which distinguishes it from the sibling search/lookup tools that query by criteria or hash/IOC values. Even without naming a sibling, 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 phrase 'by its OpenCTI ID' provides clear context for when to call this tool: when the agent already has an entity ID and needs the full object. It does not explicitly state when not to use it or point to alternatives, but the usage context is evident.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only operation but does not disclose what 'health' includes (API reachability, DB status), whether failure returns an error or a payload, or whether connectivity checking has side effects. This is thin behavioral coverage.

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

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

A single front-loaded sentence with zero filler. For a zero-parameter tool, this length is appropriate and every word contributes 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?

With no output schema and no annotations, the description should at least hint at what the response contains (e.g., status, version, latency). The tool is simple, so it is adequate but leaves the return contract entirely to convention.

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 the schema already fully covers the input contract. The baseline of 4 applies; the description correctly adds nothing about parameters because there is nothing to add.

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 ('Check') and a precise resource ('OpenCTI server health and connectivity'). It is immediately distinguishable from siblings like search_threat_intel or get_cache_stats, and even from the conceptually adjacent get_network_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?

No guidance on when to use this tool versus the comparable get_network_status sibling, nor any advice on running it before dependent operations. The intended usage is only implied by the tool's name and 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, the description carries the behavioral burden. It discloses what the tool surfaces: latency percentiles, success rates, circuit breaker state, and recommended timeout/retry settings. The verbs 'Get' and 'Shows' strongly imply a non-mutating read operation, though it does not explicitly state side-effect free or data-freshness 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?

Two compact sentences. First sentence gives the high-level purpose; second adds specific deliverable metrics. No fluff, no redundant restating of the tool name.

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-param, no-output-schema status tool, the description is substantially complete: it names the main categories of returned data. It could add a note on date/freshness scope or how recommendations are derived, but nothing critical is missing for correct invocation.

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

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

The tool accepts zero parameters, so the baseline is 4. The description does not need parameter guidance, and it presents all the information necessary to invoke the tool without arguments.

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 a specific verb and resource: 'Get network health metrics and adaptive configuration recommendations.' It also enumerates concrete outputs (latency P50/P95/P99, success rates, circuit breaker state) that distinguish it from broader siblings like get_health or cache-focused get_cache_stats.

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

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

The description implies usage when network health metrics and adaptive configuration recommendations are needed, but it does not explicitly compare against alternatives such as get_health. No when-not guidance is 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 provided, the description carries the full burden of disclosure. It states the core behavior (retrieving IOCs added within the last N days) but does not clarify what 'recently added' means (e.g., first-seen vs. added-to-platform), whether results are ordered, paginated, or what the return structure looks like. This is adequate but has clear gaps.

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 filler. Every word contributes to the purpose, and it is appropriately sized for the tool's simplicity.

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, combined with a fully documented schema, gives an agent the basic input contract. However, with no output schema or annotation, it lacks detail about the shape of the returned indicator objects, ordering, or the precise recency criterion, so it is not fully complete for nuanced selection.

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 input schema already documents both parameters with defaults and maximums. The description's 'last N days' aligns with the 'days' parameter but adds no semantic detail 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 states a specific action ('Get') and resource ('recently added indicators (IOCs)') with a time bound ('last N days'), making the tool's purpose unambiguous. However, it does not explicitly distinguish this from sibling lookup/search tools, so it misses the top tier.

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 guidance about when to use this tool versus sibling alternatives like search_threat_intel, lookup_ioc, or search_observable. The description merely states what the tool does, with no exclusions, prerequisites, or selection criteria.

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 burden of behavioral disclosure. It conveys that this is a read-style operation and gives semantic examples of relationship content, but it does not mention return format, pagination, or any side effects. 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?

The description is a single sentence with no wasted words. The core action and scope are front-loaded, and the parenthetical examples provide helpful context without bloat.

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 four-parameter tool with full schema coverage and no output schema, the description gives enough to understand basic intent but does not describe what a relationship object looks like or what the return value contains. This is a meaningful gap, though not critical for invoking the tool.

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

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

Schema description coverage is 100%, so the schema fully documents all four parameters. The description adds slight semantic color with examples like 'uses' and 'indicates', which align with relationship_types, but it does not meaningfully compensate beyond the schema 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 states a specific verb (get) and resource (relationships) tied to an entity, with concrete examples ('who uses what, what indicates what') that clarify the tool's purpose. It clearly distinguishes itself from sibling search tools and get_entity.

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 clearly implies when to use this tool: when you need an entity's relationships, not when you need entity details or a search. It does not explicitly name alternatives or exclusions, but the context is sufficiently clear given the sibling tool set.

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

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

No annotations are provided, so the description carries the full burden. It indicates a read-only enumeration behavior, but it does not clarify whether 'available' means configured, active, or live-reachable, nor does it describe the return shape. This is adequate for a simple list operation but thin on behavioral detail.

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

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

The description is a single sentence with the verb and resource front-loaded. It includes useful examples without wasted words, and this brevity is appropriate for a zero-parameter list 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?

For a simple zero-parameter tool with no output schema, the description is nearly complete: it states the operation, the resource, and example connectors. It could add whether this is a live check or static catalog, but no operationally critical information 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 has zero parameters and empty schema with 100% schema description coverage. Per the baseline for 0-parameter tools, the description does not need to explain parameter semantics, and it correctly avoids adding irrelevant parameter guidance.

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

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

The description uses a specific verb ('List') and resource ('available enrichment connectors') with concrete examples (VirusTotal, Shodan). It clearly distinguishes this tool from the many search/lookup siblings, which query threat data rather than enumerate available connectors.

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 intended use case is clear: an agent should call this when it needs to know which enrichment connectors are available. It does not explicitly mention alternatives or exclusions, but no sibling tool appears to handle connector enumeration, so the usage context is evident.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. It only states the lookup action and supported hash types. It does not mention whether the operation is read-only, what happens when no match is found, whether matching is exact, or what the response contains.

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, direct sentence with no filler. The action, resource, and supported formats are all present and front-loaded. Every word 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?

The tool has a single parameter, but there is no output schema and no annotations. The description does not explain return values, not-found behavior, or how this lookup compares to sibling lookup tools. For an agent to call it correctly and interpret the result, more context 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?

Schema description coverage is 100%, and the only parameter 'hash' is documented in the schema as 'File hash (MD5, SHA1, or SHA256'. The description repeats this rather than adding new meaning, so the baseline score 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?

The description states a specific verb ('look up') and resource ('file hash'), and even enumerates the supported hash types (MD5, SHA1, SHA256). It is clear about what the tool does. However, it does not explicitly distinguish itself from sibling tools like lookup_ioc or search_observable, so it stops short of the top score.

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 guidance on when to use this tool versus alternatives such as lookup_ioc or search_observable. The description gives no context about preferred use cases, exclusions, or why an agent should pick this over related lookup/search 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 carries the behavioral disclosure burden. It does add useful information by indicating the response will include related threat actors, malware, and MITRE techniques, and it is clearly a read-style operation. It does not mention failure behavior, empty results, or any rate/access limitations, but for a simple lookup the disclosed output scope is reasonably helpful.

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, tightly worded sentence. It front-loads the action and target, includes the key scope via parenthetical content, and ends with the value-add of related context. No filler or redundant phrasing is present.

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

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

For a single-parameter lookup tool with no output schema and no annotations, the description covers what input to provide and broadly what to expect in the response. It could be more explicit about the return shape or behavior when no context is found, but the core usage is complete enough for an agent 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 input schema fully documents the only parameter 'ioc' with type, maxLength, and an example-based description of accepted formats. The tool description essentially repeats that same type list (IP, hash, domain, URL) but adds no deeper semantic guidance. Since schema coverage is 100%, 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?

The description states a clear action ('Get full context') and resource ('a specific IOC'), and enumerates the accepted IOC types and the kind of context returned ('related threat actors, malware, and MITRE techniques'). However, it does not explicitly distinguish lookup_ioc from siblings such as lookup_hash or get_entity, so an agent must infer the boundary.

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 a targeted lookup of a known IOC value, but provides no explicit when-to-use guidance or exclusions. It does not mention alternatives like search_threat_intel, lookup_hash, or get_relationships, leaving the agent to figure out when to prefer this tool over those.

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

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

No annotations are provided, so the description carries the full burden. The verb 'Search' implies a read-only operation, which is helpful, but the description does not disclose return format, pagination behavior, or any side-effect/authorization context. There is no contradiction, but behavioral detail is 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 sentence that is front-loaded, specific, and free of redundancy. It conveys the essence of the tool without wasting 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 simple search tool with fully documented parameters, the description is minimally adequate. However, there is no output schema and no annotations, so an agent is not told what the search reponse contains or whether any pagination/filter behaviors need special handling.

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 fully documents all six parameters. The description adds 'by ID or name', which clarifies the primary query parameter, but that information already appears in the query parameter's own description.

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 a specific resource ('MITRE ATT&CK techniques'), with the two supported query modes ('by ID or name'). This clearly distinguishes it from the many sibling search_* 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?

Provides clear context for when the tool should be used: when looking up MITRE ATT&CK techniques by ID or name. It does not explicitly name alternatives or exclusions, but the use case is unambiguous.

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

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

No annotations are provided, so the description carries full disclosure burden. It only conveys that this is a search operation; it does not describe return format, result behavior, pagination, or any other operational traits. This leaves meaningful ambiguity for an agent.

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 action and target, zero filler. It is appropriately sized for a two-parameter search tool and wastes no 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 simple 2-parameter search tool, the description is minimally adequate: it names the input and the resource. However, with no output schema, it does not describe what kind of result is returned, which leaves some gaps for an agent deciding whether this tool meets a need.

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 both query and limit. The phrase 'by name or keyword' essentially restates the schema's query description and adds no new semantic meaning. With full schema coverage, 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?

The description uses a specific verb ('Search') and identifies the exact resource ('threat campaigns'), plus the input method ('by name or keyword'). It clearly differentiates from sibling search tools for other entity types, though it does not explicitly call out alternatives.

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 makes the intended context clear: use this tool when you need to find threat campaigns by name or keyword. It does not list exclusions or explicitly compare against search_threat_actor, search_malware, etc., but the resource-specific phrasing gives sufficient guidance for this simple case.

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

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

No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only restates the search intent and the domain; it doesn't state matching semantics, return format, pagination, or any side effects or prerequisites. An agent gets little insight beyond the tool name.

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 focused sentence with no redundant words; the parenthetical adds domain context without bloat. It is appropriately sized for a simple search 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?

The description plus full input schema is minimally sufficient for an agent to invoke the tool with a query and limit. However, there is no output schema and the description doesn't describe the return value, ordering, or result handling, so completeness is only mid-range.

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 baseline is 3; the schema already documents query as 'Mitigation name or MITRE ID' and limit with default/max. The tool description adds no additional parameter semantics, which is acceptable given the full 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?

States a specific verb ('Search') and a distinct resource ('courses of action'), and the parenthetical '(mitigations for attack techniques)' clarifies the domain. This distinguishes it from sibling search tools such as search_attack_pattern and search_threat_intel.

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 the tool is the right choice when looking for courses of action/mitigations, and the parenthetical gives domain context. However, it provides no explicit when-to-use or when-not-to-use guidance and does not reference alternative sibling search tools.

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

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

With no annotations, the description must disclose behavioral traits itself, but it only restates 'search' and defines the resource. It doesn't mention read-only behavior, pagination, result contents, rate limits, or any 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?

Single sentence with no filler; the resource definition is front-loaded and the entire description is easy to parse. Every word 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 simple 2-parameter search tool with a fully documented schema, this is minimally adequate for invocation. However, with no output schema and no annotations, it leaves return-value expectations and safe-use context to inference, and it doesn't help route from the large sibling set.

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 baseline is 3. The description adds useful context about the meaning of groupings, but it adds no parameter-specific details beyond what the input schema already provides for query and limit.

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 action ('Search for groupings') and a resource, with a parenthetical defining what a grouping is ('analysis containers that group related entities'). This makes the tool's target clear, though it does not explicitly distinguish it from the many sibling search_* 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?

No guidance is provided about when to choose this tool over the 28 sibling search tools. The description only says what it searches for; it never states when to use it, when not to, or which alternative to pick.

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, but it only says 'Search' without stating whether the operation is read-only, how results are ordered, whether pagination is applied, or what query semantics are used. The verb implies a read operation, but no concrete behavior is disclosed beyond the name.

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 filler or redundant wording. It is concise and easy to parse, though it does not add much beyond the tool name.

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 the tool being relatively simple, the description lacks essential context: no explanation of what the query matches, how results are returned, what the default behavior is, or how to handle the absence of results. With no output schema or annotations, an agent would need more information to correctly interpret the search results.

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

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

Schema description coverage is 100%, and both parameters (query, limit) already have descriptions in the schema. The tool description adds no additional parameter meaning, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Search') and resource ('security incidents'), which clearly identifies the tool's domain and distinguishes it from sibling tools like search_malware or search_threat_actor. However, it does not elaborate on what constitutes an incident or what fields are searched, so it stops short of full clarity.

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 guidance on when to use this tool versus the many sibling search tools, nor any mention of exclusions or preferred alternatives. The description simply states the action without giving an agent enough context to choose it over search_threat_intel or other incident-related searches.

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 disclosure burden. It only states that this is a search; it does not describe read-only semantics, result format, pagination behavior, data scope, or potential caveats. The term 'search' weakly implies a read operation, but that remains implicit.

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 useful examples and no filler. It is concise and scannable, though it could have included a brief routing or behavior sentence without much cost.

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 6 parameters, no output schema, no annotations, and many sibling search tools, the description is too thin to fully equip an agent. It lacks return-value expectations, search semantics, and any differentiation from the two dozen sibling tools, so an agent would have to infer or inspect other clues.

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 all six parameters (query, limit, offset, labels, created_before, created_after) are already documented in the schema. The description adds no parameter-level detail beyond the general subject, so the baseline score 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?

The description names the verb 'Search' and the resource 'infrastructure' with concrete examples (C2 servers, hosting, botnets), making the tool's subject clear. It does not explicitly differentiate from sibling search tools, but the resource type is reasonably distinguishable.

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 the tool — when an agent needs to find infrastructure-related entities. However, it provides no explicit guidance on when to prefer a sibling search tool such as search_threat_actor or search_malware, and no exclusions or alternative routing.

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 responsibility for behavioral disclosure. It states only that it 'searches' for locations but does not disclose what results look like, pagination behavior, authentication requirements, or any side effects. The description is not misleading, but it is 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?

The description is a single, front-loaded sentence with no filler or repetition. The parenthetical examples add useful semantic context without bloating the text, though slightly more detail could have been included without harming conciseness.

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

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

For a simple two-parameter search tool, the description covers the core purpose and the schema covers parameter details. However, with no output schema and no usage guidance relative to sibling search tools, an agent is left without information about result shape or when to choose this tool over alternatives.

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 both 'query' and 'limit' adequately. The description adds no parameter-level detail beyond the examples in the purpose clause, but it does not need to compensate because the schema is sufficient.

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

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

The description uses a specific verb ('Search') and a specific resource ('locations'), further clarified with examples ('countries, regions, cities'). This clearly distinguishes it from the more generic search tools, though it does not explicitly contrast it with any specific sibling.

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

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

No guidance is given about when to use this tool versus the many sibling search tools, nor are any exclusions or alternative tools mentioned. The intended context is only implied by the name and description, not stated.

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 of behavioral disclosure, but it only states that the tool searches. It does not explain matching behavior, result ordering, whether results are read-only, or what output shape to expect. For an unannotated tool, this leaves important behavioral uncertainty.

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 filler. Every word carries meaning, and it avoids restating details already present in the schema.

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 seven parameters, no annotations, and no output schema, this description is minimally adequate but incomplete. It does not mention pagination behavior, result format, or edge cases like alias matching, and an agent would need to infer too much about how the tool behaves beyond its basic search function.

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 parameter semantics are already fully documented in the schema. The description adds little beyond the schema, though the phrase 'by name or alias' reinforces the meaning of the query parameter without providing new details.

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: 'Search for malware families by name or alias.' This clearly identifies the tool's purpose and differentiates it from sibling tools like search_threat_actor or search_vulnerability, though it does not explicitly name alternatives or scope exclusions.

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 'by name or alias' implies this tool is appropriate when the user has a malware name or alias in mind. However, there is no explicit guidance about when to prefer this over related search tools such as search_threat_intel or search_observable, and no exclusions or alternative routing are 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, the description carries the full burden of behavioral disclosure. It only repeats the search operation implied by the tool name and gives no information about matching behavior, result ordering, pagination, or whether the operation is read-only. The behavioral transparency 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 only one short sentence and is technically concise. However, 'Search' largely repeats the tool name, so the sentence adds limited new information. It is under-specified rather than efficiently information-dense.

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 annotations and no output schema, the description should provide more context about what an analyst note is, how search behaves, and how this differs from similar search tools. The current description is too thin for an agent to reliably choose and invoke this tool over 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?

Schema description coverage is 100%, so both 'query' and 'limit' are already documented in the schema. The description adds no additional parameter semantics beyond the general 'analyst notes' context, which keeps it at the baseline for high 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 states a clear verb and resource: 'Search for analyst notes.' It is unambiguous about what the tool operates on. However, it does not distinguish itself from the many sibling search tools such as search_reports or search_threat_intel.

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

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

No guidance is provided about when to use this tool versus the numerous sibling search tools. There are no alternative recommendations, exclusions, or context clues beyond the generic 'analyst notes' phrasing.

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 carry the behavioral disclosure burden. It only says 'search' without explaining matching behavior, ordering, result format, pagination, or that the operation is read-only. A search tool has limited risk, but key behavioral context is absent.

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 one-sentence description is concise and front-loads the primary purpose with helpful examples. It is appropriately short for a search tool, though it could have included a usage hint without becoming verbose.

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

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

With no output schema and no annotations, the description should at least indicate what the search returns or any notable result behavior. It does not. The parameter schema covers inputs, but the agent is left guessing about the output shape and whether the search is exact, fuzzy, or full-text.

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 all three parameters are already documented with clear descriptions and defaults. The main description adds no additional parameter semantics beyond restating the search concept, which is acceptable baseline behavior given the full 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 states a specific verb ('Search for observables') and clearly identifies the resource type with concrete examples: raw technical artifacts such as IPs, domains, hashes, and emails. This distinguishes it from sibling tools that search other entity types like threat actors, malware, or vulnerabilities.

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 scope by defining observables as raw technical artifacts, but it does not explicitly state when to prefer this tool over alternatives like lookup_ioc, search_threat_intel, or get_entity. There is no mention of when not to use this tool or how it differs from exact-match lookups.

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 available, the description must carry the behavioral burden. 'Search for organizations' implies a non-mutating lookup, but it does not describe match semantics, scoping, pagination, or result contents. The behavior is minimally transparent 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 a single concise sentence that delivers the core purpose and examples with no wasted words. It is easy to parse, though it could carry a bit more useful context without becoming verbose.

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 two-parameter search tool with full schema coverage, the basic invocation details are covered. However, there is no output schema and no usage guidance, so an agent still lacks context about expected results and when to choose this tool over sibling searches.

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 already documents both parameters with descriptions, defaults, and constraints, so the baseline is 3. The description adds 'organizations' context but no additional parameter semantics 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 identifies the exact action ('Search') and resource ('organizations') with clarifying examples like 'companies, government bodies'. It does not explicitly contrast with sibling search_* tools, but the resource type is clear enough for an agent to know what the tool targets.

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

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

No guidance is provided about when to use this tool over siblings such as search_threat_actor, search_sector, or search_location. The description only states what the tool does, not under which conditions it should be selected.

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 of behavioral disclosure, but it only says 'search'. It does not state that the operation is read-only, how results are sorted or matched, whether it supports full-text search, or any other behavioral trait. The implied read-only nature of 'search' is not enough to rise above a minimal score.

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, efficient sentence with no filler. It is front-loaded and easy to parse, though it is almost too terse to carry the required behavioral guidance. It earns a 4 for conciseness but loses a point due to lack of structure that might have included usage 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?

Given the large sibling set and the lack of annotations or output schema, this description is incomplete for reliable tool selection. It does not explain what constitutes a 'report', how it relates to the other searchable entities, or what the search behavior entails. An agent would need to open other tool definitions or make assumptions.

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%, with both query and limit already described clearly. The description adds no additional parameter context, so the baseline score of 3 applies. The description is not misleading, but it does not compensate or elaborate on 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 states a specific verb ('Search') and resource ('threat intelligence reports'), making the core function clear. However, it does not distinguish itself from the many sibling search tools like search_threat_intel or search_incident, so it misses the differentiation that would earn a 5.

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

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

No guidance is provided about when to use this tool versus the numerous sibling search tools. There is no mention of alternatives, exclusions, or context clues such as 'choose this when looking for full report documents rather than individual entities.'

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Search', which implies read-only retrieval, but it does not state return shape, matching behavior, pagination semantics, or whether results are exact or partial 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?

The description is a single, focused sentence with no filler, and the examples earn their place by clarifying what counts as a sector/industry.

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 search tool, the core details are present, but with no output schema and no behavioral disclosure, an agent gets no indication of result structure, empty-result behavior, or additional search semantics beyond the schema-provided limit.

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 adds example values for the query parameter, which is helpful, but it does not add meaning beyond what the schema already documents for limit.

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: 'Search for sectors/industries', with concrete examples ('Energy', 'Healthcare', 'Finance'). This makes the tool's object clear and distinguishes it from the many sibling search_* tools without requiring schema inspection.

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: use this tool when looking up a sector or industry by keyword. However, it does not explicitly state when to prefer this tool over alternatives or mention any exclusions, though sibling names make the domain reasonably clear.

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

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

With no annotations, description carries the burden. It adds a useful definition of 'sighting' and implies a read-only search operation, but it does not disclose behavior such as fuzzy vs exact matching, ordering, result format, or whether partial matches are returned.

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 entire description is a single sentence, front-loads the action, and wastes no words. The parenthetical definition adds meaning without bloating 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?

For a simple two-parameter search tool, the description and schema are mostly adequate, but there is no indication of return structure or match behavior, especially since no output schema is present. An agent could call it correctly but might not know what the response represents beyond the resource name.

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 query and limit parameters are already fully documented. The description adds no additional semantic detail beyond what the schema provides, meeting the baseline for high 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 uses a specific verb ('Search'), names the exact resource ('sightings'), and clarifies what a sighting is ('detection events where indicators were observed'). This clearly distinguishes the tool from sibling search tools like search_observable or search_threat_intel.

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

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

No guidance is given about when to use this tool vs siblings such as search_observable or lookup_ioc. The description implies searching sightings by keyword, but there are no explicit alternatives, exclusions, or search-context examples.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says the tool 'searches' by name or alias; it does not disclose whether matching is exact, partial, case-insensitive, alias-aware beyond the query string, or what the results contain. The agent is left without important behavioral context.

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

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

The description is a single, direct sentence with no filler or redundant phrasing. It is appropriately concise for a simple tool and front-loads the core action and target.

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

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

Given no annotations, no output schema, and many sibling search tools, the description is too thin to fully orient an agent. It does not mention what kind of results are returned, how to interpret the output, when to prefer this tool, or any limitations. The agent must rely entirely on the schema and tool name.

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 100% description coverage for all parameters, so the description does not need to restate details. It does add mild value by clarifying that the query parameter refers to a name/alias, but it does not provide any additional semantics 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 a specific verb ('Search') and resource ('threat actors and APT groups') along with the search key ('by name or alias'). It is easy to tell what the tool targets, but it does not explicitly differentiate itself from the many sibling search_* tools, particularly search_threat_intel, so it falls short of a 5.

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 versus alternatives such as search_threat_intel, search_campaign, or lookup_ioc. There are no exclusions, no context about when this is the right choice, and no mention of what makes it distinct among the many search 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?

There are no annotations, so the description carries the full behavioral burden. It states what the tool does but does not disclose whether it is read-only, how results are aggregated across entity types, any authorization assumptions, or rate limits. For a no-annotation tool, this is a notable gap.

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 clean, front-loaded sentence with no redundancy. It states the resource, the action, the scope, and useful examples of entity types in a compact way.

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 schema documents all seven parameters, so a caller knows how to construct a request. However, there is no output schema and no description of the return shape or how multi-type results are packaged. The description is adequate for basic invocation but leaves the agent to guess about result structure and about why this broad tool may be preferable to a specialized sibling.

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 every parameter has a clear description, so the baseline is 3. The tool description adds no extra parameter context, but it does not need to since the schema already explains query, limit, labels, offset, date filters, and confidence threshold.

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 clear verb ('Search'), a resource ('OpenCTI'), and the full scope ('across all entity types'), with concrete examples. This clearly differentiates from the many specialized search_* siblings because it explicitly covers multiple entity types in one call.

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

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

The description gives a clear context for when to use the tool: broad, multi-entity threat intelligence searches. It does not explicitly name alternatives or say 'use search_threat_actor when you only need actors', so it stops short of a 5, but the sibling list and the phrase 'across all entity types' make the intended use clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only defines the semantic scope of 'tool' and says 'search.' It does not describe output form, pagination behavior, expected result types, or any access/rate characteristics, so the agent must assume a straightforward read-only search behavior.

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 concise sentence with the core action and a useful clarifying parenthetical. It is front-loaded and has no filler, though the phrasing 'Mimikatz as a tool' is slightly awkward and the description could be polished.

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 input schema richly documents all six parameters, including defaults and constraints, but there is no output schema and no annotations. The description is adequate for invoking a search, but it leaves gaps around result shape, paginated output semantics, and how this search differ from the sibling search_* 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 coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema by clarifying that 'query' terms like PsExec or Mimikatz refer to legitimate software used maliciously, and not to malware or arbitrary objects. This helps the agent shape a correct query, moving it slightly above 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 states a clear search action over a defined resource: 'tools' and explains what that means with concrete examples, 'legitimate software used maliciously, e.g., PsExec, Mimikatz'. This helps separate it from generic search and from semantic siblings like search_malware, though it stops short of explicitly naming alternative search 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 gives no guidance about when to choose this tool versus the many sibling search tools. It only defines what a 'tool' is, without saying things like 'use this for dual-use software; use search_malware for actual malware.' An agent must infer usage from the category definition alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that searching can be done by CVE ID or keyword, but it does not describe result shape, exact-match behavior, pagination semantics, rate limits, or any other runtime behavior. For a tool with no output schema, this is a significant gap.

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 filler words. It communicates the core purpose efficiently. It is slightly undersized given the tool's six parameters and lack of output schema, but on pure conciseness it performs well.

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 six parameters, no annotations, no output schema, and many sibling search tools, the one-sentence description is incomplete. An agent cannot infer what the search returns, how to scope results beyond explicit parameters, or how this tool relates to search_threat_intel and other sibling tools. More context is needed for reliable invocation and result interpretation.

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 baseline is 3. The description adds little beyond the schema, mostly restating that the query can be a CVE ID or keyword. It does not enrich the meaning of limit, offset, labels, or date filters beyond what the schema already 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 a specific verb and resource: 'Search for vulnerabilities (CVEs) by ID or keyword.' It identifies the domain and the two primary query modes. However, it does not explicitly differentiate itself from sibling search tools such as search_threat_intel or search_malware, so it stops short of full differentiation.

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

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

The description gives no guidance on when to choose this tool over the many sibling search tools. It does not state exclusions, fallbacks, or alternative tools. Usage context is only implied by the resource name, not explicitly provided.

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