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

Annotations already declare readOnlyHint, idempotentHint and non-destructive safety, so the bar is lower. The description still adds real behavioral value beyond them: it discloses data provenance (GDELT-based scoring) and, importantly, that transit and cost-pressure fields are retained for compatibility but are null in this edition — a caveat an agent would otherwise misread as missing 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?

One dense sentence that front-loads the resource and its fixed coverage, then the returned field families, then the null-field caveat. Every clause carries information; there is no filler or restatement of the title.

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

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

There is no output schema, so the description must carry the return shape, and it does: threat/activity scores, phase, news and sanctions intensity, NERAI read, plus the explicit null caveat for legacy fields. It stops short of stating units, scale, or freshness/cadence, which an agent consuming risk scores would benefit from.

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?

Zero parameters, so the baseline is 4; there is nothing to mis-specify. The description correctly implies a fixed, non-parameterized snapshot of all monitored corridors rather than a filterable query.

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

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

Specific verb and resource with an enumerated scope: it names all 8 monitored corridors (Hormuz, Suez, Red Sea/Bab-el-Mandeb, Black Sea, Malacca, Taiwan Strait, E. Mediterranean, South China Sea) and the field families returned. It does not explicitly differentiate itself from close siblings such as get_live_chokepoint_traffic or get_circumvention_corridors, so an agent must infer the split from content 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 description states what the tool returns but gives no when-to-use guidance, no prerequisites, and no routing to alternatives, even though the sibling list contains an obviously adjacent tool (get_live_chokepoint_traffic). The use case is only implicit in the resource name.

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