Why this matters

At first glance this looks like the most obvious entry: a photo goes in, a button comes out. The point is the pattern. An AI agent understands what you want, then hands you to the right native app at the exact screen, in one tap, with no browser and no checkout done by the bot. Snap Reorder does this for Amazon reorders, but the same server shape works for any app with deep links.

The server side works today. The last piece belongs to the chat apps. The interactive card standard for MCP (MCP Apps) is new, and in our testing, chat apps do not yet let a card's button open a native app. When they do, this pattern needs no changes, and it is simple enough for thousands of developers to copy. The simplest ideas are often the ones that get used the most.

Since I built it, I've been shopping on Amazon a lot more. I usually remember what I need while I'm at my computer, and I don't want to stop and dig through the app. Now I tell my agent in a few seconds and get one button that lands on the exact product, with all the steps in between gone.

Inspiration

I reorder the same things all the time: magnesium, zinc, coffee pods. Every time, I search Amazon again, scroll past sponsored results, and try to find the exact size and brand I bought last time. The bottle is already in my hand. I wanted to show it to my assistant and land on that product in the Amazon app, ready to buy.

What it does

Snap Reorder is an MCP server. You send a photo of something you already own to an AI chat. The server reads the label, or recognizes the item itself when there is no label, finds that product in your past Amazon purchases, and returns a card with the product, the last price you paid, the date you last ordered it, and one button. The button opens the Amazon app on that exact product. You review it and buy it yourself.

It never checks out, never scrapes amazon.com, and never sends you to a browser. The button is an Amazon app link (com.amazon.mobile.shopping.web://amazon.com/dp/{ASIN}). Web links are rejected in code.

Three tools:

  • match_item(image, hint?): photo in, up to 3 candidates out, each with last price, last order date, and app link.
  • list_frequent_reorders(limit?): the things you buy most.
  • ingest_orders(csv): load an Amazon order history export.

Built and tested on my full Amazon order history. For privacy, the repo and live demo carry 55 of my products, mostly recent orders.

How we built it

  • TypeScript MCP server on the official MCP SDK, protocol 2025-11-25 over Streamable HTTP, stateless JSON responses.
  • Hosted on AWS Lambda with a Function URL in us-east-1. Bearer token on /mcp.
  • Tiered matching on Amazon Bedrock. Amazon Nova 2 Lite reads the label first and returns it as JSON. Catalog-weighted word matching ranks that reading against past purchases, so rare words like a brand count most. If the match is not confident, Amazon Nova Pro re-reads the label.
  • For an item with no readable label, Amazon Nova 2 multimodal embeddings compare the photo with each past purchase's Amazon product image, and Nova Pro confirms the same product among the 3 closest. As a last resort, Nova Pro checks the photo against recent purchase titles. Only catalog products can be returned.
  • Catalog: my Amazon order emails, plus my order history page (read by my agent) once the emails stopped listing items. Each product has last price, last order date, and order count. Amazon's order history CSV export also works.
  • An MCP Apps card (ui://snap-reorder/reorder-card.html) shows the result and the button. Hosts without UI get plain text with the same link.
  • Tests cover the catalog, link rules, every matching tier, and the MCP tools.

Challenges we ran into

  • Opening the Amazon app, not a web page. The older com.amazon.mobile.shopping://www.amazon.com/products/{ASIN} link opened an Amazon "page not found" in a browser view on my iPhone. The https link often stays inside in-app web views. Only com.amazon.mobile.shopping.web://amazon.com/dp/{ASIN} reliably opened the product in the app, so it is the only link the server produces.
  • Chat apps. Many chat apps will not open a custom app link from a tool result. That is why the result is an MCP Apps card: the host owns the button and opens the link. I have not yet verified the one-tap card inside a production chat host.
  • Alexa+ is partner-only, so I could not connect it directly. The server speaks standard MCP so any MCP host can use it, including Alexa+ when access opens.
  • Order data. Amazon has no public order history API for this. I used order emails and the official data export instead of scraping.

Accomplishments that we're proud of

  • Real phone photos matched the right products on the live Lambda: Nutricost Astaxanthin, Life Extension Calm-Mag, Source Naturals DLPA, CocoaVia, whose brand is printed sideways, and Intake Breathing magnetic tabs photographed with no box or label.
  • The Amazon app link opens the product page in the Amazon app on my iPhone.
  • It follows Amazon's rules: no scraping, no automated checkout. The person always buys.

What we learned

  • Tiers keep it fast. Nova 2 Lite reads most labels in about 2 seconds, and the heavier image comparison runs only when a photo needs it.
  • App links are the hard part of agent shopping, not the model.

What's next

  • Other shopping actions with the same pattern, like "find it cheaper," each ending in one button that opens the Amazon app.
  • Test the one-tap card in MCP Apps hosts on iPhone and Android, and in Alexa+ when access allows.
  • Store each user's catalog in S3 or DynamoDB instead of a bundled file.
  • A guided import of Amazon's order history export.

Built With

Share this project:

Updates

Submission history