Over the last couple of months, we’ve talked a lot about Agentic Commerce and how AI will move from “answering questions about products” to actually helping customers search, compare and complete real purchases. Our OpenAI Shopping Research post looked at this from the outside-in – what happens when ChatGPT becomes part of the buying journey. Now it’s time to talk about what we’re doing on the inside: the Norce Agent Gateway and our first MCP server for Norce Commerce. This is where things get delightfully nerdy.
What is Norce Agent Gateway and why are we using MCP?
If you strip away the buzzwords, an AI agent is just a system that can:
- understand a customer’s intent,
- break it down into concrete steps (“search products”, “compare options”, “add to basket”),
- and call APIs on behalf of the user.
The problem is not that Norce Commerce lacks APIs – you already have powerful ProductService and ShoppingService endpoints. The problem is that every agent platform comes with its own way of describing tools, managing sessions and streaming results.
That’s where the Model Context Protocol (MCP) comes in. MCP is an open standard for connecting tools, data and agents. Instead of building one-off integrations for each AI platform, you expose a single MCP server, and agent platforms that speak MCP can discover your tools automatically.
The Norce Agent Gateway is simply:
A secure MCP entry point to Norce Commerce, designed for AI agents rather than regular backend solutions. You keep your storefront, business logic and identity model exactly as today. Your agent gets a clean, well-documented tool surface on top.
Launching Norce Agent Gateway
Today we are launching the first step in Norce Agent Gateway by releasing a MCP Server where each multi-tenant customer environment gets an MCP endpoint:
https://[customer-slug].api-se.norce.tech/mcp/commerce
It’s multi-tenant, just like our other APIs, and it sits in front of the same Norce Commerce services you already know.
Under the hood, the MCP server is:
- built on our standard ProductService and ShoppingServiceAPIs,
- secured with the same OAuth2 flow you already use,
- and governed by your existing Applications, environments and permissions.
We’re not inventing a new commerce engine for AI. We’re giving AI agents a safe, predictable way into the one you already know.
Designed for experimentation – and for production
We’ve deliberately kept the first version of the MCP server small and predictable:
- A tiny set of tools that map directly to well-understood APIs.
- No hidden magic: all markets, price lists and customers are explicit in context.
- Standard OAuth2 and Application semantics, so your existing governance still applies.
That makes it a safe starting point if you want to:
- prototype your own conversational shopping experiences,
- plug Norce Commerce into generic AI platforms that support MCP,
- or simply explore what Agentic Commerce could look like for your merchants.
At the same time, the MCP server is built with multi-tenant, production workloads in mind:
- It runs on the same platform as our other services.
- It uses token validation and telemetry consistent with the rest of Norce Commerce.
- It’s ready to scale alongside your existing traffic.
Where we’re heading next
We see the Norce Agent Gateway as a foundation, not a one-off feature. Over time, we expect to:
- expose more tools on top of other Norce services,
- make it easier to configure default context per session,
- and deepen the integration with agent platforms that our partners are already experimenting with.
But even in its first version, the MCP server gives you something very concrete:
A standard, secure way to plug AI agents into product search and cart management – without rewriting your ecommerce stack.
How to call the MCP server
Authentication and headers
To call the MCP server, your agent (or the system hosting it) must:
- Obtain an access token using a regular OAuth2 account, exactly as described in our documentation for accessing APIs with OAuth2 accounts.
- Send that token on every MCP request:
Authorization: Bearer <access_token>
application-id: <your-application-id>
A few important details:
- application-id is mandatory.
It tells us which Application configuration applies – and therefore which assortments, price lists and rules to use. It should match what your storefront already uses. - The MCP server validates tokens locally and forwards them to the underlying APIs.
If a token is missing or invalid, you’ll get 401 Unauthorized just like with our other endpoints.
If you already integrate with Norce Commerce using OAuth2, you can reuse the same accounts and tokens for the Agent Gateway.
Tools: a small, opinionated surface for agents
For the first version we focus on a narrow but powerful set of tools:
Product tools
- product.search –
Searches and lists products using ListProducts2 under the hood. The agent gets a list of ProductItem-style results with names, short descriptions, prices and images – enough to reason about and filter before making a final choice. - product.get –
Fetches detailed information about a single product using GetProduct (by productId), with the option to fall back to GetProductByUniqueName or GetProductByPartNo. This is what your agent should call when the user is close to deciding.
Cart tools
- cart.addItem –
A compound operation that will: - Create a new basket if no basketIdis supplied (using CreateBasket), and
- Add an item to that basket (using InsertBasketItems).
- cart.removeItem –
Removes a specific line from a basket. - cart.setItemQuantity –
Updates the quantity of an existing basket line. - cart.get (optional but typically enabled) –
Returns the current basket summary.
Together, these tools let an agent do what a good salesperson would do: suggest products, go a little deeper when needed, and then help the customer build a basket.
Filters vs context – the two knobs your agent needs
Two parameters often confuse people at first: filters and context. They solve different problems:
Filters – “what kind of products do we want?”
filters narrow down which products are returned from product.search. Think of them as your facets:
- categoryIds– only products from specific categories.
- manufacturerIds– limit to certain brands.
- flagIds– campaign flags, curated assortments, etc.
- minPrice/ maxPrice – price range.
Example:
"filters": {
"categoryIds": [1001],
"manufacturerIds": [25],
"minPrice": 2000,
"maxPrice": 8000
}
In a conversation this is where the agent translates “Show me solid oak tables between 2,000 and 8,000 SEK” into concrete filters.
Context – “in which market and for which customer?”
context describes where the request is coming from and who it is for. This is what makes the results match your storefront:
- cultureCode– language / locale.
- currencyCode/ currencyId – which currency to use.
- priceListIds– which price lists to use for pricing.
- salesAreaId– which market / sales area applies.
- customerId, companyId– for customer-specific conditions.
Example:
"context": {
"cultureCode": "sv-SE",
"currencyCode": "SEK",
"priceListIds": [1],
"salesAreaId": 10,
"customerId": 12345,
"companyId": 123
}
If your frontend already knows “the user is in Sweden, on price list A, with customer-specific pricing”, your agent should reuse that same information and pass it in context.
The MCP server doesn’t guess. It simply takes the filters and context you provide and forwards them to the underlying Norce APIs.
A concrete scenario: from vague intent to a filled basket
Let’s take a simple example:
“I need a 6–8-person dining table in oak, and some matching chairs.”
A well-behaved agent using the Norce Agent Gateway might:
- Call searchwith:
a. query = "dining table oak",
b. categoryIdspointing to your dining table category,
c. contextmatching the user’s current market, price lists and currency. - Get a list of 10–20 tables, with enough metadata to reason about dimensions, material and price.
- Use LLM magic to narrow that list down to 3–5 options and present them to the user.
- When the user picks one, call getfor that productId to fetch full details.
- Ask a follow-up question about chairs, then:
a. Call searchagain, this time filtered to your chair categories and maybe the same manufacturer. - When the user is ready:
a. Call cart.addItem(without basketId) for the table, including the shopper’s clientIp and the same context.
b. Remember the returned basketId.
c. Call cart.addItemagain with that basketId to add the chairs.
d. Optionally call cart.get to confirm the final basket state.
Everything runs against the same Norce Commerce environment you already use. The only difference is that an AI agent is orchestrating the calls instead of relying on fixed rules in a storefront.
Want to dive deeper?
If you’re a partner or developer and want to start building, we’ve documented:
- the MCP endpoint and authentication requirements,
- the exact tool contracts for search, product.get and the cart tools
- and how filters and context map to the underlying Norce Commerce APIs.
👉 Read the developer documentation here
We’re excited to see what you build on top of the Norce Agent Gateway – and how your agents will help customers find the right products, in the channels where they already are.
