Working Across Norce Backend MCP Servers

Once you have more than one Backend MCP Server connected to your AI assistant, a few habits make sessions significantly more effective. This guide covers how the servers relate to each other, how to set up a session well, and when to bring in the Norce Assistant MCP alongside the Backend servers.

For connection and setup instructions, see Using the Norce Backend MCP Servers. For a plain-language introduction to the Norce data model, see Understanding the Norce Backend MCP Servers.

How the servers relate to each other

Each Backend MCP Server covers one domain, but they are not independent — they share reference data and depend on each other in predictable ways.

Server	Role
Config MCP	Reference data source — applications, stores, sales areas, VAT codes. Primarily a lookup server. The IDs it provides are used by every other server.
Product MCP	The catalogue layer — products, categories, parametrics, flags, content. Products must exist here before they can be priced or stocked.
Pricing MCP	The commercial layer — price lists, rules, prices per SKU. Depends on product data and Config reference data (sales area IDs, VAT codes).
Inventory MCP	The operational layer — warehouses, stock levels, availability. Works alongside Product and Pricing for a complete picture of a product's state.
Supplier MCP	Parallel supplier structure — supplier warehouses, cost price lists, product mappings. Feeds into the product and pricing layers but has its own infrastructure.

The most important dependency to understand: Config is the source of reference data for everything else. Sales area IDs, VAT code IDs, and application IDs all come from the Config MCP. The other servers use them but do not provide them.

Start with the Config MCP

When beginning a new session or a new task, start by establishing the reference data you need. A single call to the Config MCP — listing applications, stores, and sales areas — gives you the IDs that every subsequent call will depend on.

"Give me an overview of this environment — applications, stores, sales areas, and active price lists."

Once you have the application ID for the storefront you are working with, every other server in the session will use it. You do not need to look it up again.

If you work with the same environment regularly, put the application ID and any other stable identifiers directly into your LLM instructions so the AI has them from the start of every session. See Application IDs in instructions for how to do this.

Application IDs flow across all servers

One of the most useful things to understand about the Backend MCP Servers is that a single application ID works identically across all five servers. An application ID retrieved from the Config MCP is the same one you pass to Product, Pricing, Inventory, and Supplier tools.

This means you establish the application context once — either through an initial Config MCP call or via your LLM instructions — and every server in the session works from the same perspective. If you are looking at the Swedish storefront, all five servers will give you the Swedish view.

When a task involves comparing two storefronts — for example checking whether a product is priced correctly on both the Swedish and Norwegian applications — you pass the two application IDs explicitly in your prompt. The AI will run the calls for each and present the results side by side.

"Compare product AB-1042 on the Swedish application (ID 1001) and the Norwegian application (ID 1042) — price, availability, and content."

Common multi-server patterns

Some tasks naturally span multiple servers. The AI coordinates the calls automatically — but knowing the pattern helps you write more direct prompts and understand what the AI is doing.

Investigating a product issue — Product, Pricing, and Inventory in parallel. All three can be queried simultaneously since they are independent reads.

"Product AB-1042 is displaying incorrectly. Check the product status and content, the storefront price, and the stock availability all at once and tell me what you find."

Pre-go-live validation — Config first, then Product, Pricing, and Supplier in parallel. Config provides the reference data needed to validate the others.

"We go live next week. Start with a Config overview, then run a full health check across Product data quality, Pricing configuration, and all active supplier setups."

Importing a product catalogue — Product first, then Pricing and Supplier in parallel. Prices and supplier mappings can only be imported after the products exist.

"Import this catalogue. Create the products first, then once that job completes, import the retail prices and the supplier cost prices in parallel."

Campaign setup — Pricing for the price list, Product for the flag assignment. These can run in sequence or in parallel depending on whether the population rule uses a flag.

"Set up the Summer Sale campaign price list and assign the Summer Sale flag to these products at the same time."

Bringing in the Norce Assistant MCP

The Norce Assistant MCP is a different kind of server — it does not read or write Norce data. Instead, it knows the Norce API reference, the data model schema, and Norce documentation. Think of it as the expert you consult when you want to understand something, rather than the tool you use to do something.

Connect it alongside the Backend MCP Servers when you are likely to need that understanding in the same session. Good moments to reach for it:

A result looks unexpected — ask the Assistant MCP to explain the field or the logic behind it before concluding something is wrong
You want to build an OData filter — describe what you are looking for in plain language and ask it to construct the expression, referencing the correct schema
You are designing something — ask what fields and options are available before deciding on an approach
You encounter an unfamiliar field — ask what it means and how it is used before deciding whether it matters

"The preview price response has a field called PriceListRuleId that I don't recognise. Ask the Norce Assistant MCP what this field represents and how it affects the calculated price."

"I want to find all products where the Voltage parametric is between 100 and 240 and is marked as filterable. Help me build the right OData expression for the lookup_products tool."

The Backend MCPs and the Assistant MCP complement each other naturally: the Backend servers act, the Assistant server explains. In a session where you are both doing things and trying to understand what you are seeing, having both connected means you never have to leave the conversation to look something up.

Session setup checklist

Before starting a multi-server session:

Confirm which servers are connected — check that the servers you need are active and returning tools. If a server is missing, you will get no tools from it rather than an error.
Establish your application ID — either from your LLM instructions or with an initial Config MCP call. Every other call in the session depends on it.
Set the environment context — if you are working across stage and production, name the servers clearly in your instructions so the AI knows which is which and never writes to production accidentally.
Connect the Norce Assistant MCP if you expect to need it — it is easier to have it available from the start than to add it mid-session.