Skip to main content
Glama

Aether-X Port Delay Intelligence

by io.github.belegante-byte
OverviewDiscussionsAdmin

evaluate_fiscal_routing

[DECISION TOOL] Evaluate fiscal and logistical arbitrage across alternative ports.

Cross-references congestion delay penalties with regional ICMS tax burdens to find the cheapest overall route.
Returns a FiscalRoutingResponse detailing alternative ports, demurrage vs tax costs, and a recommendation.

Args:
    intended_port_id: UN/LOCODE of the intended destination port (e.g. BRSSZ).
    commodity: Cargo type to lookup tax rules for (e.g. FERTILIZANTES, SOJA).
    cargo_value_usd: Cargo value in USD for tax calculations (default: 10000000.0).
    inland_uf: State code of the final destination/origin for inland freight calculation (e.g. MT, GO, PR).
    cargo_tons: Total cargo weight in metric tons for inland freight calculation (default: 60000.0).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commodityNoFERTILIZANTES
inland_ufNoMT
cargo_tonsNo
cargo_value_usdNo
intended_port_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that the tool is a decision/evaluation operation and that it returns a FiscalRoutingResponse with alternative ports, demurrage vs tax costs, and a recommendation. It does not state side effects, permissions/auth requirements, or cost/latency characteristics, leaving real gaps for a computation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the purpose and mechanism in two tight paragraphs before the args block. The args list is long but earns its place given zero schema-level documentation; only slight redundancy between the prose and the Args block.

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

Completeness4/5

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

An output schema exists, so the description need not detail return values, and it sensibly points to the FiscalRoutingResponse contents instead. Parameters are fully covered. The only shortfall is the absence of annotation-equivalent behavioral context (side effects, permissions), which is more critical when annotations are missing.

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

Parameters5/5

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, and it does fully: it documents all five parameters with formats and concrete examples (UN/LOCODE 'BRSSZ', commodities 'FERTILIZANTES/SOJA', UF codes 'MT, GO, PR'), plus units and default values for cargo_value_usd and cargo_tons.

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

Purpose4/5

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

States a specific verb (evaluate) and resource (fiscal/logistical arbitrage across alternative ports), and explains the mechanism: cross-referencing congestion delay penalties with regional ICMS tax burdens. However, it never distinguishes itself from the very close sibling evaluate_routing_alternatives, so an agent must infer the boundary.

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

Usage Guidelines3/5

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

The '[DECISION TOOL]' tag implies this is decision-support rather than raw data retrieval, and naming the arbitrage scenario gives an implicit context for use. But there is no explicit when-to-use, no exclusion, and no routing to alternative siblings like evaluate_routing_alternatives or evaluate_corridor_risk.

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

All Aether-X Port Delay Intelligence toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources