Agents can search the web, book a flight and write code. Very few can tell a user whether the thing they need is on a shelf three miles away.
That gap is small to describe and hard to fill. An MCP server for shopping closes it with one tool call. JENNi runs one at https://shop.jennipro.com/mcp, and any agent that speaks Model Context Protocol can connect to it.
What agents already have
Most agents already have good tools for finding information. Web search returns pages. Maps return places. Review sites return opinions.
Ask an agent for a specific item and it does what it can with those. It finds a product page, a list of nearby stores, maybe a review. Then it stops and hands the user a link.
That's findable. It isn't buyable.
The gap: local availability and a way to buy
A user who asks "can I get this today?" needs three answers. Is the item in stock near me? What will it cost, delivered? How do I pay for it without leaving the conversation?
Web pages don't answer those questions in a form an agent can trust. Stock is buried in scripts, prices change, and nothing on the page says what a courier can actually do for a given address.
The data exists. It sits on physical retail shelves. What's missing is a shared, structured layer that turns shelf inventory into something an agent can query and then buy from.
What JENNi's MCP server for shopping does
JENNi's SKU Graph joins canonical products, anchored on barcodes, with the stores that carry them: price, stock, source and when we last saw each offer. The MCP server puts that graph behind a few plain tools.
search_catalogtakes a query and a 5-digit US ZIP. It lists local delivery first, then fills with ship-to-home. Results come in pages of 20, and only in-stock items appear.get_productreturns product facts.get_buying_optionstakes aproduct_id, azip, aquantityand afulfillment_mode. It returns availability, price, delivery fee, delivery promise and the total before tax.start_checkoutreturns a hostedcheckout_urlwhere the buyer reviews delivery, tax and total and pays on a secure page.create_checkout,update_checkoutandcomplete_checkoutrun checkout inside the chat, for agents whose users want to approve the total there.get_order_statusreports where an order stands once it's placed.
Shoppers never see store names. Every offer reads "Delivered by JENNi," and JENNi is the seller. We buy the item from the store for the customer, so if something goes wrong, the issue comes to us.
Why a tool, and not a scrape
An agent can try to read store websites directly. It's slow, it breaks when a page changes, and it tells the agent nothing about what a courier can do. A tool call returns the same fields every time, so the agent can reason over them instead of parsing markup. It also means the people who maintain the data can fix it once for every agent that asks.
How to add it and what users get
Add the endpoint to your agent's MCP configuration: https://shop.jennipro.com/mcp. Your agent then sees the tools above, with their descriptions, and can call them like any others.
A typical flow is short. The agent searches with the user's query and ZIP. It narrows to one product. It asks for buying options and shows the user the price, the delivery promise and the total. Then it either sends them to the hosted checkout page or completes checkout in chat after they approve the total.
Users get something they couldn't get from a link. They get a real answer about what's nearby, a quote with a total, and a way to finish the purchase. A same-day option appears only when the delivery promise says "Get it today." When it can't be same day, the agent can ask for a ship_to_home quote instead.
Prices are checked again at checkout. If the price or availability has changed, checkout refuses the stale numbers, and nothing is charged until the shopper approves the final total.
Try it
If you build agents, point one at https://shop.jennipro.com/mcp and ask it for something you could pick up today. The missing tool call is already there.