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

Annotations only declare readOnlyHint=true; the description adds the substantive behavior an agent needs, namely what is returned (summary plus substrate serialized from the page's data modules), how it is structured (assumption scenarios / threat systems / affected assets, each with sources and authority tiers), and that capped lists carry true totals. The explicit disclosure that simulation is unavailable here is a genuinely useful limitation. It loses a point only because the serialized shape is described in prose rather than mapping cleanly to a predictable response contract.

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 one-line purpose, then the enumeration, then return semantics and the interactive-only caveat in priority order. It is dense but every clause carries information; phrases like "capped lists shipping their true totals" are terse to the point of mild opacity.

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 must explain return values and does: summary, substrate contents, per-item sourcing, authority tiers, and list truncation. Combined with the interactive-only caveat, an agent has everything needed to call this 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 0%, so the description carries the full burden, and it does so by glossing every enum value: TSMC disruption scenarios, IRGC missile range vs Gulf compute, Japan memory-fab exposure, Saudi grid. An agent can pick the right scenario_id without guessing.

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?

"Fetch geopolitical compute risk scenarios" is a specific verb plus resource, and the four enumerated scenario IDs immediately show the scope. Nothing here overlaps with siblings like scrutica_get_company or scrutica_get_facility, so an agent can route on the first sentence 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?

The enumeration of the four available scenario IDs functions as a de facto selection guide, and the closing note that the propagation simulation is interactive-only at the returned URL marks a clear capability boundary. It stops short of naming when to prefer a sibling tool (e.g. search vs. this fetch), so it is clear context without explicit exclusions.

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