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

Annotations are minimal (just openWorldHint: true, no readOnly/destructive declarations), so the description carries reasonable weight here and does not contradict anything. The cost disclosure (264,590 credits/run) in the description is genuinely useful behavioral context not present in annotations—it signals this is expensive and should be used judiciously. However, the description doesn't add depth beyond that: no mention of auth needs, external calls, the ~90-day lookback requirement for commodity price series, or what 'evaluates' means in terms of deterministic analysis versus a one-shot compute.

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 short (one substantive sentence) and front-loads the core meaning, which is good. However, embedding JSON pricing data ('Pricing: {"unit": "credits", "per_run": 264590}') directly in the free-text description is a structural smell—this belongs in structured annotations or metadata, and creates a parsing burden for the agent. The description succeeds at being concise, but the embedded metadata reduces its cleanliness wholey.

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

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

For a tool with this complexity—1 top-level param with 12 nested fields, conditional requirements across 3 event types, and an output schema—the description is adequate at the 'what' level but doesn't enrich the 'why/when' the way annotations or richer null models would. The schema is solid and the target company reference is clear, but the description offers no guidance on how to construct a commodity_price event (e.g., pivot-relative columns) or how analysis_mode normal vs backtest should be chosen. It's a viable description that leaves meaningful interpretative work to the agent.

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 parameters—per the stated baseline, this earns a 3 without description compensation. The schema descriptions are thorough, including an excellent example for company_id ('a77828f060c866441f2403384b271e63 for Tesla, Inc.') and clear conditional requirements for each event_type. The description adds no parameter semantics beyond what the schema provides, which is acceptable here since the schema is well-populated.

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

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

The description uses specific verbs ('monitors', 'evaluates') with a clear resource (global supply chain risk events) and target (a target company), clearly distinguishing this analytical tool from the many data-retrieval siblings (chain_*, company_*, park_*). It clearly communicates the evaluation intent ('whether, how, and to what extent'), which goes well beyond the tool name. However, the overall framing reads more like a product pitch than a precise operational spec, and it doesn't prepend any usage context that would separate it from analytical siblings like due_diligence_report or sg_chokepoint.

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 task context is clear (monitoring supply chain events impacting a company) and the schema does excellent work documenting the three event_type branches (news, policy, commodity_price) with their conditionally-required fields. However, the description itself offers no explicit guidance on when to choose this tool versus alternatives like due_diligence_report or tariff_calc, and doesn't state when NOT to use it. The 'Continuously monitors' phrasing implies a recurring usage pattern, but doesn't explain whether the agent should call it periodically or once per event, leaving the convention-of-use to be inferred.

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