Skip to main content
Glama
Sign In
Canada Post MCP Server

Canada Post MCP Server

by richardsondx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_rates

Get Canada Post shipping rates for a parcel route using origin and destination postal codes plus parcel dimensions and weight. Returns live rates with Developer Program credentials, or links the public Find a Rate calculator.

Instructions

Get Canada Post shipping rates for a parcel route. Needs official Developer Program credentials in env for live rates; without them it reports honestly and links the public Find a Rate calculator. Never invents a rate.

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": {
      "origin_postal_code": "<origin_postal_code>",
      "destination_postal_code": "<destination_postal_code>",
      "weight_kg": "<weight_kg>",
      "length_cm": "<length_cm>",
      "width_cm": "<width_cm>",
      "height_cm": "<height_cm>"
    },
    "name": "get_rates"
  }
}

Input Schema

NameRequiredDescriptionDefault
width_cmYesParcel width in centimetres.
height_cmYesParcel height in centimetres.
length_cmYesParcel length in centimetres.
weight_kgYesParcel weight in kilograms.
origin_postal_codeYesOrigin Canadian postal code, e.g. M5G 1N6.
destination_postal_codeYesDestination Canadian postal code, e.g. V6B 1A1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does disclose key behavior: a credential prerequisite, an honest degraded mode that links to the public Find a Rate calculator, and a no-fabrication guarantee. These are exactly the traits structured fields do not cover. It omits return shape (service levels, price fields) and any rate-limit or caching notes, which keeps it from a 5.

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?

Three short sentences, front-loaded with the core action before the credential caveat, with no filler. 'Never invents a rate' slightly restates the preceding 'reports honestly,' a small redundancy that keeps it just below top marks.

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 a six-required-parameter, single-purpose quote tool with no output schema, the description covers the operation, the auth prerequisite, and the failure mode. The main remaining gap is what the result looks like — service tiers, currency, price fields — which is unaddressed since no output schema exists to compensate.

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 description coverage is 100%, and all six required parameters (postal codes, weight, dimensions) are individually documented with units and examples in the schema. The description adds only the framing 'for a parcel route,' which does not extend meaning beyond the schema. Baseline 3 is appropriate when the schema already does the heavy lifting.

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 and resource: 'Get Canada Post shipping rates for a parcel route.' An agent can immediately tell this is a rate-quote tool, and the sibling names (find_post_office, list_mymail, track_parcel) are in unrelated domains, so no confusion is likely. It stops short of explicitly contrasting itself with any sibling, which keeps it at 4 rather than 5.

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?

The description gives clear operating context: live rates require official Developer Program credentials in the environment, and without them the tool falls back to reporting that fact plus a public calculator link. That is a usable when/when-not signal for invocation. It does not name an alternative MCP tool for the unauthenticated case, but the fallback behavior is described explicitly.

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

Deploy Server

Other Tools