How to Add a Shopping MCP Server to Your AI Agent

Your agent understands the user’s request. Turning it into a specific product recommendation is harder.

Prices change. Product details are scattered across merchant pages, catalogs and platforms. A user adds a budget, a device requirement or a delivery location, and the shortlist needs to change again. Keeping that information usable across separate sources is a substantial integration job.

Without a dependable offer source, an agent can explain what to look for yet stop short of a confident next step. It might suggest a product category or a familiar model without a concrete offer that fits this user’s circumstances. Even a useful recommendation can leave the commercial journey disconnected: the user moves on, while the product has no attributed outcome from the assistance it provided.

AON’s shopping MCP server connects your agent to highly structured offers across connected merchants. It brings offer discovery, request-based matching and tracked next actions into the agent’s existing tool workflow. Your product can help the user move from a general question to a suitable commercial option—and earn when that help leads to a qualifying outcome.

Here is what the connection adds, then how to configure it.

1. Give Your Agent the Offer Layer Behind a Useful Recommendation

A shopping MCP server lets an AI agent discover and use shopping tools during a conversation. It can connect a buying request to structured offers that the agent can compare. It does not place the order or handle payment; those actions remain with the merchant or checkout system. That offer layer addresses the gap web search leaves in a buying decision.

AON MCP adds three connected capabilities:

• Concrete options to work with. Retrieve merchant offers during the conversation, with supplied product information, prices and commercial terms. Your agent has a basis for a specific recommendation beyond what the model remembers.
• Matching that follows the user’s requirements. Send the buying request and relevant constraints to AON. As the user adds details, multi-turn discovery carries the conversation forward and helps refine the options. Highly structured offers make those commercial choices easier for AI to understand and compare.
• A next step connected to an outcome. Each returned action gives the user a route to the offer. AON attribution connects the referral to qualifying merchant or partner-reported results, creating a revenue path for your application. The merchant handles the purchase and fulfillment.

Your team controls when to search, how to explain the trade-offs and how offers appear. AON provides the offer network, matching and attribution behind that experience. You can focus on helping the user decide rather than building each merchant connection into a separate recommendation workflow. The same foundation can support product finders, comparison features and buying steps within an existing workflow.

Model Context Protocol exposes these capabilities as tools your agent can discover and call. If your application already uses an MCP client, the hosted AON connection fits that workflow. AON also offers REST and SDK routes for products that prefer direct integration.

2. Connect AON and Attribute Traffic to Your Application

AON’s hosted endpoint is:

https://api.aon.pro/v1/mcp

For Claude Code, the documented connection command is:

claude mcp add --transport http aon https://api.aon.pro/v1/mcp \
  --header "X-AON-Placement-Id: <YOUR_PLACEMENT_ID>"

Replace the placeholder with the Placement ID from your application. The client manages its MCP connection; this command configures the server rather than performing an offer search itself.

Search can also run anonymously without the placement header, but anonymous traffic earns nothing and cannot be reassigned to your application later. Use your own placement for traffic that should earn revenue for your application. The non-billable Public Test Sandbox is a separate way to inspect the raw Query contract.

Offer search needs no API key. Your placement identifies the application that earns from its traffic.

3. Search with the Requirement That Changes the Choice

Have the client list the tools exposed by the connected server. Look for aon_search_offers and inspect its input schema. AON’s tools reference describes the search arguments, while the connected server’s tools/list result defines the tools and schemas available on that server.

Start with one intent sentence carrying the product, budget and use case. The search text should be a single line of no more than 200 characters:

{
  "intent": {
    "content": [
      {
        "type": "input_text",
        "text": "noise-cancelling headphones under 300 USD for calls on trains"
      }
    ],
    "provenance": "user_expressed"
  }
}

Pass that object as the arguments to aon_search_offers through your MCP client. It is an arguments example, not a complete HTTP exchange.

The wording carries a product type, a budget and a use case. That makes the result easier to evaluate than a keyword list such as “headphones, train, calls, cheap.” You can add supported fields as the product needs them, using the discovered schema rather than guessing names.

An end-to-end example

Suppose a user says:

“I need noise-cancelling headphones under 300 USD for calls on trains.”

The agent sends the request above to aon_search_offers. An illustrative excerpt from the JSON inside the tool result could look like this:

{
  "data": {
    "offers": [
      {
        "offer_info": {
          "title": "Option A",
          "description": "Noise-cancelling headphones with up to 30 hours of stated battery life.",
          "commercial": {
            "price": {
              "amount": "249",
              "currency": "USD"
            }
          }
        },
        "entity": {
          "name": "Example Merchant"
        },
        "match_reason": "Fits the stated budget and includes noise cancellation.",
        "action": {
          "type": "open_url",
          "payload": {
            "url": "https://example.com/attributed-offer-url"
          }
        }
      },
      {
        "offer_info": {
          "title": "Option B",
          "description": "Noise-cancelling headphones with up to 45 hours of stated battery life.",
          "commercial": {
            "price": {
              "amount": "289",
              "currency": "USD"
            }
          }
        },
        "entity": {
          "name": "Another Example Merchant"
        },
        "match_reason": "Fits the budget and has the longer stated battery life of these two options.",
        "action": {
          "type": "open_url",
          "payload": {
            "url": "https://example.com/another-attributed-offer-url"
          }
        }
      }
    ]
  }
}

This excerpt uses the documented offer_info, entity and action structure. Identifiers and other response fields are omitted for readability. Product details, prices and URLs are placeholders; they do not represent live offers or a completed tool call.

The next step is to turn those fields into a useful comparison.

4. Turn the Search Result into a Reason to Choose

The tool result’s content[0].text contains a JSON document. Read data.offers[] from that document: the offer information, merchant, applicable terms and next action give the agent the material for its answer.

Use the returned match_reason, when present, to explain why an option fits. For calls on trains, connect the relevant features to that use case. Leave microphone performance unresolved if the supplied information does not establish it; noise cancellation alone does not answer the call-quality question.

The MCP usage guide describes presenting supplied offer information, preserving action.payload.url and using available follow-up guidance. Keep that action URL verbatim. Rebuilding it from a merchant name can lose the intended destination and attribution path.

A useful answer explains the trade-off before the link. For long journeys, comfort and battery life may change the choice. Compare the supported differences in the user’s terms.

For the illustrative response above, the agent could say: “Option A stays further below your 300 USD budget. Option B costs more but has the longer stated battery life. Neither result establishes microphone performance, so if clear call audio is essential, that is still worth checking. I’ve kept each merchant’s offer link so you can review the current terms.” The comparison gives the user a reason to choose without turning match_reason into independent performance evidence.

That gives the agent a role beyond pasting search results into the chat.

5. Call the Tool When the User Needs an Option

Connecting a tool does not mean invoking it on every turn. Put the trigger into your agent’s behavior instructions. For example:

Use offer discovery when the user wants a product or service option.
Keep the user's stated requirements intact.
Ask a clarifying question when one missing detail would change the choice.
Explain recommendations using supplied evidence.
Make commercial relationships visible and preserve returned action URLs.
If no suitable offer is available, continue helping without inventing one.

These are application instructions, not AON API fields. Test the behavior with a clear buying request, a vague request that needs clarification and a question that only needs an explanation. The distinction matters more than the number of tool calls you can produce.

6. Carry the User’s New Requirements into the Next Search

Users refine a request after seeing options. They may lower the budget, add a requirement or decide they need a different type of product. This is the multi-turn part of the integration: carry the new requirement into the next search instead of repeating the first result.

Use a fresh, unguessable context.session_id for each conversation and keep it stable across its rounds. Pass the prior response’s data.request_id as context.session.previous_request_id to connect the next search.

When the user selects a supplied refinement, merge its query_helper.request_patch into the request and copy its origin to intent.origin. For registered traffic, assign an unguessable request_id before the first call. Reuse it only to retry that unchanged request; a changed query needs a new ID. Without a caller-supplied ID, each call is treated as new. Anonymous requests are always recomputed rather than replayed.

The product question is whether the second search reflects the user’s changed requirement. Repeating the same offer after a user rejects it is a poor conversation even when every tool call succeeds.

7. Measure the Experience Your Agent Creates

Before broadening the rollout, review the agent’s behavior and commercial results in the first use case:

Use the Reporting API to review attributed clicks, conversions and estimated_earnings for the placement:

• Clicks: recorded clicks on the returned offer path.
• Conversions: qualifying conversions attributed to the offer.
• Estimated earnings: the reported earnings estimate for those attributed outcomes, not a guarantee of payment.

Reporting v2 returns earnings in USD. Values for a past reporting window can still change as late conversions arrive or settlements are reversed, so treat estimated_earnings as a reporting estimate rather than final paid revenue. Keep clicks, approved commission and payouts distinct, and review them alongside serving cost and user feedback.

Your own application logs or exposure events should measure tool-call rate, non-empty response rate and display CTR. A non-empty response does not prove that the offers were a good match, and these experience metrics are not AON Reporting API metrics. AON can connect a returned action to qualifying merchant or partner-reported outcomes; a click alone is not revenue, and MCP does not automatically place or pay for an order.

The mechanism is straightforward: the user expresses a need, AON matches structured offers, your application explains and displays the options, and the user follows the returned action path. When a qualifying outcome is reported, that attributed result can create a revenue path for the application. The merchant still handles checkout, payment and fulfillment.

Start Building with AON

Start with the AON MCP connection guide, then use a Placement ID for traffic that should be attributed to your application. A practical first use case is any existing shopping flow where users already state a product, a constraint and a reason for buying. Add the tool at that decision point, preserve the returned action URL and measure both the quality of the conversation and the commercial outcome.

FAQ

Should a custom AI shopping assistant use AON MCP or REST?

Choose MCP when your agent host manages tool calls, or REST when your application should control the requests directly. Both connect the assistant to AON’s structured merchant-offer discovery. With MCP, the host discovers and invokes the tool; with REST, your application manages orchestration, retries and response handling. Your product still decides when buying help is useful and how to explain and present returned offers.

Does AON’s shopping MCP server place orders for users?

No, AON’s shopping discovery tools return merchant offers and tracked next actions rather than placing orders. The agent can compare supported offer information and let the user choose where to continue. Preserve the returned action link so the referral remains connected to qualifying outcomes. The merchant or its checkout system handles payment, fulfillment and post-purchase service.

What should an AI agent do when AON MCP returns no offers?

For a successful query with no offers, continue helping the user and clarify only requirements that would meaningfully change the search. First distinguish that empty result from a connection or tool error, which needs separate handling. Keep the user’s stated constraints intact and ask before relaxing one. AON discovery can be useful within an existing assistant without every buying question producing a commercial recommendation.

Can developers test AON shopping search without a Placement ID?

Yes, the hosted AON search supports anonymous calls before you create a placement. Use them to inspect requests, returned offers and how the agent explains the results. Anonymous activity earns no attribution or payouts. Add your own Placement ID when you want subsequent referrals associated with your application; earlier anonymous activity does not become attributed retroactively.

How should developers test an AI agent’s shopping behavior after connecting AON MCP?

Use a buying question with a requirement the answer must preserve, plus a similar question that needs no offer. Review whether the agent calls the tool selectively, avoids unsupported claims and handles a missing match naturally. A successful search is only one part of a successful conversation.

Can AON MCP work alongside an AI agent’s existing search tools?

Yes, AON can work alongside the research tools your agent already uses. Search can support broader research, while AON supplies concrete commercial options and tracked next actions. Your application decides which tool the current question needs and carries the relevant requirements into the request.