Skip to main content
Glama

Calculate Demurrage & Detention Costs

shippingrates_dd_calculate
Read-onlyIdempotent

Calculate demurrage and detention (D&D) costs for one carrier in one country.

Use this when the user needs a detailed cost breakdown for a specific carrier. Returns free days, per-diem rates for each tariff slab, and total cost. This is the core tool for logistics cost analysis — it answers "how much will I pay if my container is detained X days?"

To compare D&D costs across all carriers at once, use shippingrates_dd_compare instead.

By default this returns carrier detention/demurrage. Pass charge_type="storage" to instead get TERMINAL port storage — a distinct charge billed by the terminal, not the carrier, and never mixed into the default D&D answer. Storage coverage is thin — only a handful of carrier/country lanes have it. Any uncovered combo returns an explicit 'no data' error (never a false $0), and that error names the lanes that ARE covered, derived live from the database rather than from a hardcoded list that would go stale.

PAID: $0.10/call via x402 (USDC on Base or Solana). Without payment, returns 402 with payment instructions.

Returns: { line, country, container_type, days, free_days, breakdown, total_cost, currency, charge_type_served, charge_family: 'carrier_dd'|'terminal_storage' }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
daysYesNumber of detention days
lineYesShipping line slug — maersk, msc, cmacgm (or cma-cgm), hapag-lloyd, one, cosco, zim, evergreen, yangming, hmm, arkas, oocl, pil
countryYesISO 2-letter country code (e.g. IN, AE, SG)
directionNoimport or export (default import)
x_paymentNox402 payment proof header (optional — required for paid access)
charge_typeNoOverride the charge type; default is the engine's detention→demurrage→combined priority. 'storage' is a distinct TERMINAL charge (not carrier D&D) and is ONLY ever returned when explicitly requested here — thin coverage, see tool description.
container_typeYesISO 6346 container type — 20GP, 40GP, 40HC, 20RF, 40RF, 20OT, 40OT, 45HC, 40FR, 20FR, 40DG, 20DG, 45RF, 45OT, 45DG, 40TK, 20TK, 45GP, 45TK, 40NOR

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/non-destructive/idempotent, and the description adds substantial behavioral context: no false $0 responses, live-derived lane coverage in errors, charge-type priority defaults, and the x402 payment requirement with 402 response on non-payment. No contradictions with annotations.

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?

The description is organized into clear paragraphs with front-loaded purpose, but it is somewhat wordy (e.g., the 'live from the database... go stale' clause could be trimmed). All content is relevant, though a few phrases are redundant.

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

Completeness5/5

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

Given 7 parameters, no output schema, and payment/coverage edge cases, the description provides a complete picture: return field names, error behavior, storage caveats, and payment flow. It would be improved only by a structured output schema, but as a description it fills that gap adequately.

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 covers 100% of parameters with descriptions, so baseline is 3; the description elevates this by explaining charge_type semantics (terminal storage vs carrier D&D, only returned when explicitly requested) and the payment header requirement. It also clarifies the default detention→demurrage→combined priority, adding meaning beyond enum values.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Calculate demurrage and detention (D&D) costs for one carrier in one country.' It further clarifies scope (detailed cost breakdown, free days, per-diem rates, total cost) and explicitly distinguishes from the compare sibling, making selection unambiguous.

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

Usage Guidelines5/5

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

It provides explicit when-to-use ('Use this when the user needs a detailed cost breakdown for a specific carrier') and names the alternative for multi-carrier comparison (shippingrates_dd_compare). It also covers conditional usage for storage via charge_type and outlines the no-data error expectation, giving the agent clear decision rules.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.6/5.0
Disambiguation5/5

All 26 tools have clearly distinct purposes, with detailed descriptions that differentiate overlapping areas (e.g., transit vs. schedule vs. vessel schedule). Even closely related tools like dd_calculate, dd_compare, and dd_countdown are well-delineated.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with prefix 'shippingrates_'. Compound names use underscores predictably (e.g., dd_calculate, inland_compare, vessel_schedule_options), making the naming scheme highly predictable.

Tool Count4/5

26 tools is slightly above the ideal range, but the breadth of features (rates, D&D, inland, congestion, risk, schedules, etc.) justifies the count. Each tool earns its place, and there is minimal bloat.

Completeness5/5

The tool set covers all major aspects of shipping intelligence: rates, surcharges, local charges, D&D, inland haulage, congestion, risk, transit, schedules, regulatory updates, and discovery tools. No obvious gaps for the stated purpose.

Resources