Skip to main content
Glama

SMKlog Parcel Shipping Rates

Get live parcel shipping rates from a US origin

get_parcel_quote
Read-only

Live shipping rates for one parcel sent from a US origin — inside the US, or to Canada, the UK, Germany or Australia — across USPS, UPS and FedEx, and DHL Express on the German and Australian lanes. Describe the item in plain words and the packed box size and weight are estimated. Give exact dimensions and weight to skip the estimate. Returns up to five purchasable services with the checkout total, the carrier cost beneath it and the SMKlog fee stated separately.

Manual review: oversized, palletized or crated shipments are priced by a person. Clients that declare the io.modelcontextprotocol/tasks extension get a durable task handle (poll it with tasks/get, answers usually take a few business hours). Others get a pointer to the human review page. Shipping labels are bought on smklog.com, not through this tool.

Choosing between the tools: use this one to answer what a shipment would cost. Then hand the quote_id it returns to create_checkout_link once the human has settled on shipping this exact parcel, so the pair costs one carrier call rather than two. Use get_price_index instead for typical or historical prices: it is free, while this tool spends a rate-limited carrier call every time.

Parameter rules:

  • weight_lb, length_in, width_in and height_in count only as a set of four, each above zero. Leave any one out and all four are ignored in favor of the estimate, so never send weight alone.

  • Online pricing covers one parcel up to 150 lb, 108 in on the longest side and 165 in of length plus girth. A heavier or larger box, a quantity above 1, or a product worded as freight (pallet, LTL, truckload, machinery, bulk) returns no rates and goes to a person.

  • product is the item itself, up to 200 characters. A bare route ("to Canada"), a bare weight ("7 lbs") or a question is refused as product_not_recognized before any carrier is called.

  • from_zip must be a real 5-digit US ZIP (ZIP+4 is trimmed to five), or the call fails with invalid_us_zip.

  • to_zip follows to_country: a 5-digit ZIP for US, otherwise that country's own postal code handed to the carriers as typed. A to_country outside US, CA, GB, DE and AU is refused as international_unsupported_online, so do not retry it with a different box.

  • Allowance: 80 calls an hour per client, shared with the public /quote route.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
to_zipYesDestination postal code: a 5-digit ZIP for the US, or the destination country's own postal code, e.g. M5V 2T6 for Toronto or SW1A 1AA for London.
productYesPlain-words item description, e.g. "65 inch flat screen TV in original box".
from_zipYesOrigin US ZIP code, 5 digits. The origin is always in the United States.
quantityNoIdentical parcels in this shipment. Default 1.
width_inNoPacked box width, inches.
height_inNoPacked box height, inches.
length_inNoPacked box length, inches.
weight_lbNoPacked weight, pounds. Decimals allowed.
to_countryNoTwo-letter destination country: US (default), CA, GB, DE, AU.US

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoQuote mode; "freight_manager" routes to a human review
ratesYesPurchasable services, cheapest first
packageNoThe packed box the rates were computed for
quote_idNoHandle to this quote, good for 15 minutes. Pass it to create_checkout_link as quote_id and that call spends no second carrier call. Null when no rate came back, or when the handle could not be stored.

TDQS

A5/5.0
Behavior5/5

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

Annotations (readOnlyHint=true, idempotentHint=false) cover the safety profile, and the description goes well beyond them: each call consumes a rate-limited carrier call, there is an 80-calls/hour allowance shared with the public /quote route, dimension/weight limits divert to manual review, and the three named failure modes (product_not_recognized, invalid_us_zip, international_unsupported_online) are disclosed. It also states that shipping labels are bought on smklog.com, not through this tool, which prevents an agent from assuming checkout behavior. No contradiction with the annotations.

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?

The description is long, but every section earns its place: scope is front-loaded, followed by return shape, manual-review fallback, tool routing, per-parameter rules, and the rate limit. Sections are visually separated and ordered by decision relevance, allowing an agent to skim directly to the parameter rules without wading through prose. Nothing is redundant with the schema or annotations.

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?

For a 9-parameter tool with four named failure modes, a manual-review fallback, an estimation-vs-exact-dimensions path, and a rate limit, the description covers every invocation concern: lanes, carriers, purchasability and fee breakdown, task-handle polling via tasks/get versus a human-review page, quota, and the sibling-tool handoff. Since an output schema exists, return-value shape does not need description coverage.

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?

Although the schema already documents all 9 parameters (100% coverage), the description adds the critical set-of-four rule — weight_lb, length_in, width_in, and height_in are all ignored unless sent together, so 'never send weight alone' — which the schema cannot express. It also adds constraints invisible in the schema: product is capped at 200 characters and refuses bare routes, bare weights, or questions; from_zip trims ZIP+4 to five digits; to_zip semantics depend on to_country; quantity above 1 or freight wording returns no rates and goes to a person; and the 150 lb / 108 in / 165 in girth limits.

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 precise verb+resource statement — 'Live shipping rates for one parcel sent from a US origin' — and specifies the destination lanes (US, CA, GB, DE, AU) and carriers (USPS, UPS, FedEx, DHL Express on the German and Australian lanes). It is clearly differentiated from siblings: get_price_index covers typical/historical prices, while this tool returns up to five live, purchasable services with a quote_id for create_checkout_link.

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?

The 'Choosing between the tools' paragraph is explicit about when to use this tool (answer what a shipment would cost), when to use an alternative (get_price_index for typical or historical prices, because it is free while this tool spends a rate-limited carrier call every time), and how to sequence with create_checkout_link (hand it the quote_id once the human settles on the parcel, so the pair costs one carrier call rather than two). Exclusions are also stated: oversized, palletized, or crated shipments go to a person rather than being priced online.

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.9/5.0
Disambiguation5/5

Each tool targets a distinct operation: live quote versus checkout session versus reference index versus tracking. The only potential overlap is create_checkout_link's live-pricing fallback, but its stated purpose and required quote_id flow make the boundary clear.

Naming Consistency5/5

All four tool names follow the same imperative verb_noun pattern in snake_case: create_checkout_link, get_parcel_quote, get_price_index, track_parcel. No mixed conventions or vague verbs.

Tool Count5/5

Four tools is a well-scoped set for a parcel shipping domain: one for quotes, one for checkout links, one for reference pricing, and one for tracking. Each tool earns its place without bloat or redundancy.

Completeness4/5

The core workflow is covered: get a quote, create a checkout link, and track the resulting label, with a free price-index tool for reference. Minor gaps exist around post-purchase lifecycle operations like voiding labels or retrieving session status, but those are not central to the stated purpose.