Live USPS, UPS, FedEx and DHL rates from the US: domestic, Canada, UK, Germany, Australia. No scale.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds substantial context beyond them: the 60/hour rate limit, 30-day session lifetime, session_not_found behavior for expired/malformed IDs, and the privacy constraint that responses never carry names, addresses, or emails. The 'nothing changes' statement aligns perfectly with readOnlyHint=true, so there is no contradiction.
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?
Roughly 200 words, but every paragraph earns its place: purpose and polling cadence, status semantics with transition details, ID rules, the manual-review edge case, and the rate limit. Content is front-loaded with the core statement and grouped under a clear 'Parameter rules' heading rather than dumped as a wall of text.
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?
With an output schema covering the return envelope, the description covers everything else an agent needs for correct invocation: polling cadence, status ordering and transition semantics, the error condition (session_not_found), TTL, rate limit, privacy constraints, and follow-up routing to track_parcel. Nothing operational 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%, yet the description still adds real meaning: the ID's provenance ('the session_id returned by create_checkout_link'), its shape ('as_ plus a UUID'), and explicit exclusions ('no order id, no email, no quote_id'). It also conveys sensitivity posture ('treat the session_id like a tracking number'), which the schema cannot express.
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') and enumerates the exact statuses returned, so an agent knows precisely what this tool does. It also differentiates from siblings by naming track_parcel as the follow-up tool and framing itself as a read-only status check, which no sibling claims.
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?
Explicit when-to-use guidance is present: 'Poll it after handing the human the link, minutes apart rather than seconds,' with the rationale that nothing moves until the human acts. It also routes to the alternative tool explicitly ('Once label_ready, feed tracking_number to track_parcel') and rules out other uses with 'no carrier call, no quote allowance.'
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 declare readOnly, idempotent, and non-destructive hints, and the description adds meaningful behavioral context beyond them: it does not consume quote allowance, omitting month returns the newest issue, and invalid or missing months produce specific error shapes (invalid_month vs issue_not_found with available_months). 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?
Every sentence earns its place: definition, return payload, use case, cost implication, sibling routing, parameter rules, error behavior, and comparability. The description is front-loaded with the core definition and no sentence 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only lookup tool with an output schema, this description is complete. It covers purpose, usage context, alternatives, parameter format and defaults, error cases, cost side-effects, and issue comparability. There is no missing information an agent needs to correctly select and invoke the tool.
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 well beyond the schema's 'Issue as YYYY-MM. Omit for newest published issue.' It documents the valid date range from 2026-07, the one-issue-per-month cadence, omission behavior, and both error responses. The comparability guarantee across issues is also valuable semantic context.
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 ('Returns') and resource ('SMKlog parcel shipping price index'), then names exact outputs: cheapest purchasable service per box and lane, every rate behind it, and basket averages. It also distinguishes itself from sibling get_parcel_quote by clarifying it is reference data, not a specific shipment price.
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?
Provides explicit usage context with example questions ('what does shipping a shoebox cost in the US right now') and states that reading spends no quote allowance. It explicitly routes specific-shipment pricing to get_parcel_quote instead, making the when-to-use/when-not-to-use boundary unambiguous.
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?
Beyond the readOnly/idempotent annotations, the description discloses the actual behavior: return contents (status, scan events, ETA), error responses (tracking_number_required, 404 tracking_not_found with status 'not_found'), normalization rules (strip spaces/hyphens, ignore case), format expectations, and the newest-first eight-event limit. No behavior contradicts 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense, and every sentence contributes non-obvious information needed to call the tool correctly. It is front-loaded with the core purpose and return values, then progressively adds exclusions, parameter rules, validation, and error behavior.
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 tool with output schema present, the description is fully sufficient: it names what is returned, explains edge cases, defines error semantics, and clarifies when the tool should not be used. No important caller-facing behavior is omitted.
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?
Even though the schema already documents tracking_number at 100% coverage, the description adds crucial semantics: it is the only accepted key, no order id or email is accepted, values are normalized, expected carrier formats are given, and sub-6-character inputs are refused. This goes well beyond the schema's one-line description.
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 first sentence names a specific verb ('Track'), a specific resource (SMKlog shipments), and a specific lookup key (carrier tracking number). It also differentiates itself from universal trackers and from the pricing tools, so an agent can tell it apart from its siblings without opening the schema.
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 states when the tool applies ('SMKlog labels only'), when it does not ('not a universal tracker for arbitrary USPS, UPS, FedEx or DHL numbers'), and that it neither quotes nor spends quote allowance. It also points to get_checkout_status as the way to obtain the tracking number after a create_checkout_link session, giving clear routing guidance.
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. Dates show when Glama detected each change.
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_parcelClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Live 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.
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.
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.
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.
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.
