Overview
What is MCP
AfterShip Post-purchase MCP
Reference
Tool reference
Installation
Claude
Claude Code
ChatGPT
Cursor
VS Code (GitHub Copilot)

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 — and, with your confirmation, act on what you find: edit a shipment, retrack a stalled package, or move a return through approval, receiving, and resolution — 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.

Features

The server provides 21 tools for AfterShip Post-purchase scenarios — 9 that read your data and 12 that change it. Read tools run on their own; write tools always ask for your confirmation first.

  • Tracking — search and filter shipments, open a shipment's full checkpoint timeline, edit shipment details, retrack a stalled shipment, or mark one as delivered, lost or returned to sender.
  • Returns — search returns, open one RMA's full detail, move a return through approval, receiving and resolution, comment on it, and manage the allowlist and blocklist rules.

For the full list, with what each tool does and whether it reads or writes, see the tool reference.

How the agent handles writes

The tools marked Write above change real merchant and customer records. The server flags every one of them as a write and instructs the agent to work to these rules:

  • Confirm first. Before any write, the agent shows you exactly what will change — which record, which field, from what to what — and waits for your explicit approval. It will not go straight from finding a record to changing it without asking you first.
  • Never invent a value. If something is ambiguous, the agent asks. Customer name, email, and phone changes have to be confirmed verbatim; a rejection reason and an inspection grade have to come from you.
  • Batch operations show their blast radius. For anything touching more than one record, the agent lists the candidates and the scope of the change before acting.
  • No promises the tool did not make. The agent reports the state the tool actually returned — it will not tell you a refund has landed or an exchange has been arranged.

Some writes cannot be undone through this server: there is no tool to undo an approved return, reopen a resolved or rejected return, or reverse a manually marked shipment status.

Access and permissions. The agent works inside the AfterShip organization you pick during sign-in, and it can only do what your own AfterShip role allows — connecting an agent does not grant it more access than you have. Tools also require an active plan for the product they touch; if your organization has no Tracking or Returns plan, the relevant tools return a subscription link rather than data.

Usage Examples

Use Case 1: Monitor shipments that need attention

Merchants can quickly identify shipments with delivery issues — those in exception, and those that have expired. 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.

Use Case 2: Investigate tracking details for an order or customer

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.

Use Case 3: Search and summarize returns / RMAs

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, order number or RMA number can be passed as the free-text search q, which matches from the start of the value rather than anywhere inside it. Note that no default time window is applied — ask for a time range to scope by date.

Use Case 4: Review the full context of a specific return request

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.

Use Case 5: Fix up a shipment record without opening the admin

Support and operations teams can correct a shipment's details in the same conversation where they spotted the problem — a typo in the customer's email, a wrong destination address, a tag that needs adding for a follow-up queue.

Example prompts:

How it works: the AI resolves the shipment with list_shipments, reads the current record with get_shipment, then shows you a summary of the change and waits for your confirmation before calling update_shipment (or mark_shipment_status for a final state). Tags, customers and custom fields are stored as whole sets rather than edited item by item, so the agent reads the existing entries first and sends the complete intended list — it will name anything that would be dropped before going ahead.

Use Case 6: Process a return end to end

Merchants can take a return request from triage to closure without switching tools — approve it, record the parcel arriving, and resolve it once the refund is issued.

Example prompts:

How it works: the AI calls get_return first to confirm the RMA's current state, because the lifecycle cannot skip steps. It then summarizes the action and waits for your approval before calling approve_return, receive_return_items, or resolve_return. Quantities, quality grades, and any rejection reason come from you — the agent never fills them in on its own, and it cannot infer a grade from a description like “damaged”. Receiving is not repeatable: calling it twice would double-count stock, so the agent will not retry on its own if it is unsure a call went through.

Next step