Check congestion risk for any port by entering its UN/LOCODE. Get predictive scores for delays, waiting vessels, and freight volatility to support supply chain decisions.
Return the predictive congestion signal for a single port.
Args: port_id: UN/LOCODE of the port, e.g. "BRSSZ" (Santos), "CNSHA" (Shanghai).
| Name | Required | Description | Default |
|---|---|---|---|
| port_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Return', implying a read operation, but it does not state side effects, response behavior, or limitations. This is minimal transparency beyond the tool's name.
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 the purpose and follows with a compact args block. Every sentence earns its place, with no filler or repetition.
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-parameter read tool, the description covers purpose and parameter format, and the output schema can handle return structure. It does not explicitly route to get_ports_risk for multi-port queries, but the singular wording and sibling names provide enough context.
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 must compensate. It defines port_id as a UN/LOCODE and provides two concrete examples (Santos and Shanghai), giving format and usage context that the bare schema field name 'Port Id' lacks.
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 ('Return'), a clear resource ('predictive congestion signal'), and a clear scope ('single port'). The singular/plural contrast with the sibling get_ports_risk helps an agent distinguish the tools 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?
Usage context is only implied by 'single port', which hints that this tool is for one port rather than a bulk query. However, it never explicitly names alternatives like get_ports_risk or states when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.