Othermile border costs

Border cost check

border_quote

Read-onlyIdempotent

Estimate duties, tariffs, taxes and fees for goods moving into Canada or the US, by parcel or freight (truck, rail, air, ocean), and whether any item is banned. Gives who pays under the Incoterm, and what the exporting country requires. Use before buying from or shipping across the border.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "from": "<from>",
      "to": "<to>",
      "mode": "<mode>",
      "items": "<items>"
    },
    "name": "border_quote"
  }
}

Input Schema

Name	Required	Description	Default
`to`	Yes
`date`	No	Date the parcel enters the destination country
`from`	Yes	Country the parcel ships from
`mode`	Yes	mail or courier for parcels (low value allowances apply); road (truck), rail, air, sea or inland_waterway for commercial freight
`items`	Yes
`paidBy`	No	Who pays border charges: the customer at the door (DAP), or the seller in advance (DDP). Ignored when incoterm is given	customer
`region`	No	Destination province or state, for example AB or ON
`freight`	No	International transport cost in the destination currency, to split costs by the Incoterm
`incoterm`	No	Incoterms 2020 term of sale; FAS, FOB, CFR and CIF are for sea and inland waterway
`personal`	No	true when a person buys the goods for their own use, as a shopper's parcel is; some surtaxes spare those. Leave out for a business import
`insurance`	No	Cargo insurance cost in the destination currency

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 24, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / items / items / additionalProperties
```
Removed value: -false
```
- addedInput schema / properties / items / items / properties / qty / maximum
```
Added value: +9007199254740991
```
First observedOct 20, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real value on top: it is an estimate, it flags banned items, and it resolves who pays under the Incoterm. It does not state how current the tariff data is or that results are non-binding, which matters for a compliance-adjacent quote.

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

Conciseness5/5

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

Three sentences, front-loaded with what is estimated, then the extra outputs, then the invocation trigger. No filler, and the ordering matches how an agent scans a definition.

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?

For an 11-parameter read-only calculator with no output schema, the description conveys the main computed outputs (duty/tax totals, ban check, Incoterm payer, export requirements). Missing is a hint at response shape or granularity (per-item vs. total) and any caveat on estimate accuracy.

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

Parameters3/5

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

Schema coverage is 82%, so the schema already documents from/to/mode/incoterm/paidBy/personal/freight/insurance. The description's 'by parcel or freight (truck, rail, air, ocean)' restates the mode enum and 'who pays under the Incoterm' restates paidBy/incoterm; it adds little about cusmaClaim, personal, region or the per-item origin/value fields.

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?

Specific verb ('Estimate') plus a concrete resource list (duties, tariffs, taxes, fees), with scope narrowed to Canada/US inbound and to parcel vs. freight modes. It also names the secondary outputs (Incoterm payer, exporting-country requirements), but never mentions the siblings border_lane_insights, border_rules_status or door_cost_estimate, so the boundary against door_cost_estimate in particular is left implicit.

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

Usage Guidelines4/5

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

'Use before buying from or shipping across the border' gives a clear decision context for invocation. There are no explicit exclusions or named alternatives, so an agent must still infer when border_rules_status or door_cost_estimate is the better call.

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

All Othermile border costs tools Inspect

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

Need Help?