AfterShip Post-Purchase MCP Server

The AfterShip Post-Purchase MCP Server exposes your AfterShip organization's shipment tracking and returns data to AI assistants through the Model Context Protocol. You can search and filter shipments, look up a package's full checkpoint timeline and estimated delivery date, triage return requests (RMAs), and inspect a single return's items, refund status, and processing progress — without leaving the AI assistant you already use.

Server URL:

preparing...

Transport: the server supports Streamable HTTP only. SSE and stdio transports are not supported — when configuring an MCP client, make sure the transport type is set to Streamable HTTP.


The server provides tools for AfterShip Post-purchase scenarios.

ToolDescription
list_shipmentsList trackings, with options to filter by tracking number, order number, carrier, status, issue, destination, date range, etc.
get_shipmentGet details of a shipment, including shipment status, checkpoints, delivery estimate, and related carrier and customer information.
list_tracking_filter_optionsLook up the valid filter values (carriers, service types, shipping methods, countries, etc.) available in your organization's data.
ToolDescription
list_returnsList returns, with options to filter by return status, date range, shipping status, refund status, etc.
get_returnGet details of a return, including return items, exchange items, status, return value, return reason, and related return information.

Merchants can quickly identify shipments with delivery issues, including exceptions, delays, or expired cases. This helps support and logistics teams prioritize follow-up before customers escalate.

Example prompts:

How it works: the AI calls list_shipments with a status filter (Exception, Expired, etc.) and a created-date range, then groups or summarizes the results in its answer. Status values are built into the tool, so no lookup call is needed.

Merchants can look up a shipment by tracking number, order number, customer email, or related order information, then review the latest status, carrier events, checkpoints, and tracking timeline.

Example prompts:

How it works: the AI calls list_shipments with a locator filter (order_number, tracking_numbers, customer_emails, etc. — no date range needed) to resolve the internal shipment id. If several shipments match, it shows the candidates and asks you to choose. It then calls get_shipment for the full detail — current status and sub-status, the latest carrier events, and the complete checkpoint timeline.

Merchants can search return requests by status, time range, order number, customer email, or refund status, then summarize the results for operational review and follow-up.

Example prompts:

How it works: the AI calls list_returns with named filters — e.g. rma_status in [submitted] (Pending approval) plus a return_created_at time window — and summarizes the resulting RMAs by status, outcome, value, or customer in its answer. Filters combine freely: approved-but-unresolved returns are simply an rma_status filter for approved, optionally paired with a refund_status filter. A customer email or order number can be passed as the free-text keyword q. Note that no default time window is applied — ask for a time range to scope by date.

Merchants can inspect a specific RMA or return request to understand its current status, related order, returned items, refund progress, and latest updates.

Example prompts:

How it works: given an RMA number, the AI calls get_return directly and reports the return items (with reasons and prices), exchange items and the exchange order, the current return and refund status, receiving records, refund amounts, and key timestamps. Given only an order number or a customer email, it calls list_returns first to find the RMA — it never guesses RMA numbers — then drills into the detail.