Most product APIs stop at a link. A buying agent needs to know if this item can be bought, in this quantity, for this address, by when and for how much. Then it needs a checkout.
An agent checkout API has to cover that whole path. A product record is only the start. Here's what an agent has to answer before it can honestly say "done," and how JENNi's MCP server helps it answer.
The questions an agent has to answer
Before an agent tells a user an item is handled, it needs answers to a short list.
- Is this the exact product the user means, including size?
- Is it in stock?
- Can it reach this address, and how: local delivery or shipping?
- What's the price, the delivery fee and the total?
- When will it arrive, and how sure are we?
- How does the user pay safely?
A link answers none of these. A product page answers one or two, in a format built for people. The agent ends up guessing, and a guess that turns into a promise is how users lose trust.
Buying options: nearby or shipped, with totals
JENNi's get_buying_options tool is built around those questions. You give it a product_id, a zip, a quantity and a fulfillment_mode, which is either local_delivery or ship_to_home.
It returns availability, price, delivery fee, delivery promise and the total before tax. Tax is added at checkout, and the checkout page shows it before the buyer pays.
Two details matter for agents.
First, same day is a claim, and it's only verified when the delivery promise says "Get it today." If the promise says anything else, the agent shouldn't say same day. Ask for ship_to_home and quote that instead.
Second, search shows in-stock items only, but a product opened directly can still be quoted. So an agent should treat a quote as the source of truth, not a search hit.
Clear refusals in an agent checkout API
Sometimes an item can't be bought. It may be out of stock, out of range for local delivery, or the price may have moved since the last look.
A good agent checkout API says so, and says why, instead of returning something that looks like success. JENNi's checkout re-verifies current price and availability and refuses stale prices. Nothing is charged until the shopper approves the final total.
For you as a builder, this means a refusal is information. Pass it to the user plainly: this size isn't available, local delivery doesn't reach that address, shipping is the option. Then offer the next step.
One practical tip: sized goods are often listed one size per product. If a user wants a particular size, put it in the search query. Don't assume the agent can pick a size later.
The handoff to a secure checkout page
When the user is ready, start_checkout returns a hosted checkout_url. The buyer opens it, reviews delivery, tax and total, and pays on that page. The page re-verifies price and availability at that moment.
start_checkout creates no order and no charge by itself. That keeps the agent's job clean. It finds, quotes and hands off, and the payment details never pass through the conversation.
If you'd rather keep the user in chat, create_checkout, update_checkout and complete_checkout do the same job in steps. Nothing is charged until complete_checkout, and that only runs after the shopper approves the total.
Why this changes how you build
If your agent only gets links, you'll spend your effort on scraping, retries and guesswork. If it gets structured answers, you can spend that effort on the conversation. Ask the user what they need, check the options, say what's true, and let them decide. The agent becomes a shopper's helper instead of a search box with opinions.
Think of it as a contract. The tool promises fields, the agent promises to repeat only what those fields say, and the user gets an answer they can act on. When either side drifts, the shopper pays for it.
Where to start
Connect your agent to https://shop.jennipro.com/mcp and call get_buying_options for a product near you. Compare what comes back with what a product page told you. That difference is the distance between findable and buyable.