This server provides US-origin parcel shipping capabilities: live multi-carrier quotes, label checkout sessions, shipment tracking, and a pricing index.
Get live quotes (get_parcel_quote): USPS, UPS, FedEx, and DHL Express rates for parcels from the US to the US, Canada, UK, Germany, or Australia, using a plain-language item description or exact dimensions; returns purchasable services with checkout totals, carrier costs, and delivery estimates.
Create label payment sessions (create_checkout_link): turns a quoted shipment into a payment session with a handoff URL and session_id; can reuse a quote_id to avoid an extra carrier call and never charges automatically.
Check checkout status (get_checkout_status): tracks a session through awaiting_checkout, checkout_started, paid, label_ready (with tracking number), delivered, or refunded; no personal data exposed.
Track SMKlog shipments (track_parcel): returns delivery status, scan events, and estimated delivery for labels bought on smklog.com using the carrier tracking number.
Read the price index (get_price_index): monthly US parcel shipping price data for common box weights from Newark to five US cities, free to query.
Freight and oversize handling: pallets, oversized, or multi-piece shipments are routed to human pricing via task handles instead of fake quotes.
No API key or signup required; tools are rate-limited and designed for one quote per shipment.
Provides live DHL Express parcel shipping rate quotes from the US to Germany and Australia, including purchasable services, checkout totals, carrier costs, and delivery windows.
Provides live FedEx parcel shipping rate quotes for US domestic and selected international lanes, including purchasable services, checkout totals, carrier costs, and delivery windows.
Provides live UPS parcel shipping rate quotes for US domestic and selected international lanes, including purchasable services, checkout totals, carrier costs, and delivery windows.
Provides live USPS parcel shipping rate quotes for US domestic and selected international lanes, including purchasable services, checkout totals, carrier costs, and delivery windows.
Most shipping APIs want a box: length, width, height, weight. People don't have that — they have a thing on the table and a ZIP code to send it to. This server takes the thing.
Describe "a full-size acoustic guitar in its hard case" and it estimates the packed carton, prices it live across three carriers, and hands back services you can actually buy — with the checkout total and the carrier's own cost side by side, so you can always show a person both numbers.
"How much to ship a 12 lb box from 07922 to 90011?"
"What would it cost to send a full-size acoustic guitar in a hard case from New Jersey to Los Angeles?"
"Compare USPS, UPS and FedEx for a 5 lb box, Newark to Chicago — which is cheapest and which is fastest?"
"Price a 24 × 18 × 12 in box at 22 lb going to 33101, then give me a link to buy the label."
"Where is my package? Tracking 9400111899561234567890."
"Did they pay for that label yet? Here is the session id you gave me."
"What has a 5 lb box to Denver cost over the last few months?"
"I have a pallet of ceramic tile going from Hoboken to Miami — can you get me a quote?"
That last one is not a parcel, and the server says so rather than guessing: it returns a task handle, a person prices the freight, and the answer comes back when you poll it.
Related MCP server: Easyship MCP
Tool | What it does |
| Live rates for one parcel from a US origin, domestic or to Canada, the UK, Germany or Australia, across USPS, UPS and FedEx, plus DHL Express to Germany and Australia. Plain-words description → estimated packed box; or pass 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 delivery window. |
| Prices the shipment and returns a payment session: the amount, a handoff URL that opens the SMKlog checkout prefilled with this shipment, and a |
| Where a payment session stands: |
| Delivery status, scan events and the carrier's estimated delivery date for a shipment whose label was bought on smklog.com. Not a universal tracker for arbitrary numbers. |
| The monthly SMKlog parcel price index: six common boxes (1–20 lb) from Newark, NJ to five US cities, repriced through the same live pipeline that prices real shipments. Reading it spends no quote allowance. |
A quote is a real carrier call and costs real money to produce. Call
get_parcel_quote once per shipment, not once per variation you are curious
about. The server is rate limited per client and will say so plainly rather than
silently degrading.
Origin is the United States. Domestic lanes and US-origin exports. A lane that starts somewhere else is out of scope, and the server will tell you instead of inventing a number.
Prices are checkout totals with the SMKlog fee inside, and the carrier cost comes back as its own field. Show whichever one the conversation needs — but the total is what the person pays.
Oversized, palletized and multi-piece freight is priced by a person. Declare
the io.modelcontextprotocol/tasks extension and get_parcel_quote returns a
task handle for those; poll it with tasks/get.
Nothing here buys a label on its own. create_checkout_link produces a URL;
a human completes the purchase, certifies the contents and consents to carrier
adjustments. An agent cannot spend someone's money through this server.
{
"mcpServers": {
"smklog": {
"type": "http",
"url": "https://quote-api.smklog.com/mcp"
}
}
}No key, no OAuth, no signup. Quoting, tracking and the price index are all open.
For a client that only launches local commands — Claude Desktop, Cursor, an MCP inspector, a Docker-based runner — this repository is a thin stdio bridge to the same endpoint. No dependencies, no build step, no keys:
{
"mcpServers": {
"smklog": {
"command": "npx",
"args": ["-y", "github:smklog/parcel-shipping-rates-mcp"]
}
}
}Or with Docker:
docker build -t smklog-parcel-shipping-rates-mcp https://github.com/smklog/parcel-shipping-rates-mcp.git
docker run -i --rm smklog-parcel-shipping-rates-mcpThe bridge forwards every JSON-RPC message to https://quote-api.smklog.com/mcp
and writes the answer back, one JSON object per line. If the endpoint cannot be
reached it still answers initialize and tools/list from the snapshot shipped
here (initialize.json, tools.json), so you can see what is offered; tool
calls need the network. npm test drives it end to end.
Also installable from Smithery
and listed in the official MCP registry
as com.smklog/parcel-shipping-rates.
Other ways in, if MCP is not your transport: OpenAPI · A2A agent card · API docs · llms.txt
SMKlog sells US shipping labels. The same pricing pipeline that answers this server answers the website — there is no separate "API rate". Questions, bugs and odd results: info@smklog.com.
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 cheapest rate, 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". Cheapest when omitted; 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?
The description goes well beyond annotations by disclosing side effects: it writes a 30-day session record, is not idempotent, spends carrier calls when no quote_id is used, never charges the card, and calls out stale-link repricing. It also explains failure conditions like missing_required_fields. This is exactly the behavioral context an agent needs.
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 section earns its place: main behavior, side effects, no-session cases, and parameter rules are clearly separated. It is front-loaded with the core purpose and workflow placement, and the later formatting uses scannable paragraphs and labeled parameter rules.
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 7-parameter tool with subtle override rules and special-case failures, the description is remarkably complete: it explains the quote_id interaction, fallback behavior, service matching, international customs/duty, and what the human completes on the resulting page. The output schema exists, so the description does not need to restate return structure, and it covers what the schema cannot.
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 schema coverage is 100%, the description adds substantial semantic value: quote_id overrides most fields but not service, expired quote_ids fall back to live pricing, service matching is a case-insensitive fragment that silently falls back to cheapest, and from_zip/to_zip constraints are clarified. These rules are absent from the schema and materially change how parameters should be supplied.
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 verb and resource: 'Turns a decided shipment into a payment session for buying its shipping label.' It clearly distinguishes itself from quote/session-status siblings by describing the handoff URL and session creation, and it orients the agent to the surrounding workflow with 'Use it after get_parcel_quote.'
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 when to use the tool ('after get_parcel_quote') and when not to ('No session is returned when... freight, oversize...'), and names the sibling get_checkout_status for checking human payment and label existence. These are concrete, actionable routing rules rather than vague context.
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 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.
| 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 | Purchasable services, cheapest first |
| 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 mark this read-only and non-destructive, and the description adds substantial behavioral context: dimension estimation behavior, purchasable-service return shape, manual review path, tasks extension behavior, label purchasing location, rate-limited carrier calls, and an 80-call hourly allowance. No contradictions 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?
Although long, the description is tightly organized with labeled sections and every sentence carries operational value. The core behavior is front-loaded and the parameter rules are grouped logically rather than repeated.
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 9-parameter tool with rich validation, rate limits, carrier integration, and sibling routing, the description covers all necessary invocation details, error cases, and fallback paths. The output schema exists, so return-value documentation is not required from the description.
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 critical semantics: the four parcel-dimension parameters must be sent as a set or all are ignored, product is validated against bare routes/weights/questions, from_zip must be a real 5-digit ZIP, and to_zip semantics depend on to_country. This goes well beyond the schema.
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 verb and resource: getting live parcel shipping rates from a US origin, with explicit carriers and destination countries. It also distinguishes itself from get_price_index and create_checkout_link, so an agent can select it correctly without opening sibling 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?
The description explicitly says when to use this tool versus get_price_index, and instructs the agent to pass the returned quote_id to create_checkout_link. It also covers when a human is required (oversized, palletized, crated shipments), leaving no ambiguity about routing.
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.
Each tool targets a distinct lifecycle stage: live quote, checkout-link creation, checkout status, tracking, and reference pricing. Even the two pricing tools are clearly separated by live shipment quote versus historical price index.
All tool names follow a consistent verb_noun snake_case pattern: get_* for reads, create_* for creation, track_* for tracking. The naming is predictable and easy to navigate.
Five tools is well-scoped for this domain: quote, checkout session, session status, tracking, and price index. There are no redundant tools and each one has a clear role.
The core quote-to-label-to-tracking lifecycle is well covered, including session status polling and a reference price index. Minor gaps exist: cancel/refund actions and manual-review follow-up are not directly exposed as tools, though manual review is acknowledged.
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
Compare parcel and letter delivery prices across 60+ carriers in 27 European countries.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/smklog/parcel-shipping-rates-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
