Live USPS, UPS, FedEx and DHL rates from the US: domestic, Canada, UK, Germany, Australia. No scale.
Scored across 5 tools
Each tool targets a distinct step in the shipping workflow: quoting, price-index reference, checkout creation, checkout status polling, and tracking. Even the two pricing tools are clearly separated by live shipment quotes versus historical index data, so there is no real risk of selecting the wrong one.
All tool names follow the same snake_case verb_noun pattern: get_parcel_quote, get_price_index, create_checkout_link, get_checkout_status, track_parcel. The verbs are consistently simple and the nouns clearly identify the resource.
Five tools is well-scoped for the server's purpose: quoting, reference pricing, checkout creation, status polling, and tracking. Each tool covers a distinct part of the parcel shipping workflow without redundancy or bloat.
The tool set covers the full user journey from getting a quote or index price, creating a checkout session, checking payment and label status, and tracking the parcel once a label exists. No obvious dead ends or missing lifecycle steps appear for the stated domain.
Turns a decided shipment into a payment session for buying its shipping label: the checkout amount and a handoff URL that opens SMKlog checkout prefilled with the parcel. Use it after get_parcel_quote, passing the quote_id that call returned, so the price is reused and no second carrier call is spent. Without a quote_id it prices the shipment live from the fields. The result carries a session_id: keep it, and get_checkout_status tells you when the human has paid and when the label exists.
Side effects: it writes a session record (30-day life, readable through get_checkout_status) and is not idempotent. Calling it twice makes two sessions and, without a quote_id, spends two carrier calls. It never charges: no card is touched and nothing is reserved until the human confirms the contents certification and the carrier-adjustment consent on the page and pays there. A stale link simply reprices.
No session is returned when a person has to price the shipment: freight, oversize, a quantity above 1, or an installed lithium battery crossing a border. Quote first to learn which case applies.
Parameter rules:
A valid quote_id overrides product, from_zip, to_zip, to_country and quantity. service is still honored.
An expired quote_id falls back to live pricing from the fields. If those were omitted too, the call fails with missing_required_fields, so pass them alongside an old id.
service is matched as a case-insensitive fragment of the display name ("Ground Advantage", "UPS Ground Saver"). A fragment that matches nothing silently anchors the quote's first rate, which is the top of the best-value ranking and not always the cheapest, so read the service field in the result.
from_zip is a real 5-digit US ZIP. to_zip follows to_country (US, CA, GB, DE or AU).
On the four international lanes the human completes the customs declaration on the page, and duty is billed to the recipient on arrival.
| Name | Required | Description | Default |
|---|---|---|---|
| to_zip | No | Destination postal code: a 5-digit ZIP for the US, or the destination country's own postal code. Required unless quote_id is given. | |
| product | No | Plain-words item description. Required unless quote_id is given. | |
| service | No | Service to anchor the amount to, e.g. "USPS Ground Advantage". Omitted or unmatched, the amount anchors the quote's first rate, top of the best-value ranking rather than the cheapest; the human can still pick any service on the page. | |
| from_zip | No | Origin US ZIP code, 5 digits. Required unless quote_id is given. | |
| quantity | No | Identical parcels in this shipment. Default 1. | |
| quote_id | No | The quote_id returned by a previous get_parcel_quote call. Valid for 15 minutes. | |
| to_country | No | Two-letter destination country: US (default), CA, GB, DE, AU. | US |
| Name | Required | Description |
|---|---|---|
| note | No | Standing caveats: live quote, human confirms consents and pays |
| amount | Yes | Live-quoted checkout total for the anchored service, USD |
| intent | Yes | Always "session" — this tool never charges |
| method | No | Payment rails behind the checkout, e.g. stripe, card |
| service | No | The service the amount is anchored to |
| currency | Yes | ISO currency, USD |
| session_id | No | Handle for get_checkout_status, shaped as_ plus a UUID, good for 30 days. Null only when the session record could not be stored. |
| handoff_url | Yes | Opens the SMKlog checkout prefilled with this shipment |
| quote_reused | No | True when the amount came from a quote_id you supplied, so no carrier call was spent. False when this tool priced the shipment live -- either because no quote_id was given, or because the one given had expired. |
| identified_product_title | No | What the estimator understood the item to be |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already include readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context: it writes a session record with 30-day life, is not idempotent, never charges, and describes side effects, stale links, and conditions where no session is returned. This goes far beyond what annotations alone provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized into labeled sections (Side effects, Parameter rules). It front-loads the core purpose and then details rules. While dense and arguably verbose, each sentence earns its place by conveying a rule or side effect an agent must know. Slightly over-long, but structure keeps it navigable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stateful, non-idempotent, side-effecting tool with 7 parameters and no required fields, this description is remarkably complete. It covers preconditions (quote first), postconditions (session_id, get_checkout_status), side effects (session record, carrier calls), error cases (missing_required_fields, no session returned), and parameter interactions. The output schema exists, so return values beyond session_id are covered elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds critical parameter meaning beyond the schema: quote_id overrides other fields, expired quote_id falls back to live pricing, service is matched as a case-insensitive fragment and silently anchors the first rate if unmatched, and from_zip/to_zip/to_country constraints. It explains failure modes and parameter interactions in detail, which the schema alone could not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Turns a decided shipment into a payment session for buying its shipping label') and clearly distinguishes itself from siblings by naming get_parcel_quote and get_checkout_status in the flow. It makes clear what the tool produces: a checkout amount and a handoff URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool ('Use it after get_parcel_quote'), what to pass (quote_id), and what happens if quote_id is missing. It also names the sibling get_checkout_status for checking payment status, giving the agent a clear comparison and routing guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports where a payment session made by create_checkout_link stands: whether the human has opened checkout, paid, and whether the shipping label exists yet, with the tracking number once it does. Reads SMKlog's own order records only: no carrier call, no quote allowance, nothing changes. Poll it after handing the human the link, minutes apart rather than seconds, because nothing moves until the human acts.
Statuses, in order: awaiting_checkout (link made, no checkout started), checkout_started (a checkout exists, not paid), paid (paid, label not created yet: the checkout page buys it right after payment, otherwise an operator picks it up), label_ready (label bought, tracking_number present), delivered, refunded. Once label_ready, feed tracking_number to track_parcel for scan events.
Parameter rules:
session_id is the session_id returned by create_checkout_link, shaped as_ plus a UUID. Nothing else identifies a session: no order id, no email, no quote_id.
A session lives 30 days from creation. An unknown, malformed or expired id answers session_not_found rather than a status.
The answer never carries names, addresses or emails. Treat the session_id like a tracking number: whoever holds it can read the tracking number.
A manual-review request made from the handoff page is not a checkout and leaves the status at awaiting_checkout.
Allowance: 60 checks an hour per client.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | The session_id from create_checkout_link. |
| Name | Required | Description |
|---|---|---|
| next | No | What, if anything, the agent should do now |
| amount | No | The amount the session was anchored to, USD |
| status | Yes | Stage, in that order |
| service | No | The service the session was anchored to |
| checkout | No | The checkout the human started, null while awaiting_checkout |
| currency | No | ISO currency, USD |
| created_at | No | When create_checkout_link made the session, ISO 8601 |
| expires_at | No | When the session stops answering, ISO 8601 |
| session_id | Yes | The session asked about |
| quote_reused | No | Whether the session reused a quote_id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses concrete operational behavior: no carrier call, no quote allowance, nothing changes, 30-day session lifetime, session_not_found sentinel, no PII in responses, and a rate limit of 60 checks per hour. It also warns that polling too fast is useless because nothing moves until the human acts. This is rich behavioral disclosure that materially affects how an agent should call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every section earns its place: statuses, polling cadence, privacy, expiry, manual-review edge case, and rate limit. It is front-loaded with the core purpose and then logically organized into statuses and parameter rules. There is no filler or tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for an agent to call this tool correctly: it names the input source, explains every possible status, gives the error sentinel for bad ids, states the rate limit, clarifies privacy, and directs onward to track_parcel. The output schema exists, so return-value details are not the description's burden. No critical operational gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already covers session_id with a pattern and description, the description adds essential semantics: the id shape 'as_ plus a UUID', that nothing else identifies a session, that unknown/malformed/expired ids return session_not_found rather than a status, and that the id must be treated like a tracking number. This goes well beyond the schema and compensates fully for any ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Reports where a payment session made by create_checkout_link stands.' It clearly distinguishes this tool from siblings by explaining it reads only SMKlog's own order records and later points to track_parcel for scan events. The status list further anchors what this tool does and what its output means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Poll it after handing the human the link, minutes apart rather than seconds.' It also tells the agent when to switch to a sibling tool: 'Once label_ready, feed tracking_number to track_parcel for scan events.' It adds exclusions like the manual-review request not being a checkout, which prevents incorrect invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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, each as one checkout total with the SMKlog fee inside it (the fee is itemized only on the checkout receipt) and, where the carrier publishes one, its own counter price for the same parcel beside it.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| to_zip | Yes | Destination 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. | |
| product | Yes | Plain-words item description, e.g. "65 inch flat screen TV in original box". | |
| from_zip | Yes | Origin US ZIP code, 5 digits. The origin is always in the United States. | |
| quantity | No | Identical parcels in this shipment. Default 1. | |
| width_in | No | Packed box width, inches. | |
| height_in | No | Packed box height, inches. | |
| length_in | No | Packed box length, inches. | |
| weight_lb | No | Packed weight, pounds. Decimals allowed. | |
| to_country | No | Two-letter destination country: US (default), CA, GB, DE, AU. | US |
| Name | Required | Description |
|---|---|---|
| mode | No | Quote mode; "freight_manager" routes to a human review |
| rates | Yes | Up to five purchasable services. Not cheapest first: they are ranked by best value, each rate scored as its checkout total in cents plus 175 per business day of transit (30 days when the carrier quotes none), lowest score first, and a rate that publishes a carrier counter price may lead a near-tie within 50 cents or 2 percent. Sort by amount yourself when you want the cheapest. |
| package | No | The packed box the rates were computed for |
| quote_id | No | Handle 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and idempotentHint=false. The description adds substantial behavioral context: it spends a rate-limited carrier call, returns up to five purchasable services, includes the SMKlog fee in the total, surfaces a human-review path for nonstandard shipments, and documents the 80-calls/hour allowance. No contradiction 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Long but densely informative, organized into clear sections: overview, manual review, tool selection, and parameter rules. The core purpose is front-loaded in the first sentence. Every paragraph and bullet adds distinct operational value such that trimming would reduce correctness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, live carrier calls, manual review fallback, sibling differentiation, rate limits) and the presence of an output schema, the description covers all necessary decision points. It even describes return shape (up to five checkout totals, fee inclusion, counter price) and error behavior, leaving no major gap for an agent invoking it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description goes far beyond the schema by explaining the all-or-nothing set rule for dimensions, the 150 lb / 108 in / 165 in limits, that quantity above 1 routes to manual review, that product should be the item itself and not a route/weight/question, ZIP normalization, and country-specific to_zip behavior. These are essential for correct invocation and are absent from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get live parcel shipping rates'), resource ('one parcel sent from a US origin'), and scope (carriers, destination countries). Immediately distinguishes itself from siblings via the 'Choosing between the tools' section, so an agent can tell it apart from create_checkout_link and get_price_index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool ('to answer what a shipment would cost'), when to use create_checkout_link (after a human settles, to reuse the quote_id), and when to use get_price_index (typical/historical prices, free). Also specifies exclusions: oversized/freight shipments go to manual review, and unsupported countries are refused.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The SMKlog parcel shipping price index: a monthly repriced basket of six common boxes (1 to 20 lb) shipped from Newark, NJ to five US cities, quoted through the same live USPS, UPS and FedEx pipeline that prices real shipments. Returns the cheapest purchasable service per box and lane with every rate behind it, plus basket averages. Reference data for questions like "what does shipping a shoebox cost in the US right now" — reading it spends no quote allowance. For a price on a specific shipment, call get_parcel_quote instead. Parameter rules: month names one published issue as YYYY-MM; issues exist from 2026-07 onward, one per month, and omitting month returns the newest. A month with no issue answers issue_not_found together with available_months, so one miss lists every valid value; anything not shaped YYYY-MM answers invalid_month. Every issue prices the same boxes and lanes, so two months compare cell for cell.
| Name | Required | Description | Default |
|---|---|---|---|
| month | No | Issue month as YYYY-MM. Omit for the newest published issue. |
| Name | Required | Description |
|---|---|---|
| page | No | The published issue page on smklog.com |
| cells | Yes | One entry per box and destination |
| label | No | Issue month spelled out, e.g. "August 2026" |
| month | Yes | Issue month, YYYY-MM |
| origin | No | Origin of every lane, Newark NJ (07102) |
| captured_on | Yes | The date every price in this issue was captured |
| methodology | No | How the numbers are produced |
| carrier_wins | No | How many cells each carrier priced cheapest |
| basket_average | No | Mean of the cheapest rate across all thirty cells, USD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, and the description adds valuable behavioral detail: reading spends no quote allowance, invalid month shapes return invalid_month, and missing issues return issue_not_found with available_months. It also states that every issue is directly comparable month-over-month, which is useful operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: definition, output, use case, alternative, and parameter rules are all front-loaded in a logical order. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only reference tool with one optional parameter and an output schema, the description covers purpose, use case, alternatives, parameter behavior, error semantics, and comparability. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description goes far beyond it: it specifies the YYYY-MM format, the default when month is omitted, the earliest available issue (2026-07), one-issue-per-month granularity, and the exact error responses for invalid or nonexistent months. This fully compensates for any ambiguity in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (SMKlog US parcel shipping price index), defines its scope (six boxes, 1-20 lb, Newark to five US cities), and states the output. It also distinguishes itself from get_parcel_quote, so an agent can tell them apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says this is reference data for questions like US shipping costs, notes that reading spends no quote allowance, and directs callers to get_parcel_quote for a specific shipment. This is clear when-to-use and when-not-to-use guidance with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Track a shipment whose shipping label was bought on smklog.com, by carrier tracking number. Returns the current delivery status, the latest scan events and the estimated delivery date when the carrier reports one. Works for SMKlog labels only — it is not a universal tracker for arbitrary USPS, UPS, FedEx or DHL numbers, so a number from any other seller comes back not-found rather than as a status. Unrelated to the two pricing tools: it neither quotes nor spends quote allowance. Parameter rules: tracking_number is the only key; no order id or email is needed or accepted. When the label was bought through a create_checkout_link session, get_checkout_status hands back this number at label_ready. It is matched after removing spaces and hyphens and ignoring case, so a pasted or spoken number works as-is. Expect USPS as 20 to 22 digits (13 characters ending in US for international), UPS as 1Z plus 16 characters, FedEx as 12 to 22 digits; anything shorter than 6 characters after cleanup is refused as tracking_number_required, and a number SMKlog never sold answers 404 tracking_not_found with status "not_found". Scan events come newest first, up to eight.
| Name | Required | Description | Default |
|---|---|---|---|
| tracking_number | Yes | Carrier tracking number from the SMKlog receipt or label page |
| Name | Required | Description |
|---|---|---|
| events | Yes | Scan events, newest first, up to eight |
| tracking | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds substantial behavioral detail: it returns delivery status, latest scan events, and estimated date; it normalizes tracking numbers by removing spaces/hyphens and ignoring case; and it documents exact error responses such as tracking_number_required and tracking_not_found with status 'not_found'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every clause earns its place: scope, return value, exclusions, parameter rules, normalization behavior, carrier format expectations, and error conditions. It is front-loaded with the core action and return, then modularly covers constraints and edge cases without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description is complete: it covers input requirements, normalization, validation thresholds, error responses, result shape, and sibling relationships. There is no missing information an agent would need to decide when to call it or to interpret a successful or failed call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description greatly exceeds that by explaining that tracking_number is the only key, how it is cleaned, acceptable carrier formats, and the minimum length rule. This gives an agent actionable semantics far beyond the schema's simple 'Carrier tracking number from the SMKlog receipt or label page'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear and specific verb ('Track') and resource ('a shipment whose shipping label was bought on smklog.com, by carrier tracking number'), then sharpens the scope by explicitly saying it is not a universal tracker for arbitrary USPS/UPS/FedEx/DHL numbers. This distinguishes it from generic trackers and from unrelated pricing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it ('SMKlog labels only'), when not to use it ('not a universal tracker'), and names a related flow ('When the label was bought through a create_checkout_link session, get_checkout_status hands back this number at label_ready'). It also states that pricing tools are unrelated and that no order id or email is needed or accepted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_parcel_quote3 fields changedOutput schema / properties / rates / items / properties / amount / descriptionPrevious value: -"Checkout total, USD"New value: +"Checkout total, USD, SMKlog fee inside"Output schema / properties / rates / items / properties / carrier_amountRemoved value: -{
- "description": "Negotiated carrier cost, USD",
- "type": "number"
-}Output schema / properties / rates / items / properties / service_feeRemoved value: -{
- "description": "SMKlog fee, USD",
- "type": "number"
-}create_checkout_link1 field changedInput schema / properties / service / descriptionPrevious value: -"Service to anchor the amount to, e.g. \"USPS Ground Advantage\". Cheapest when omitted; the human can still pick any service on the page."New value: +"Service to anchor the amount to, e.g. \"USPS Ground Advantage\". Omitted or unmatched, the amount anchors the quote's first rate, top of the best-value ranking rather than the cheapest; the human can still pick any service on the page."get_parcel_quote1 field changedOutput schema / properties / rates / descriptionPrevious value: -"Purchasable services, cheapest first"New value: +"Up to five purchasable services. Not cheapest first: they are ranked by best value, each rate scored as its checkout total in cents plus 175 per business day of transit (30 days when the carrier quotes none), lowest score first, and a rate that publishes a carrier counter price may lead a near-tie within 50 cents or 2 percent. Sort by amount yourself when you want the cheapest."create_checkout_link1 field changedOutput schema / properties / session_idAdded value: +{
+ "description": "Handle for get_checkout_status, shaped as_ plus a UUID, good for 30 days. Null only when the session record could not be stored.",
+ "type": [
+ "string",
+ "null"
+ ]
+}get_checkout_statusget_parcel_quote1 field changedOutput schema / properties / rates / items / properties / carrier / descriptionPrevious value: -"USPS, UPS or FedEx"New value: +"USPS, UPS, FedEx or DHL"track_parcel1 field changedOutput schema / properties / tracking / properties / carrier / descriptionPrevious value: -"USPS, UPS or FedEx"New value: +"USPS, UPS, FedEx or DHL"create_checkout_link7 fields changedInput schema / properties / from_zip / descriptionPrevious value: -"Origin 5-digit US ZIP. Required unless quote_id is given. The origin is always in the United States."New value: +"Origin US ZIP code, 5 digits. Required unless quote_id is given."Input schema / properties / quantity / descriptionPrevious value: -"How many identical parcels ship together, priced as separate labels. Defaults to 1."New value: +"Identical parcels in this shipment. Default 1."Input schema / properties / quote_id / descriptionPrevious value: -"The quote_id returned by a previous get_parcel_quote call, valid for 15 minutes. Pass it and the shipment is taken from that quote, which spends no second carrier call; product, from_zip, to_zip and to_country are then ignored. Omit it and this tool prices the shipment live from the fields below. If the id has expired the tool prices live instead and says so with quote_reused false."New value: +"The quote_id returned by a previous get_parcel_quote call. Valid for 15 minutes."Input schema / properties / service / descriptionPrevious value: -"Optional service to anchor the amount, e.g. \"USPS Ground Advantage\". Cheapest when omitted; the human can still pick any service on the page."New value: +"Service to anchor the amount to, e.g. \"USPS Ground Advantage\". Cheapest when omitted; the human can still pick any service on the page."Input schema / properties / to_country / descriptionPrevious value: -"Two-letter destination country. Omit for domestic. Sold online: US, CA, GB, DE, AU. On the four international lanes the human completes the customs declaration on the handoff page before paying, and duty is billed to the recipient on arrival (DDU) rather than added here."New value: +"Two-letter destination country: US (default), CA, GB, DE, AU."Input schema / properties / to_country / enumAdded value: +[
+ "US",
+ "CA",
+ "GB",
+ "DE",
+ "AU"
+]Input schema / properties / to_zip / descriptionPrevious value: -"Destination postal code. A 5-digit ZIP when to_country is US or omitted; otherwise that country's own postal code."New value: +"Destination postal code: a 5-digit ZIP for the US, or the destination country's own postal code. Required unless quote_id is given."get_parcel_quote14 fields changedInput schema / properties / from_zip / descriptionPrevious value: -"Origin 5-digit US ZIP. The origin is always in the United States; there is no lane that starts abroad."New value: +"Origin US ZIP code, 5 digits. The origin is always in the United States."Input schema / properties / height_in / descriptionPrevious value: -"Packed box height in inches."New value: +"Packed box height, inches."Input schema / properties / height_in / exclusiveMinimumAdded value: +0Input schema / properties / length_in / descriptionPrevious value: -"Packed box length in inches. Supply all three dimensions AND weight_lb to skip the estimate."New value: +"Packed box length, inches."Input schema / properties / length_in / exclusiveMinimumAdded value: +0Input schema / properties / product / descriptionPrevious value: -"Plain-words item description, e.g. \"65 inch flat screen TV in original box\""New value: +"Plain-words item description, e.g. \"65 inch flat screen TV in original box\"."Input schema / properties / quantity / descriptionPrevious value: -"How many identical parcels ship together, priced as separate labels. Defaults to 1."New value: +"Identical parcels in this shipment. Default 1."Input schema / properties / to_country / descriptionPrevious value: -"Two-letter destination country. Omit for a domestic shipment. Sold online: US, CA, GB, DE, AU. Any other country is refused with international_unsupported_online rather than priced, so do not retry it with a different box."New value: +"Two-letter destination country: US (default), CA, GB, DE, AU."Input schema / properties / to_country / enumAdded value: +[
+ "US",
+ "CA",
+ "GB",
+ "DE",
+ "AU"
+]Input schema / properties / to_zip / descriptionPrevious value: -"Destination postal code. A 5-digit ZIP when to_country is US or omitted; otherwise that country's own postal code, e.g. M5V 2T6 for Toronto or SW1A 1AA for London."New value: +"Destination 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."Input schema / properties / weight_lb / descriptionPrevious value: -"Packed weight in pounds. Optional; estimated from the description when omitted."New value: +"Packed weight, pounds. Decimals allowed."Input schema / properties / weight_lb / exclusiveMinimumAdded value: +0Input schema / properties / width_in / descriptionPrevious value: -"Packed box width in inches."New value: +"Packed box width, inches."Input schema / properties / width_in / exclusiveMinimumAdded value: +0create_checkout_link5 fields changedInput schema / properties / from_zip / descriptionPrevious value: -"Origin 5-digit US ZIP. The origin is always in the United States."New value: +"Origin 5-digit US ZIP. Required unless quote_id is given. The origin is always in the United States."Input schema / properties / product / descriptionPrevious value: -"Plain-words item description"New value: +"Plain-words item description. Required unless quote_id is given."Input schema / properties / quote_idAdded value: +{
+ "description": "The quote_id returned by a previous get_parcel_quote call, valid for 15 minutes. Pass it and the shipment is taken from that quote, which spends no second carrier call; product, from_zip, to_zip and to_country are then ignored. Omit it and this tool prices the shipment live from the fields below. If the id has expired the tool prices live instead and says so with quote_reused false.",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "product",
- "from_zip",
- "to_zip"
-]New value: +[]Output schema / properties / quote_reusedAdded value: +{
+ "description": "True when the amount came from a quote_id you supplied, so no carrier call was spent. False when this tool priced the shipment live -- either because no quote_id was given, or because the one given had expired.",
+ "type": "boolean"
+}get_parcel_quote1 field changedOutput schema / properties / quote_idAdded value: +{
+ "description": "Handle 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.",
+ "type": "string"
+}create_checkout_link5 fields changedInput schema / properties / from_zip / descriptionPrevious value: -"Origin 5-digit US ZIP"New value: +"Origin 5-digit US ZIP. The origin is always in the United States."Input schema / properties / quantity / descriptionPrevious value: -"How many identical parcels ship together. Defaults to 1."New value: +"How many identical parcels ship together, priced as separate labels. Defaults to 1."Input schema / properties / to_countryAdded value: +{
+ "default": "US",
+ "description": "Two-letter destination country. Omit for domestic. Sold online: US, CA, GB, DE, AU. On the four international lanes the human completes the customs declaration on the handoff page before paying, and duty is billed to the recipient on arrival (DDU) rather than added here.",
+ "type": "string"
+}Input schema / properties / to_zip / descriptionPrevious value: -"Destination 5-digit US ZIP"New value: +"Destination postal code. A 5-digit ZIP when to_country is US or omitted; otherwise that country's own postal code."Output schema / descriptionPrevious value: -"A payment session, not a charge: the amount and the handoff URL where the human pays."New value: +"A payment session, not a charge: the amount and the handoff URL where the human pays. The amount is a live quote at this moment, not a hold or a reservation, and no money moves until the human completes the page."get_parcel_quote4 fields changedInput schema / properties / from_zip / descriptionPrevious value: -"Origin 5-digit US ZIP"New value: +"Origin 5-digit US ZIP. The origin is always in the United States; there is no lane that starts abroad."Input schema / properties / quantity / descriptionPrevious value: -"How many identical parcels ship together. Defaults to 1."New value: +"How many identical parcels ship together, priced as separate labels. Defaults to 1."Input schema / properties / to_countryAdded value: +{
+ "default": "US",
+ "description": "Two-letter destination country. Omit for a domestic shipment. Sold online: US, CA, GB, DE, AU. Any other country is refused with international_unsupported_online rather than priced, so do not retry it with a different box.",
+ "type": "string"
+}Input schema / properties / to_zip / descriptionPrevious value: -"Destination 5-digit US ZIP"New value: +"Destination postal code. A 5-digit ZIP when to_country is US or omitted; otherwise that country's own postal code, e.g. M5V 2T6 for Toronto or SW1A 1AA for London."create_checkout_linkget_parcel_quoteget_price_indextrack_parcelLive USPS, UPS & FedEx shipping rates plus USPS postage and stamp prices. Free, no API key.
Multi-carrier shipping functionality with built-in, discounted carrier accounts. Compare rates, generate PDF shipping labels, schedule pickups and track packages in automated way or in your chatbox, no coding required. This is a demo server that is functional with no account needed and no auth. For production use please find our production version.
Multi-carrier shipping for AI agents: compare rates, buy labels, track packages, validate addresses
Connect Easyship to compare rates, create shipments, buy labels, and track packages globally.
Add one secure layer between your agents and this server.
