gulf_maritime_exposure

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

The description explicitly discloses that the tool is pre-compliance evidence triage only, with no live retrieval, does not resolve vessel ownership or verify identity, no legal or sanctions advice, and requires human review. With no annotations provided, the description carries the full burden, and it does so clearly. It adds context about decision-readiness scoring and evidence gaps that are not present in the schema. It could be more explicit about whether it mutates state, but the read-only nature is strongly implied by 'triage' and the return semantics.

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 dense but well-structured: one sentence for the scope and risk facets, one for the input format/returns, and one for limitations and human review. No filler words. The key limitation (no live retrieval, human review required) is front-loaded before the returns are fully described, which is a good ordering for risk-sensitive tools.

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

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

The tool has a single parameter with extensive schema documentation and an explicit pointer to the full schema via get_schema('gulf_maritime_exposure_request'). The description covers all key behavioral context, inputs, returns, and caveats. The output schema is absent, but the description covers the key outputs (triage recommendation, exposure signal, decision-readiness score, source comparison). For a complex, sensitive tool, no critical information for correct invocation is missing.

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

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

The schema description coverage is 100% for the single top-level parameter (exposure_request), with a detailed inline description and a reference to the full schema via get_schema. The tool description adds value by explaining the purpose of passer input (vessel/voyage, route, cargo, counterparties, dated_sources, risk_question, decision_stage) and confirming the matching schema. It doesn't repeat field-by-field semantics but points to the authoritative schema contract, which is appropriate at this parameter's level.

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

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

The description clearly states the tool triages maritime sanctions and chokepoint-disruption exposure for vessels/voyages through specific regions (Hormuz, Persian/Arabian Gulf, Gulf of Oman, Bab-el-Mandeb, Red Sea). It names specific risk facets (Iran-oil, Russia price-cap, dark-fleet, STS transfer, flag-hopping, P&I gap, AIS manipulation) and explicitly notes the input schema reference. This distinguishes it from broader sibling tools like middle_corridor_deal_risk or cis_secondary_sanctions_exposure, which focus on other geographies/risks.

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

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

The description provides clear guidance on when the tool is appropriate — for pre-compliance evidence triage of vessel/voyage risk in specific Gulf/Red Sea regions. It explicitly states the tool does NOT do live retrieval, resolve ownership, verify identity, or provide legal advice, and calls for human review. However, it does not explicitly name alternative sibling tools to use when those excluded functions are needed, so it falls slightly short of an explicit 'instead use X' pattern.

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