OT Intel API

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

Annotations only declare readOnlyHint/openWorldHint. The description adds substantial behavioral context beyond them: deterministic rules with no LLM in the decision path, the vendor_stack cap on the verdict, the $0.12 USDC x402 price, and the exact unpaid-call failure/retry protocol. This is exactly the kind of context annotations cannot carry.

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

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

Three dense sentences, front-loaded with the verdict purpose then the constraint then the billing. Every sentence earns its place, though the payment-retry sentence is somewhat long and could be trimmed.

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, the description correctly names the three possible verdicts and explains the failure/payment path, so an agent can invoke and interpret it. It stops short of describing the full response body for a successful call, but coverage is adequate for a read-only scoring 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 parameters are already well documented. The description's vendor_stack and asset_context notes largely restate what the schema already declares. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific output (deterministic auto_approve/human_review/reject verdict) for a specific resource (planned remediation action against actor/sector/region context). It even lists the concrete action types it gates (block_ip, quarantine_host, halt_pipeline) and names its sibling lineage (/ot/threat-score) without requiring the schema to be opened.

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?

Clear context for use — gating a planned remediation action before execution — and it states the vendor_stack condition that caps the verdict at human_review. It distances itself from getThreatScore by noting the added auditable rules, but never gives an explicit 'use this rather than X when Y' routing statement.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the critical non-obvious behavior: a paid endpoint ($0.35 USDC via x402 on Base), the exact failure mode (PaymentRequired challenge on unpaid calls) and the retry contract (resubmit identical call with signed payload in _meta["x402/payment"]). It also reveals the fan-out behavior across six endpoints. This is exactly the kind of behavioral context annotations cannot convey.

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 purpose, then returned artifacts, then price and payment mechanics in order of likely need. Dense but each sentence carries distinct information; no filler.

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

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

With no output schema, the description compensates by listing the returned artifacts (profile, infrastructure analysis, IOC table, detection rules, kill chain, MITRE ATT&CK coverage). Combined with the payment contract and fan-out disclosure, an agent has everything needed to call and interpret the result.

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% (the actor param is documented with concrete examples like SANDWORM, XENOTIME, VOLTZITE). The description adds no additional meaning about the actor parameter, 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 and resource ('Comprehensive intelligence dossier for an ICS threat actor') and enumerates the underlying endpoints and returned artifacts, making clear it is the broad aggregation call. It does not name or differentiate against the very close siblings getActorReport and getThreatActor, so an agent must infer the distinction from 'Comprehensive'/'Deep' alone.

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: the broad fan-out and 'Comprehensive' framing suggest this is the deep, all-in-one call versus narrower siblings like getActorReport. There is no explicit when-to-use, when-not-to-use, or named alternative, and no prerequisite guidance beyond the payment flow.

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 only cover readOnlyHint/openWorldHint, but the description goes well beyond: it discloses the price ($0.25 USDC via x402 on Base mainnet), what an unpaid call returns (PaymentRequired challenge), the exact retry mechanism (_meta["x402/payment"]), the TLP handling, and the internal fan-out/synthesis path. These are operationally critical behaviors an agent must know to invoke it successfully, none of which appear in structured fields.

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 purpose, then the fan-out, output contents, TLP, and payment flow in a logical order. Every sentence carries real information, though the endpoint enumeration and the full output-section list make it denser than strictly necessary.

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, the description carries the return-value burden and does so by listing the report sections it produces. It also covers the payment/auth lifecycle and data classification, so an agent has everything needed to call and interpret it.

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

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

Schema description coverage is 100%, so both parameters (actor, sector) are already documented with examples and the sector field's optionality. The description adds only the implicit notion of an ICS/APT actor, not new syntax or format detail, 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+resource: a synthesised Markdown threat report for an ICS/APT actor, and enumerates what it returns (executive summary, campaigns, malware families, ATT&CK mappings). It implies a composite/superset capability that separates it from leaf tools like getThreatActor, but it never names or contrasts those siblings explicitly (e.g. getActorDossier, getThreatActor), leaving the agent to infer the 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?

The 'fans out to ... internally (no extra charge) and synthesises' phrasing implies this is the one-shot comprehensive option versus calling the individual endpoints, which is useful implied guidance. However, there is no explicit when-to-use/when-not statement and no named alternative for narrower lookups, even though many overlapping siblings exist (getActorDossier, getThreatActor, getSectorBrief).

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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the paid-access mechanics: $0.03 USDC per call via x402 on Base mainnet, an unpaid call returning a PaymentRequired challenge, and the exact retry pattern using _meta["x402/payment"]. This is exactly the operational context an agent cannot infer from annotations.

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

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

Three short sentences, front-loaded with the retrieval scope and followed by the payment flow; every sentence carries weight. The opening noun fragment is slightly abrupt but not wasteful.

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

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

Covers purpose, data source, and the full payment lifecycle, which is the hardest part for an agent to get right. With no output schema, it could say more about the shape or size of the returned actor list, but for a single-parameter lookup this is nearly complete.

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

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

Schema description coverage is 100% and the single 'sector' parameter is documented with concrete examples (energy, water, manufacturing, oil-and-gas, chemical, nuclear). The description only restates 'specific industrial sector' and adds no format or matching rules, 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+resource ('All ICS threat actors targeting a specific industrial sector') plus the data source (live MITRE ATT&CK ICS STIX). An agent knows exactly what it retrieves. It does not explicitly differentiate from sibling sector tools like getSectorBrief or getSectorSitrep, so it stops 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?

There is no when-to-use or when-not-to-use guidance. With four sector-oriented siblings (getSectorBrief, getSectorDelta, getSectorSitrep) and actor-oriented siblings (getActorDossier, getThreatActor), the description never explains which to pick for a given need.

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

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

Annotations only cover readOnlyHint and openWorldHint, but the description adds the critical non-obvious behavior: the x402/Base USDC payment model, the 402 PaymentRequired challenge on unpaid calls, and the exact retry mechanism via _meta["x402/payment"]. This is exactly the auth/rate-limit class of context annotations can't provide.

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?

Four sentences, purpose front-loaded, then return fields, then the payment mechanics. Each sentence earns its place, though the payment retry sentence is dense and could be marginally tighter.

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, the description compensates by enumerating return fields (advisory IDs, CVSS, CVE lists, OT severity, triage links), and it fully documents the payment/retry flow. Nothing needed to call 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 coverage is 100%, so limit, sector, and vendor are already fully documented with examples. The description's mention of 'filtered by vendor or sector' only restates the schema, adding no syntax or format detail beyond 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 ('Latest CISA ICS-CERT advisories') plus the filter mechanism ('by vendor or sector'). Clear enough for selection, though it doesn't distinguish itself from potentially overlapping siblings like getCveTriage or getVendorRisk.

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: it notes the advisory feed is filterable by vendor or sector, but gives no when-to-use guidance or explicit alternatives among the ~39 siblings. An agent must infer the appropriate scenario.

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 cover readOnlyHint/openWorldHint, and the description goes well beyond them: it discloses determinism, that no LLM is in the lookup path, the $0.20 USDC x402 price, and the full unpaid-call recovery flow (PaymentRequired challenge + retry with signed payload in _meta). That payment/auth protocol is exactly the operational context annotations cannot express.

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?

Information-dense and front-loaded: identity → scope limits → sibling disambiguation → determinism → payment. Each sentence carries a distinct fact, though the long parenthetical citation and price/payment block make it heavier than strictly necessary for tool selection.

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, no-output-schema lookup, the description covers selection, scope, sibling boundaries, and the payment barrier, which is what an agent needs to invoke it. It does not describe the shape of the returned feasibility data, a minor gap given no output schema exists to carry that.

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, but the description adds real query semantics: it establishes the closed vendor set, notes the 'at least one of technique, vendor, or campaign' rule, and states which techniques actually succeeded, letting the agent judge which values yield signal. It stops short of documenting value syntax beyond what the schema already carries.

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+resource ('deterministic lookup against one specific empirical study') with a named citation, subject matter, and conclusion (1.08% success rate). It explicitly distinguishes itself from the two closest siblings, /ot/ai-exposure and /ot/ai-uplift, so an agent can route correctly 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?

Names both alternatives and what each covers, and the scope constraints ('only 3 vendors tested', 'only Network/Register-Tags ever succeeded') implicitly define when results are meaningful. However, there is no explicit 'use this when / use the sibling when' construction; the agent must infer the selection condition from the parentheticals.

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=true and openWorldHint=true, but the description adds substantial behavioral context beyond those: hand-verified mapping, ATLAS IDs confirmed against the live matrix, deterministic no-LLM lookup path, $0.20 USDC x402 pricing, and the exact PaymentRequired challenge/retry flow with the signed payload location. These details are necessary for correct invocation and are not covered by the schema or annotations.

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

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

The description is front-loaded with purpose and return values, then adds provenance, deterministic behavior, and payment mechanics. Every sentence earns its place: the payment/retry instruction is essential for calling this paid tool, and there is no filler.

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

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

There is no output schema, but the description enumerates the return fields (documented AI/agentic copilot, autonomy level, access, applicable MITRE ATLAS techniques) and explains data provenance and deterministic behavior. Combined with the x402 payment instructions and the readOnly/openWorld annotations, the definition is complete enough for an agent to select, invoke, and interpret 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?

The input schema has 100% description coverage and documents the single vendor parameter with concrete OT/ICS examples. The tool description adds no additional parameter semantics such as accepted aliases, case sensitivity, or matching behavior, so the baseline 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?

States a specific verb 'lookup' and resource 'AI/agentic copilot exposure', scoped to OT/ICS vendors, and names the returned artifacts (documented copilot, autonomy level, access, MITRE ATLAS techniques). This distinguishes it from generic sibling exposure tools such as getAssetExposure or getVendorRisk.

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 use context: it is an AI/agentic copilot exposure lookup specifically for OT/ICS vendors, and it explains the key risk differentiator it returns. It does not explicitly say when not to use it or route the agent to closest alternatives like getAiAttackFeasibility or getAiUplift, so it stops short of full when-to-use guidance.

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

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

Annotations only declare readOnlyHint and openWorldHint, but the description adds critical operational behavior: the $0.20 USDC x402 price on Base mainnet, and the exact failure/retry contract (an unpaid call returns a PaymentRequired challenge; retry the identical call with the signed payload in _meta["x402/payment"]). It also discloses methodology (DeepSeek-synthesised, ICD-203 estimative language) and the grounding precedent, none of which is derivable from structured fields.

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?

Purpose is front-loaded, followed by differentiation, methodology, and pricing/payment mechanics in a logical order; every sentence carries distinct information. It is slightly long, with some framing ('Grounded in a real-world precedent (Dragos, May 2026), not frontier-model governance thresholds') that leans editorial, but it still serves differentiation.

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 only two light annotations, the description covers the dimensions an agent needs: what is assessed, how it differs from the closest sibling, what it costs, and exactly how to handle the payment challenge. The reference to a capped 'informational' tier also signals that graded output exists, filling the gap left by the missing output schema.

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

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

Schema description coverage is 100%, with every parameter self-documented in the schema, including the 'unknown' defaults and the tier-capping rule. The description adds no syntax or format detail beyond the schema, so the baseline 3 for schema-carried semantics is correct.

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

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

The description states a specific verb and resource: it 'assesses how much a general-purpose AI agent lowers the skill/time barrier for an attacker to reach a vendor's OT-adjacent footprint.' It also explicitly differentiates itself from the sibling getAiExposure by scope (attacker uplift vs. the vendor's own embedded copilot), so an agent can route between them 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?

It gives a clear contrast with the nearest alternative ('Distinct from /ot/ai-exposure, which covers a vendor's OWN embedded AI copilot'), which is genuine when-not-to-use guidance. It stops short of stating a positive triggering condition (e.g., when doing attacker-capability modelling vs. product risk), so it is not fully explicit about when to reach for this tool over getAiAttackFeasibility.

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 only cover readOnlyHint and openWorldHint, but the description adds material behavioral context the schema cannot: the $0.12 USDC x402 price on Base mainnet, and the exact unpaid-call failure mode (PaymentRequired challenge) plus the retry contract via _meta["x402/payment"]. This is precisely the kind of beyond-annotation disclosure the dimension rewards.

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

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

Three sentences, front-loaded with what the tool produces before the payment mechanics. Every sentence serves a purpose, though the x402 retry sentence is dense and could be tightened.

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

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

No output schema exists, so the description must convey what comes back — it names the brief's components (BLUF, key judgments, ICD-203 confidence) and how output relates to /ot/report. Combined with the explicit payment/retry contract, an agent has everything needed to call and handle the response 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?

Schema description coverage is 100% (actor with ICS examples, sector with examples), so the schema already carries parameter meaning. The description only restates that sector is optional scoping, adding no syntax or format detail beyond the schema — baseline 3.

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 (produces/returns) and resource (analyst brief for a threat actor) and enumerates the content: BLUF, key judgments, ICD-203 confidence assessment. It distinguishes itself from the full report at /ot/report, though it does not differentiate from sibling briefs like getActorDossier or getSectorBrief by name.

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 usage (decision-ready short brief vs a full report) and notes the optional sector scoping, but gives no explicit when-to-use vs not, and no routing against the many sibling brief/dossier/report tools. Guidance is inferable rather than 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?

Annotations only declare readOnlyHint and openWorldHint; the description goes well beyond them by disclosing the paid-call model, the exact price ($0.03 USDC via x402 on Base mainnet), and the failure/retry protocol (PaymentRequired challenge, then replay the identical call with the signed payload in _meta['x402/payment']). That is precisely the kind of non-obvious operational behavior an agent must know before calling.

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?

Purpose and return contents are front-loaded in the first sentence, with payment mechanics last where they belong. The output enumeration is dense but each item is distinct and decision-relevant; only minor tightening is possible.

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, the description carries the return-value burden and does so by naming the result categories (actor links, phishing kits, hosting indicators, abuse categories, WAF hint). Payment prerequisite and retry semantics are fully covered, leaving nothing an agent needs 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% with only two params, both already documented with examples (AS215540, hivelocity). The description adds no parameter-level meaning, 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 and resource ('Profiles an ASN') scoped to ICS threat actor infrastructure use, then enumerates concrete outputs (actor associations, phishing kits, bulletproof hosting, abuse categories, blocking recommendation). No sibling tool in the list does ASN-level infrastructure profiling, so the agent can route to it 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?

Usage is implied by the required 'asn' input and the ICS/OT framing, but there is no explicit when-to-use statement and no named alternative (e.g., getIocEnrichment or getThreatActor) for overlapping infrastructure questions. Guidance is inferable rather than 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?

Annotations declare readOnlyHint and openWorldHint, so the safety profile is already covered; the description goes well beyond that by disclosing the paid model ($0.05 USDC via x402 on Base mainnet) and the exact failure/retry contract — an unpaid call returns a PaymentRequired challenge and must be retried with the signed payload in _meta["x402/payment"]. That is non-obvious operational behavior an agent could not derive from structured fields.

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

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

Three sentences, each doing distinct work: purpose first, then the return contract (valuable since there is no output schema), then the payment mechanics. No filler, and the most decision-relevant content is front-loaded.

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, the description correctly compensates by naming the returned fields (risk_score, escalate, recommended_action, contributing threat actors) and fully covers the payment path. What it omits is sibling disambiguation and any note on whether the optional firmware parameter materially changes the verdict.

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 five parameters are already documented with examples and enums-in-text, establishing a baseline of 3. The description restates which inputs feed the synthesis (notably flagging firmware as a contributor) but adds no format, syntax, or defaulting detail 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 gives a specific verb and resource ('Synthesises vendor, model, firmware, sector, and network context into a branchable risk verdict') and enumerates the return fields, so the agent knows exactly what it gets. It stops short of distinguishing itself from close siblings like getRiskExposure, getDeviceExposure, or getVendorRisk, which is the only thing keeping it from 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?

There is no statement of when to pick this tool over the many overlapping exposure/risk siblings (getRiskExposure, getDeviceExposure, getVendorRisk, getThreatScore). The only procedural guidance concerns payment retry, not tool selection. An agent must infer usage purely from the name and required-parameter shape.

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 only declare readOnlyHint and openWorldHint, but the description adds critical behavior the agent could not otherwise know: a $0.05 USDC charge per call via x402 on Base, that an unpaid call returns a PaymentRequired challenge, and that the exact same call must be retried with the signed payload in _meta["x402/payment"]. This is exactly the kind of operational context the schema cannot carry.

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

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

Three tight sentences, front-loaded with purpose and return contents, followed by the cost and the payment-failure recovery path. Nothing is repeated from the schema and every sentence carries information an agent needs.

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, the description supplies the return fields; the annotations supply the read-only/open-world safety profile; and the description additionally covers billing and the payment-challenge retry loop. For a 2-parameter read-only lookup, nothing required to call 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%: both sector (with its value list) and status (enum active/all) are fully documented in the schema. The description only reuses the sector concept ('targeting a specific industrial sector') and adds no syntax or format meaning beyond it, 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?

Clear specific verb+resource: retrieving active ICS campaigns for a given industrial sector, with an explicit enumeration of returned fields (campaign name, actor, start date, geography, TTPs, CVEs). However, it never distinguishes itself from closely related siblings such as getSectorBrief, getSectorSitrep, or getActorsBySector, 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?

Usage is implied by the name and the sector-scoping sentence, but there is no explicit when-to-use/when-not guidance and no routing to or away from the many sibling sector/campaign tools. The only explicit instructions concern the payment retry flow, which is how to call the tool rather than when to choose 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 only supply readOnlyHint/openWorldHint; the description goes well beyond them by disclosing the paid model ($0.20 USDC via x402 on Base mainnet), the failure behavior (unpaid call returns a PaymentRequired challenge) and the exact retry protocol (resend identical call with signed payload in _meta['x402/payment']). It also enumerates the return payload (score, verdict, corroborating/contradicting evidence, confidence), which is essential for a no-output-schema tool. No contradiction with the readOnly annotation.

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?

Four sentences, front-loaded with the methodological grounding, then capability, then return shape, then payment mechanics — a sensible order with little waste. The full paper citation with arXiv version and date is heavier than an agent strictly needs, but it justifies the taxonomy used.

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, the description correctly spells out the returned fields, and it covers the non-obvious payment/retry workflow that an agent must know to succeed. Combined with annotations handling the safety profile, nothing needed to call this tool 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% and each parameter already carries an example-bearing description, so the baseline is 3. The prose adds only the general idea of intel.db grounding, not per-parameter syntax, format, or interaction detail beyond what the schema supplies.

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 ('Classifies a CTI claim'), names the exact taxonomy applied (spurious correlation, contradictory knowledge, constrained generalization) and the grounding method (intel.db + DeepSeek synthesis). No sibling in the list scores claim reliability, so the agent can distinguish it from getThreatScore or getCveTriage without opening a 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?

Usage context is implied — this is the tool for judging whether a CTI claim holds up — but the description never states when to prefer it over adjacent tools such as getThreatScore or getCveTriage, nor any preconditions or exclusions. The 'e.g.' clause gives example inputs but not routing guidance.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the paid-call behavior end to end: $0.20 USDC via x402 on Base mainnet, a PaymentRequired challenge on unpaid calls, and the retry with a signed payload in _meta['x402/payment']. It also clarifies that the lookup is deterministic and only the remediation prose is LLM-generated.

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?

Four sentences, front-loaded with the core purpose before the mechanics and pricing. Each sentence carries load, though the payment plumbing could be slightly tightened.

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, the description does the work of describing the return: a deduplicated roll-up into one aggregate severity rating plus an LLM-written remediation summary. Combined with the payment protocol detail, an agent has enough to invoke and interpret it, though the exact aggregate shape remains unspecified.

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 all three parameters thoroughly (including the auto-detection of CVE vs actor tokens and the entity_sector tone-only caveat). The description adds aggregate/dedup output context but no parameter-level detail beyond the schema, 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 — rolling up compliance-gap mapping across multiple CVEs/threat actors in one call — and explicitly contrasts the aggregate behavior with the single-item /ot/compliance mapping. An agent can distinguish it from siblings like getComplianceMapping 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 'multiple CVEs/threat actors in a single call' framing makes the batching use case clear, and the mention of the same compliance_mappings data as /ot/compliance gives context. It does not explicitly name the single-item alternative or state when NOT to batch, so it falls short of full routing guidance.

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

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

Beyond the readOnly/openWorld annotations, it discloses behavior annotations cannot carry: deterministic table lookup with LLM only adding compensating-control prose, a $0.04 USDC x402 price on Base mainnet, the exact failure mode (PaymentRequired challenge), and the retry protocol with a signed payload in _meta['x402/payment']. This is exactly the non-obvious operational detail an agent needs.

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?

Purpose is front-loaded in the first clause, followed by lookup semantics, agent use case, then the pricing/retry mechanics. Five tight sentences with no filler; the payment details are necessary for correct invocation.

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, the description still names what is returned (triggered compliance controls per framework) and covers the paid-call flow, so an agent can call it correctly. It is silent on whether actor and cve_id may be combined or must be mutually exclusive, which is the one remaining ambiguity.

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

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

Schema description coverage is 100%, so the actor, cve_id, and framework enum are already fully documented in the schema. The description only restates that the query targets 'a CVE or threat actor,' adding no syntax or format meaning, 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 and resource ('Returns triggered compliance controls for a CVE or threat actor') and enumerates all 11 frameworks, so an agent knows exactly what is produced. It does not differentiate itself from the closely named sibling getComplianceBatch, which is the main gap keeping it below 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?

Gives clear triggering context: 'call when a new advisory drops, generate gap report, route to compliance team.' Context is explicit but no when-not conditions or named alternatives (e.g., getComplianceBatch) are offered.

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?

Goes well beyond the annotations: it discloses the concrete fan-out data sources, the ~700-word output shape (headline, lede, body, defanged IOCs, TLP marking), the exact price ($0.45 USDC via x402 on Base mainnet), and the failure/retry contract for unpaid calls. Annotations only say readOnly/openWorld, so this added payment and output-mechanics detail is genuinely load-bearing and does not contradict them.

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 deliverable and its size, then cost and retry mechanics in one dense sentence each; no filler. It is longer than strictly necessary for the purpose/usage portion, but every sentence carries information an agent needs (output shape, price, payment retry).

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 present, the description compensates by describing the returned content structure and financial/auth mechanics, plus the x402 challenge-and-retry flow. Nothing essential for a correct first call appears to be 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% and the string params (cve, actor, sector) are fully documented in the schema, including the cve/actor mutual requirement. The description adds no syntax or format detail 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 concrete deliverable (a ~700-word, publication-ready CTI article) with its inputs (actor or CVE) and generation style, so the agent knows exactly what comes back. It does not, however, explicitly contrast itself with near siblings such as getActorReport, getSectorBrief, or getAdvisories, leaving the distinction between 'article' and 'report/brief' to inference.

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

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

Provides usage context ('suitable for threat intel blog posts or advisories') and implicitly scopes the tool to publication-style output, but names no alternatives and gives no when-not-to-use or prerequisite guidance. The reader must infer that short-form reports should use a different sibling.

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

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

Annotations already mark it read-only and open-world. The description goes further by listing the OT-adjusted return fields, disclosing the $0.02 USDC x402 cost on Base mainnet, and explaining the unpaid-call PaymentRequired challenge and retry mechanism with _meta["x402/payment"].

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

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

The description is front-loaded with purpose, then returns, cost, and payment failure handling. Every sentence adds practical information, with no filler or redundant restatement of 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?

With no output schema, the description usefully enumerates the returned fields and explains the paid-call behavior. It is nearly complete for invocation, though it does not cover data freshness, missing-CVE behavior, or exact response structure.

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 id parameter is documented in the schema as a CVE identifier with an example. The description adds no additional parameter syntax or usage detail 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?

States a specific verb and resource: CVE lookup enriched for ICS/SCADA environments. It lists the OT-specific outputs, making the scope clear, but it does not explicitly distinguish itself from any sibling tool by name.

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 context for when it applies: CVE lookup enriched for ICS/SCADA environments. It also explains the paid invocation flow, but it does not name alternatives, exclusions, or when-not-to-use cases.

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 only cover readOnlyHint and openWorldHint, yet the description adds substantial operational detail: the validated:true vs validated:false provenance distinction (public corpus vs DeepSeek synthesis), the requirement to lab-test unvalidated rules, and the full x402 payment flow including the unpaid-call challenge and the _meta["x402/payment"] retry mechanism. This is exactly the kind of auth/payment/trust context annotations cannot express.

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?

Five sentences, zero filler, and correctly front-loaded: what the tool returns, then rule provenance/trust, then intended consumer, then the payment mechanics needed to invoke it successfully. Every sentence 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?

There is no output schema, so the description carries the return-value burden and does so by explaining what the rules are and how the validated flag should be interpreted. Combined with the payment/retry instructions, an agent has everything needed to call this correctly on the first attempt.

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 format enum is self-documenting, so the baseline of 3 applies. The description says rules are returned for a named 'ICS malware family or threat actor', reinforcing the target parameter's meaning, but adds no new syntax or constraint 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?

States a concrete verb+resource ('Returns YARA/Sigma detection rules for an ICS malware family or threat actor') and names the domain explicitly (ICS malware/actors), which is enough to distinguish it from siblings like getMalwareProfile or getIocEnrichment without opening a 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 context of use: 'Designed for automated threat hunting pipelines that commit rules to SIEMs and EDRs.' That framing tells an agent when the tool fits, but it never names an alternative sibling or an explicit when-not-to-use condition.

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 only declare readOnlyHint and openWorldHint; the description adds real behavioral context beyond them: a mandatory $0.05 USDC per-call fee via x402 on Base mainnet, the exact failure mode (unpaid call returns a PaymentRequired challenge), and the retry contract (identical call with signed payload in _meta['x402/payment']). This is exactly the kind of cost/error/retry disclosure an agent needs before invoking a paid tool.

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

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

Three sentences, front-loaded with what the tool returns, followed by price and the payment retry contract. No filler, though the payment mechanics occupy a substantial share of the text while routing guidance is absent.

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, the description does enumerate the return content (default credential risk, exposed OT protocols with ports, hardening recommendations), and it fully covers the paid-invocation path. It omits anything about rate limits, result scoping, or failure modes other than payment, but is otherwise complete for a two-parameter 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 description coverage is 100%, so the schema already documents both vendor and model with examples. The description adds only the framing that lookup is by vendor and model, adding no syntax or format detail beyond the schema, 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+resource combination ('Exposure data for OT devices by vendor and model') and scopes it to OT/industrial control devices via the vendor/model lookup, which the bare title alone would not convey. It does not explicitly name the sibling it is not (e.g. getAssetExposure or getVendorRisk), so it falls short of full sibling 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?

No when-to-use or when-not-to-use guidance is given relative to the ~38 sibling exposure/risk tools. The only procedural instruction is the payment retry flow, which tells the agent how to pay but not when to choose this tool over getAssetExposure, getRiskExposure, or getVendorRisk.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the full monetization behavior: $0.01 USDC per call via x402 on Base mainnet, that an unpaid call returns a PaymentRequired challenge, and exactly how to retry (signed payload in _meta["x402/payment"]). This is precisely the kind of non-obvious operational context the annotations cannot carry.

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

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

Three sentences, front-loaded with the tool's identity and source pipeline before the payment mechanics. Every sentence earns its place, though the payment/retry sentence is dense enough that it could be split for scannability.

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-optional-param read tool with no output schema and annotations covering safety, the description covers identity, provenance, human review, cost, and retry mechanics. The only gap is a brief sense of what an edition contains, which is minor given the tool's simplicity.

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

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

Schema coverage is 100% and the single optional issue_date parameter is fully documented in the schema (YYYY-MM-DD, defaults to latest). The description adds no further parameter meaning, 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?

The description states a specific resource ('State of OT Threat Intel — GCC' sitrep) and its nature as a recurring, human-reviewed public bulletin, which is far more specific than a tautology. It does not, however, differentiate itself from nearby siblings like getSectorSitrep or getAnalystBrief, leaving the agent to infer the GCC/OT scope 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?

It notes the bulletin comes from 'the same intel.db pipeline as /ot/sitrep', which hints at relatedness, but gives no explicit when-to-use guidance or when to prefer this over getSectorSitrep, getAnalystBrief, or getSectorDelta. Selection among a dense set of brief/sitrep siblings is left entirely to inference.

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?

Goes well beyond the annotations: it declares full determinism and no LLM/trained model, defines the output nature (flags inconsistency and direction, not a cause), and — most importantly — discloses the x402 payment requirement, the $0.20 USDC price, and the exact retry protocol for the PaymentRequired challenge. That is exactly the kind of auth/payment context annotations cannot carry.

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 purpose, then determinism, scope, and the payment/retry mechanics. Dense but every sentence carries weight; the payment paragraph is slightly verbose but operationally necessary for a paid 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?

With no output schema, the description steps in to characterize the return (inconsistency and direction flagged) and covers the invocation prerequisites. For a single-check tool with all params documented, this is close to complete, though the exact output shape is only roughly sketched.

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 all 8 parameters (including the noise_floor default and >0 constraints). The description adds no parameter-level syntax or format 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 (checks) and resource (tank/vessel level change vs flow-in/flow-out via conservation of mass) with unusual precision, and the method (physical-invariant residual check) is named. An agent can immediately tell this is a physical consistency validator rather than any of the cyber/threat-intel 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?

Implied usage is clear — use it to test physical consistency of tank readings — and the scope note (flags inconsistency and direction, does not assert a cause) usefully bounds expectations. However there is no explicit when-to-use/when-not guidance or named alternative among siblings, so guidance remains inferred rather than 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?

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the paid-call model: $0.01 USDC per call via x402 on Base mainnet, the exact failure mode (unpaid call returns an x402 PaymentRequired challenge), and the precise remediation (retry the identical call with the signed payload in _meta["x402/payment"]). That is exactly the operational context an agent cannot infer from structured fields.

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

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

Three tight sentences: purpose and sources first, return value second, payment protocol third. No filler, and the critical payment/retry instruction is not buried.

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

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

No output schema exists, but the description states the return value (a verdict on ICS-targeting campaign linkage), and the payment workflow is fully specified, which is the main complexity for this tool. It stops short of describing verdict granularity or confidence fields, leaving a small gap.

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% with only two required parameters (value, type) and an enum for type, so the schema fully documents the inputs. The description adds no parameter-level detail such as accepted IOC formats, 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?

Names a specific verb+resource (IOC enrichment), the upstream sources (AlienVault OTX, AbuseIPDB), and the concrete output (verdict on ICS-targeting campaign linkage). This is clearly distinguishable from siblings like getThreatActor, getMalwareProfile, or getThreatScore.

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 name and the stated output: call it to enrich a single IP or domain. However, it never says when to prefer this over adjacent enrichment/context tools (getThreatScore, getCveTriage, getMalwareProfile), nor does it mention prerequisites such as wallet/payment setup beyond the mechanics of the failed-call retry.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the full payment contract: $0.15 USDC per call via x402 on Base mainnet, that an unpaid call returns a PaymentRequired challenge, and that the caller must retry the identical call with the signed payload in _meta['x402/payment']. This is exactly the kind of operational behavior an agent needs and cannot infer from annotations.

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

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

Purpose and fan-out are front-loaded, followed by output contents and the payment mechanics, with every sentence carrying information. The payment sentence is dense but load-bearing rather than 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?

With no output schema, the description correctly enumerates the return payload (hook, bullet observations, CTA, hashtags), describes the input routing, and covers the non-obvious payment/retry flow. Nothing material for a correct call is missing.

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

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

Schema coverage is 100% and both parameters already carry inline descriptions including the 'required if no X' conditional, so the schema does the heavy lifting. The description's fan-out sentence mildly reinforces that cve/actor are alternative inputs but adds no syntax or format detail beyond the schema. 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?

Names a specific deliverable (a LinkedIn post for a CTI/ICS security audience), states the data it fans out to (/ot/actor or /ot/cve + /ot/advisory), and enumerates the output components (hook line, 3-5 bullets, CTA, hashtags). It is clearly distinguishable from the sibling getXThread by the LinkedIn format and audience.

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 audience, the input mode (actor-or-CVE fan-out), and the 'ready to publish' framing give clear context for when this tool applies. It does not explicitly name the alternative (e.g. getXThread) or state exclusions, so it falls short of 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 only cover readOnlyHint and openWorldHint; the description goes well beyond by disclosing the paid-call behavior — $0.02 USDC via x402 on Base mainnet, an unpaid call returning a PaymentRequired challenge, and the exact retry contract using _meta["x402/payment"]. This is critical operational context an agent cannot get from structured fields.

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

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

Three dense sentences: coverage first, returned fields second, payment mechanics last. Every sentence earns its place with no filler.

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

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

With no output schema, the description compensates by naming the returned sections (capabilities, targeted OT protocols, attributed actor, MITRE ATT&CK for ICS techniques) and fully documents the payment round-trip. An agent has everything needed 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?

Schema description coverage is 100% with a single 'name' parameter, so the schema already documents the parameter fully. The description reinforces valid values by listing example names but adds no syntax or format detail beyond that, matching the baseline 3.

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+resource ('structured profiles of known ICS malware') and enumerates the covered malware families (PIPEDREAM, TRITON, INDUSTROYER2, etc.), which clearly separates it from sibling lookups like getThreatActor or getActorDossier. An agent can identify the tool 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 listed names imply the tool is a name-based lookup restricted to a known set of ICS malware, but the description never states when to use it over siblings or what happens for an unknown name. Usage is implied rather than guided.

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 only cover readOnlyHint and openWorldHint, but the description discloses substantial extra behavior: pricing ($0.20 USDC via x402 on Base mainnet), the exact failure mode (unpaid call returns a PaymentRequired challenge) and the recovery path (retry identical call with signed payload in _meta["x402/payment"]). It also flags the output origin (DeepSeek-synthesised) and epistemic framing (ICD-203 estimative language), which is valuable for interpreting results.

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 core purpose is front-loaded in the first sentence, followed by parameter guidance, return contents, and critical payment semantics. The payment/retry instructions are necessary for correct invocation and earn their length, though the DeepSeek-synthesised/ICD-203 sentence is slightly more editorial than strictly required.

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, the description carries the burden of describing return contents, and it does: matched ATT&CK ICS techniques mapped to D3FEND countermeasures with priority and rationale plus architecture recommendations. Combined with the payment flow and parameter combination rule, an agent has everything needed to call it successfully.

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

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

Schema description coverage is 100%, so both the parameter meanings and the at-least-one-of constraint are already fully documented in the schema. The description restates the selection rule but adds no syntax, format, or ambiguity resolution 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?

The description states a specific verb and resource ('Prescriptive D3FEND-mapped mitigation guidance') plus scope ('for OT/ICS threats'), which distinguishes it from siblings like getComplianceMapping or getCveTriage. An agent can identify the deliverable (ATT&CK ICS techniques mapped to D3FEND countermeasures with priority and rationale) without opening the schema.

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

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

The description gives clear context (OT/ICS threats) and the parameter-combination rule ('Pass one of actor, cve_id, or technique_id, optionally with vendor_stack'), which is implied usage guidance. However, it names no alternative sibling tools and provides no when-not-to-use guidance, leaving routing entirely to inference.

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=true and openWorldHint=true, so the safety profile is covered. The description adds real operational context beyond that: the x402 payment requirement, the PaymentRequired challenge on an unpaid call, and the exact retry mechanism via _meta["x402/payment"] — without this an agent would fail to invoke it. No rate-limit or auth detail is given.

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

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

Three sentences, front-loaded with purpose, then return contents, then payment mechanics. No wasted words, though the payment sentence is fairly 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?

With no output schema, the description enumerates the returned fields (availability, workarounds, downtime, live-patch flag, risk score) and fully explains the payment flow. An agent has everything needed to call it correctly; only minor gaps remain.

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% for the single 'id' parameter, so the schema already documents format and example. The description adds no syntax or format detail beyond it, matching the baseline 3 for a well-covered single-param 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+resource (patch feasibility for a CVE) and scopes it to OT/ICS environments, which meaningfully distinguishes it from generic siblings like getCveTriage or getMitigationMap. It does not explicitly name a sibling it is not, so it falls short of the top mark.

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 'OT/ICS environments' qualifier implies when this tool applies, but there is no explicit when-to-use vs alternatives statement and no exclusions. Usage must be inferred from the domain context.

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

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

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses that classification is a deterministic tactic-taxonomy lookup (no LLM), states a concrete price ($0.04 USDC via x402 on Base mainnet), and describes the exact payment failure path (PaymentRequired challenge, retry with signed payload in _meta['x402/payment']). This is exactly the behavioral context an agent needs to invoke it successfully.

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 bucketing behavior, followed by the determinism note and then the payment mechanics — a sensible priority order. The parenthetical bucket enumerations are dense but each clause carries required information; only the phrasing could be tightened.

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, the description carries the return-value burden and does so adequately by naming the two buckets an agent will receive. Combined with the payment and determinism disclosure, a single-parameter read tool is covered well, though exact response field structure remains unspecified.

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 'actor' parameter is fully documented in the schema, so the baseline is 3. The description references 'an actor's known TTPs' but adds no syntax or format guidance 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?

States a specific verb (buckets) and resource (an actor's ATT&CK-for-ICS TTPs), then defines the two output buckets precisely — pre-impact (recon through C2) vs impact-stage (inhibit-response-function, impair-process-control, impact). This function is distinctive enough that an agent can separate it from siblings like getThreatActor or getActorDossier without opening a schema.

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

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

The description frames the pre-impact bucket as 'the early-warning window before physical/process disruption,' which implies when the tool is valuable, but it never explicitly states when to use this versus alternatives (e.g., getThreatActor for full TTPs) or any exclusions. Usage is inferable rather than directed.

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 cover only readOnly/openWorld, so the description carries the important behavioral burden and does so richly: paid call ($0.40 USDC via x402 on Base), an unpaid call returns a PaymentRequired challenge, and the retry must carry the signed payload in _meta["x402/payment"]. This is exactly the operational context an agent needs to invoke it successfully.

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-loads the core purpose, then the sibling relationship, then payment mechanics. Slightly repetitive with '/ot/threat-score' referenced twice, but every clause is informative and there is no filler.

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

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

With no output schema, the description usefully states what is returned (a DeepSeek-written executive summary in BLUF/ICD-203 style) and fully explains the paid-call flow. Completeness is good; only a brief note on ranking output shape or failure modes beyond payment is absent.

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 all five parameters, giving a baseline of 3. The description only restates the sector+region scoping and the vendor_stack->capability-score link, which the schema already provides, so it adds no meaning beyond structured data.

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: aggregates the capability x opportunity x intent scoring across actors for a sector+region, ranks them, and returns an executive summary. It explicitly positions itself as the portfolio-level companion to /ot/threat-score (getThreatScore), letting an agent distinguish it from the single-target 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?

Gives clear context for use (vCISO agents, GRC/board-reporting automation) and names the relationship to /ot/threat-score as the single-target alternative. It stops short of an explicit when-not-to-use rule (e.g., 'do not use for a single actor'), but the routing intent is inferable.

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?

Goes well beyond the readOnlyHint/openWorldHint annotations: it discloses determinism, absence of LLM/trained model, the paper it is and is not based on, exact pricing ($0.15 USDC via x402 on Base mainnet), and the concrete failure path (unpaid call returns PaymentRequired, retry with signed payload in _meta['x402/payment']). That is precisely the behavioral context an agent needs to invoke successfully.

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 operation and mechanism, then the trust note, then the payment flow. Four sentences, all load-bearing except the citation disclaimer, which is defensible but slightly 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 stateless paid computation with no output schema, the description covers mechanism, determinism, cost, and the payment retry protocol. It stops short of describing the shape of the ranked result (sensor_id + score, top_k entries), which the absence of an output schema leaves partially inferred.

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 documents top_k, window format (URL-encoded JSON array, max 20 entries, baseline fields), and anomaly_event_id echo semantics. The description only restates that the window is caller-supplied, adding no syntax or constraint beyond the schema, 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 and resource ('ranks which sensors most likely drove a reported anomaly') plus the exact mechanism ('z-score deviation from each sensor's own baseline'). This is unlike any sibling, which are all report/exposure/dossier getters, so the agent can distinguish it immediately.

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

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

Implied usage is clear from the precondition ('given a caller-supplied telemetry window') and the method note (per-sensor baseline required), but there is no explicit when-to-use/when-not-to-use statement and no named alternative among siblings. The agent must infer the frame of applicability.

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 only cover readOnly/openWorld, but the description adds critical operational behavior: a $0.10 USDC x402 price on Base mainnet, that an unpaid call returns a PaymentRequired challenge, and the exact retry mechanic (re-send with signed payload in _meta["x402/payment"]). This is behavior an agent cannot infer from structured fields and would otherwise discover by failing.

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-loads the deliverable and its contents, then the cost/payment mechanic in two compact sentences. Dense with zero filler; every clause carries either scope or an actionable payment instruction.

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, the description compensates by enumerating the returned fields, and it covers the non-obvious x402 payment path. The only gap is it doesn't clarify how the configurable 'period' interacts with the '30-day' framing, but overall an agent has enough to call 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?

Schema coverage is 100% with both params documented, so the schema does the heavy lifting and a 3 is the baseline. The description implies a 30-day window but does not clarify that the 'period' parameter can override it, leaving a small mismatch between the fixed '30-day' framing and the configurable parameter.

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+resource ('Complete 30-day threat brief for an industrial sector') and enumerates the exact payload (actors, CVE counts, campaigns, advisories, trend, top 3 actions), so an agent knows precisely what it produces. It also positions itself against the broad family with 'One call replaces 5+ chained calls.'

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?

'One call replaces 5+ chained calls' gives a clear usage signal: reach for this instead of composing several narrower lookups. It stops short of naming a specific alternative (e.g., getSectorSitrep or getSectorDelta) or stating when not to use it, so no explicit exclusions.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the cost ($0.03 USDC per call via x402 on Base mainnet) and the exact failure/recovery path for unpaid calls, including where to put the signed payload. This is precisely the operational context an agent needs and cannot get from the schema or annotations.

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

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

Three sentences, front-loaded with the purpose, then audience, then payment mechanics. No filler and nothing repeated from the schema or annotations.

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, the description does state what the response contains (new CVEs, advisories, actor activity) and fully covers the payment/auth path. It omits pagination, result-size limits, and accepted sector values, but the core picture needed to invoke it is present.

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

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

Schema description coverage is 100%, with both `days` (default 7, max 30) and `sector` documented in the schema. The description's "last N days" only loosely restates the `days` parameter and adds no format, enum, or validation detail beyond it, 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?

"What is NEW for a sector in the last N days" states a specific retrieval operation with explicit scope (delta only) and enumerates the returned content types (new CVEs, CISA advisories, actor activity). This clearly separates it from siblings like getSectorBrief and getSectorSitrep, which provide full pictures rather than changes.

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?

"Designed for cron-based monitoring agents" and "Only returns changes" give a clear use context and implicitly frame it against full-summary siblings. It stops short of explicitly naming an alternative (e.g. getSectorBrief) for the non-delta case or stating exclusion conditions.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses the fan-out behavior across five endpoints, the exact cost ($0.35 USDC per call via x402 on Base mainnet), and the failure mode for unpaid calls including how to retry with the signed payload in _meta["x402/payment"]. That is precisely the operational context annotations cannot carry.

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

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

Three sentences, front-loaded with what the tool is and what it returns, then the payment mechanics. The payment sentence is long but earns its place because the retry protocol is non-obvious and essential to a successful call.

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, the description carries the burden of describing the return contents (threat landscape, top actors, advisories, deltas, compliance impact, weekly priorities) and it does so. Combined with cost and payment-failure handling, 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?

Schema description coverage is 100% for both parameters, so the schema already documents 'sector' enumerations and the 'period' lookback default. The description only restates the 30-day default and adds no format or constraint detail beyond the schema, making the baseline 3 appropriate.

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

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

The description names a specific deliverable ('30-day situation report for an industrial sector') and enumerates the fan-out endpoints and the sections returned, so the agent knows exactly what it produces. It does not contrast itself with nearby siblings such as getSectorBrief or getSectorDelta, which is the only thing keeping it off 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?

Usage is implied by the '30-day situation report for an industrial sector' framing, and the payment/retry protocol is spelled out clearly, which is real invocation guidance. However, there is no explicit when-to-use versus alternatives (e.g., the lighter getSectorBrief or the delta-only getSectorDelta), so selection still requires inference.

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 readOnlyHint/openWorldHint already declared, the description adds meaningful context: deterministic lookup with no LLM in the path, $0.20 x402 pricing, and the exact unpaid-call retry behavior. These are non-obvious operational traits not captured by annotations, though return shape 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?

Purpose is front-loaded after a dense paper citation and version/date boilerplate that is mostly extraneous. The payment and lookup-path sentences earn their place, but the bibliographic detail bloat offsets the otherwise tight structure.

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?

There is no output schema, so the description must characterize returns; it does at a high level (full/partial/none plus actionability) and explains the payment/retry flow. A short note on response fields or how partial vs none is signaled would push it higher, but it is adequate for a simple 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 all four parameters (cve_id, campaign, protocol, technique_id) are already documented in the schema, including the at-least-one requirement and examples. The description adds no parameter-level 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?

The description names a specific verb+resource: it returns STIX 2.1 representability (full/partial/none) and detection-actionability for a technique/protocol/CVE. Purpose is concrete and distinct from siblings like getDetectionArtifacts. It stops short of naming an alternative sibling, so a 4 rather than 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?

It implies the use case (checking whether artifacts are representable and reportable) but never states when to prefer this over siblings such as getDetectionArtifacts or getCveTriage. Usage must be inferred from the purpose statement rather than read off explicitly.

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 and openWorldHint; the description adds important non-schema behavior: pricing via x402, the PaymentRequired challenge on unpaid calls, and retry with _meta payment. It still omits rate limits and response details, so not 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?

The description is front-loaded with purpose and content, then alias and payment mechanics, with little wasted text. It is dense but still readable; a slightly cleaner structure would separate retrieval semantics from payment instructions.

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, the description lists what the profile contains, which gives the agent return-value expectations, and it explains the x402 payment flow. It stops short of covering unknown-actor behavior or exact response shape, but is complete enough for a one-parameter 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% and already describes the name parameter with examples, but the description adds useful alias normalization (Volt Typhoon→VOLTZITE, APT44→SANDWORM). That extra mapping meaningfully improves parameter use 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?

States a specific resource and enumerates the profile contents (MITRE ATT&CK for ICS techniques, malware, attribution, physical impact, targeted sectors). It does not explicitly distinguish itself from sibling tools such as getActorDossier or getActorReport, so it misses 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 alias-lookup examples imply how to supply names, but there is no explicit when-to-use guidance or comparison to sibling actor tools. An agent can infer this is the actor-profile lookup, but must guess when to choose it over getActorDossier/getActorReport.

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?

Adds substantial context beyond the annotations: deterministic keyword-pattern matching with no LLM, advisory-only with no containment or network action, and full x402 pricing mechanics including the PaymentRequired challenge and the _meta["x402/payment"] retry path. This is exactly the operational detail structured fields cannot carry.

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-loads what it detects before provenance, safety posture, and payment mechanics. Every sentence carries distinct information; only the arXiv citation borders on filler for an invoking agent.

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?

Constraints, safety posture, and payment flow are all covered, and with no output schema the description should ideally hint at return shape (verdict/score/evidence fields), which it does not. Otherwise complete for a 3-param read 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 coverage is 100%, so baseline would be 3, but the description adds real semantics: OT-zone matches are always scored HIGH, reinforcing the zone enum's meaning. The 'at least one of processes or commands' rule is echoed rather than expanded, so no full 5.

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 ('Flags') plus the exact resource: control-loop recon patterns and LOTL/RMM-tool abuse derived from caller-submitted process/command observations. The subject matter is narrow enough to be separable from siblings (dossiers, advisories, detection artifacts), though no sibling is named 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?

Clearly says what input is required ('caller-submitted process/command observations') and warns it is advisory-only, but never states when to reach for this versus getDetectionArtifacts or getPrecursorTtp. Usage is implied by the input type rather than prescribed.

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 cover only readOnlyHint and openWorldHint, but the description adds materially more: the score is deterministic and not LLM-generated, it draws on named source classes (actor/CVE/campaign, GDELT, OFAC), and it discloses the paid x402 flow including price, chain, and the PaymentRequired-then-retry-with-signed-payload behavior. This is exactly the behavioral context an agent needs to invoke it successfully.

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

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

Three sentences, front-loaded with the purpose, followed by provenance and then the payment mechanics, with no filler. Slightly dense in the final sentence, but every clause is actionable.

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-required-parameter scoring tool with no output schema, the description covers provenance, determinism, and the full payment/auth path well. Its one gap is the return shape: with no output schema present, the description should indicate what the score looks like (range, breakdown, or confidence), which it does not.

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 four parameters (actor, region, sector, vendor_stack) are already documented with examples and the 'none' fallback. The description adds no parameter-level meaning beyond the schema, 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?

The description names a specific computed artifact ('deterministic capability x opportunity x intent threat score') for a specific input pair (actor-target), and identifies its data sources. It is clearly distinguishable from sibling scoring tools like getRiskExposure, getAssetExposure, or getActorDossier, which do not describe a composite threat 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?

Usage is only implied: the agent can infer this is the composite scoring tool for an actor/target pairing, but there is no explicit when-to-use guidance and no comparison against scoring-adjacent siblings such as getRiskExposure or getAiAttackFeasibility. The payment retry instructions are the only operational guidance offered.

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 only cover readOnlyHint and openWorldHint. The description adds the two things that really matter and that annotations cannot express: a $0.15 USDC x402 cost on Base mainnet, and the exact failure mode (PaymentRequired challenge) plus recovery path (retry identical call with signed payload in _meta['x402/payment']). That is precisely the behavioral context an agent needs before invoking.

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

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

Front-loaded with purpose, then outputs, then payment mechanics — a logical order with no wasted preamble. Slightly dense, and 'DeepSeek-synthesised, ICD-203 language' is flavor rather than actionable, but it is brief.

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?

Even with no output schema, the description enumerates the returned fields, states the cost, and documents the payment error path. For a two-parameter read-only tool this leaves no operational gap.

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% with only two documented parameters, so the schema already carries all parameter meaning. The description adds no syntax or filtering detail beyond what the schema states. 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?

States a specific verb (risk assessment) and resource (OT/ICS supply-chain vendor), plus the concrete outputs (risk tier, confidence, cited CVEs, threat actors, mitigations). However it never distinguishes itself from the obvious sibling getVendorRiskDelta, leaving the agent to guess which one to 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?

Usage is implied by the OT/ICS supply-chain framing, and the description gives procedural guidance for the payment retry loop. But it never says when to prefer this over getVendorRiskDelta or when a vendor risk assessment is appropriate vs other intelligence 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?

Annotations declare readOnlyHint=true and openWorldHint=true, and the description adds substantial beyond-annotation context: the $0.20 USDC/x402 price, the PaymentRequired challenge on unpaid calls, and the exact retry mechanism via _meta['x402/payment']. This is exactly the auth/payment behavior an agent needs to invoke the tool successfully.

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

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

Three sentences, purpose front-loaded ahead of the payment mechanics. Every sentence earns its place, though the payment detail adds length that is justified only because the x402 flow is non-obvious.

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, the description usefully states what is returned (risk-tier delta plus per-vendor summaries) and fully covers the payment/auth flow. For a two-required-parameter read tool it is essentially complete, with only return-format detail (structure of the delta) left unspecified.

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 four parameters (including the optional product_current/product_proposed) are already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, 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+resource ('counterfactual vendor-swap risk comparison') and clarifies scope by naming the underlying assessment '/ot/vendor-risk' as the per-vendor engine. It also names the sibling getVendorRisk implicitly, letting an agent distinguish the delta-comparison tool from the single-vendor tool 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?

Gives a clear usage context ('for pre-purchase or migration decisions') and frames itself as counterfactual comparison versus a single assessment. It does not explicitly name getVendorRisk as the alternative to use for a single-vendor lookup, so the routing guidance is clear but not fully enumerated.

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?

Goes well beyond the readOnly/openWorld annotations by disclosing the return shape (5-7 posts with defined structure and 280-char limit), the cost ($0.10 USDC via x402 on Base mainnet), and the exact payment failure/retry flow including the _meta key for the signed payload. This is critical operational context an agent cannot infer from structured data.

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

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

Front-loaded with purpose, then output structure, then pricing/payment in a logical progression. Every sentence carries information, though the payment mechanics are dense. Slightly packed but no wasted 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?

With no output schema, the description takes on the burden of describing returns, which it does well (post count, composition, character limit). Payment and retry semantics are covered. Only minor gaps remain, such as hard failure modes or rate limits, so not quite a 5.

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

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

Schema coverage is 100% and both parameters carry their own descriptions ('required if no actor' / 'required if no cve'), so the schema does the heavy lifting. The description's 'for an actor or CVE' merely restates the either/or pattern. Baseline 3 applies when schema is comprehensive.

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+resource (generates an X/Twitter thread for an actor or CVE) with the target platform named. The 'X/Twitter' framing implicitly distinguishes it from the LinkedIn sibling (getLinkedinPost) without ambiguity. An agent can tell what this produces at a glance.

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 indicates the input choice ('for an actor or CVE') but offers no explicit when-to-use-vs-when-not guidance against alternatives like getLinkedinPost or getActorReport. Usage is implied rather than spelled out. No exclusions or prerequisites are given beyond the payment note.

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?

Adds substantial behavior beyond what readOnlyHint=false and openWorldHint=true convey: anonymization (no org identifier stored), the destination store ('not intel.db'), a per-call price, and the full x402 failure/retry protocol including the _meta['x402/payment'] payload location. This is exactly the kind of non-obvious operational detail annotations cannot express.

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-loads purpose, then anonymity/storage behavior, then the cost and retry protocol. Four sentences, each adding distinct actionable information with no filler.

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

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

For a mutation tool with no output schema, it covers the write target, the privacy guarantee, the cost, and the payment round-trip including the retry requirement. Nothing an agent needs to invoke it successfully 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 all five parameters are already documented in the schema, and the description adds no parameter-level syntax or format detail beyond what is there. Baseline 3 applies when the schema carries the semantics.

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

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

States a specific verb and resource ('Submit an anonymized IOC/TTP sighting'), scopes it to the caller's own OT environment, and distinguishes itself from the entirely read-oriented get* sibling set. An agent can tell this is the sole write/contribution path 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?

Clear context on when to use it (sightings the caller directly observed in their own OT environment, to feed the correlation corpus) and a concrete operating procedure for the payment flow. It does not name explicit exclusions or alternatives, but no sibling competes with it since all are read tools.

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