Norce Backend MCP Servers for Developers and Solution Architects
This guide is for developers and solution architects working on Norce Commerce implementations — onboarding new clients, building integrations, validating environments, and debugging data problems. It assumes the Backend MCP Servers are already connected to your AI assistant — if not, start with Using the Norce Backend MCP Servers.
For a broader overview of what the Backend MCP Servers can do across all roles, see End-to-end use cases.
What changes for developers
The typical developer interaction with Norce involves writing one-off scripts to look up identifiers, calling multiple API endpoints to piece together a picture of the environment, and going back and forth between Admin UI screens during configuration work. None of this is fast, and much of it happens under time pressure during onboarding.
With the Backend MCP Servers connected, you can interrogate any part of a Norce environment in conversation — across Config, Product, Pricing, Inventory, and Supplier simultaneously. The AI coordinates the calls, correlates the results, and surfaces what matters. This is especially valuable early in a project when you are still mapping the environment, and during the iterative design work where the Admin UI slows you down most.
With the Backend MCP Servers connected to an AI assistant, you can:
- Design and iterate on the product data model collaboratively — creating categories, parametrics, flags, and test products in conversation and previewing the result on the storefront without leaving the session
- Explore any client environment in minutes — find all identifiers, codes, and configuration details needed to start building an integration
- Compare stage and production to catch configuration drift before a deployment
- Validate a full environment across all domains before go-live
- Debug broken integrations by querying data state, import job history, and raw vs storefront views to isolate where the problem is
- Set up supplier infrastructure from scratch and validate the full configuration chain before the first import
Workflows
Designing the product data model
The most important — and most time-consuming — conversation in any Norce onboarding project is defining the product data model. What should the category structure look like? Which parametrics are needed for each category? How should variant groups be structured? What flags are required?
This conversation typically involves a solution architect who knows Norce's data model and a PIM manager who knows the products but has not yet worked with Norce. It is highly iterative: propose a structure, test it on a real product, see how it looks, and refine. Done through the Admin UI, each iteration means navigating across multiple screens. Done through the MCP servers, the full loop — design, create, test, preview, refine — happens in a single conversation.
Exploring and designing the category structure
Start by understanding what is already there, then build from it.
Sample prompts
"Show me the current category structure — top-level categories and their direct children."
"We're onboarding a client that sells electrical components. We need a category structure for connectors, cables, and switching equipment. Suggest a starting structure based on what already exists and what we're adding."
"Create a new category called 'Connectors' as a child of category ID 12. Set it as active."
Defining parametrics for a category
Once the category structure is in place, define which parametrics each category needs — types, list values, and whether they should be filterable or searchable.
Sample prompts
"What parametrics are currently assigned to the Connectors category? Show me the full list with types and values."
"We need a 'Connector Type' parametric with list values: RJ45, USB-C, HDMI, DisplayPort, and VGA. Create it in the Electrical parametric group and assign it to the Connectors category."
"Add a 'Max Voltage' parametric of type decimal to the Connectors category. It should be filterable and searchable."
"We want to make 'Connector Type' and 'Max Voltage' visible in the filter panel. Confirm that both are set as filterable."
Building a test product and previewing the result
With the category and parametrics in place, create a test product, fill in values, and preview how it renders on the storefront. This is the validation step — the moment where the data model design becomes tangible.
Sample prompts
"Create a test product in the Connectors category. Use part number TEST-CONN-001. Set it as active, assign the Connector Type parametric with value RJ45, and set Max Voltage to 100."
"Show me how TEST-CONN-001 looks on the storefront (application ID 1001). Does everything render correctly?"
"The parametric values are not showing up on the storefront. What's missing — is it a category assignment issue, a flag, or something in the storefront configuration?"
"Run a readiness check on TEST-CONN-001 and tell me what would prevent it from being published."
Iterating
The design rarely lands perfectly on the first attempt. A parametric type turns out to be wrong, a list value is missing, a category assignment needs adjusting. The AI lets you make corrections and retest immediately.
Sample prompts
"The Max Voltage parametric should be an integer, not a decimal. Change the type and update the test product value to 100."
"We need two more list values for Connector Type: Thunderbolt and eSATA. Add them."
"Move the test product to the sub-category 'Network Connectors' (ID 88) instead of the top-level Connectors category."
"Now that the structure looks right, check translation completeness for all new parametrics and categories in en-GB and de-DE."
Analysing the impact of a change
As the data model evolves, changes to existing metadata can have wider effects than expected. Changing a parametric from text type to list type, for example, affects every product that has a value stored for it. Before making that kind of change, ask the AI to assess the impact — which products use the parametric, what values they currently have, and what needs to happen to those values during the migration to the new type.
"We want to change the 'Material' parametric (ID 34) from a text type to a list type. How many products currently have a value for it? What are the most common values? And what do we need to do with the existing text values when we make the change?"
"If we split the 'Dimensions' parametric into three separate parametrics — Width, Height, and Depth — which products currently have a Dimensions value that would need to be migrated?"
When the structure is agreed, clean up the test product and document the final parametric assignments — the AI can summarise the agreed structure in a format the team can reference during the full import.
Exploring a new client environment
On the first day of a project, before writing any integration code, you need to know what is in the environment — application IDs, price list codes, warehouse codes, sales area IDs, VAT codes, supplier codes. Collecting these through raw API calls or the Admin UI takes time. The Config MCP and other servers can give you a complete picture in a single session.
Sample prompts
"Give me a full overview of this client environment — applications, stores, sales areas, VAT codes, and active price lists."
"What are the application IDs for this client, and which storefronts do they correspond to?"
"List all warehouse codes and their locations. I need these for the stock import integration."
"What price list codes are active? I need to know which ones the ERP should map to."
"List all suppliers and their warehouse codes and price list codes. I'm building the supplier feed integration."
Keep the identifiers you collect in your LLM instructions so they are available in every subsequent session without having to look them up again.
Migrating from an existing platform
Customers switching to Norce from an existing e-commerce platform face a common challenge: they have an existing product structure — categories, attributes, product relationships — that does not map directly to Norce's data model. Starting the metadata design from a blank slate ignores what the customer already has and what already works for them.
A faster starting point is to give the AI access to the existing product catalogue — for example, by sharing links to product pages, an exported product feed, or a sample data file — and ask it to analyse the existing structure and propose an equivalent Norce metadata model. This gives the project team something concrete to react to and refine, rather than designing in the abstract.
The AI can also act as the bridge between the old and new model throughout the migration: tracking which fields map directly, which need to be transformed, which old fields can be consolidated into a single Norce parametric, and which Norce fields have no equivalent in the old system and will need to be populated during enrichment.
Sample prompts
"Here are links to 10 product pages from our existing webshop: [links]. Analyse the product data — categories, attributes, and values — and propose an equivalent category and parametric structure in Norce."
"Here is an export of our current product catalogue: [file]. Based on this structure, what categories, parametric groups, and parametrics should we create in Norce? Identify any fields that need to be merged or consolidated."
"We've agreed on the Norce metadata structure. Now compare it with the old system's fields and tell me: which fields map directly, which need transformation, and which Norce fields have no source in the old data and will need to be added manually during enrichment?"
"During the migration, which products will be missing data for required Norce fields? Show me the gaps so we know what enrichment work is needed before the products can go live."
"The old system had a single 'Size' attribute that covered both clothing and shoes with different values mixed together. In Norce we want separate 'Clothing Size' and 'Shoe Size' parametrics. Help me map the existing values to the correct new parametric for each product category."
Stage vs production comparison
Before any significant deployment — a go-live, a code release, a configuration change — verify that stage and production are aligned. Differences in price list configuration, VAT code assignments, or application settings between environments are a common source of post-deployment issues.
Sample prompts
"Compare the full configuration of our stage and production environments. Flag any differences in applications, sales areas, VAT codes, and price list assignments."
"The pricing behaviour on production is different from stage. Compare the price list configurations on both environments and tell me what differs."
"Check that all the categories and parametrics we set up on stage have been replicated correctly to production."
Pre-go-live validation
Before an environment goes live, run a comprehensive health check across all domains. The MCP servers let you do this in one session — Config for environment setup, Product for data quality, Pricing for price list integrity, and Supplier for supplier configuration chains.
Sample prompts
"We're going live next Thursday. Run a full validation of the environment across all domains and give me a structured report of anything that needs to be fixed."
"Run a pricing health check in full mode and a product data quality sweep. Tell me what's failing and what's at risk."
"Check the supplier setup for all active suppliers and confirm that each one has at least one active warehouse, a standard location, and a primary price list connected to a warehouse."
"Validate the Config setup — confirm that all applications have a primary price list assigned, all sales areas have a VAT code, and there are no expiring price lists in the next 30 days."
Debugging a broken integration
When an integration stops working — an ERP sync is producing wrong data, a stock update is not showing up, a price feed is landing incorrectly — the MCP servers let you quickly isolate where the problem is.
The first step is always to check what is actually stored (the raw view), then check what the storefront is showing (the processed view), and compare them. If the raw data looks wrong, the problem is in the import or the source system. If the raw data looks correct but the storefront view does not, the problem is in business logic, configuration, or caching.
Sample prompts
"Product AB-1042 is showing the wrong stock level on the Norwegian storefront. Show me the raw on-hand data and the customer view side by side, and tell me where the discrepancy comes from."
"Our ERP price feed ran last night but several products are showing old prices. Check the raw stored prices for these SKUs and confirm when they were last updated: [list]."
"The supplier import from this morning completed but some products are showing as out of stock. Check the import job status and the raw on-hand data for these SKUs: [list]."
"Pull the last 5 import job results for the supplier MCP and tell me if any of them had errors or partial failures."
"Product AB-2201 has the wrong category on the storefront. Check what category it has in the raw data vs what the storefront shows."
When the source of the problem is identified, ask the AI to apply the fix directly for lower-risk corrections, or to tell you exactly what API call or data change is needed.
Setting up supplier infrastructure
When onboarding a new supplier, the full infrastructure chain — supplier record, warehouse, locations, price list, warehouse connection — must be in place before any imports can run. Missing any step silently breaks availability calculations or import jobs.
The AI can set up the full chain in sequence, validating each step, and run norce_supplier_check_supplier_setup at the end to confirm everything is correctly wired before the first import.
Sample prompts
"Set up a new supplier called 'Acme Electronics' with code ACME, country Sweden, and currency SEK. Walk me through each step and confirm before proceeding."
"The supplier ACME is created. Now add a warehouse called 'Standard' — it should be the standard warehouse with a 3-day lead time."
"Add a default location to the ACME Standard warehouse. Mark it as the standard location."
"Create a primary price list for ACME called 'ACME Cost' with code ACME-COST in SEK. Connect it to the Standard warehouse."
"Run a full supplier validation check for ACME and confirm everything is in place before we start the first import."
Scheduling operational changes
Some operations need to happen at a specific time — a campaign flag added at midnight, a price update applied before a market opens, a stock reset run at the start of a new season. AI assistants that support scheduling can prepare and execute these operations automatically, with validation built in.
Sample prompts
"Schedule the following flag update for Monday at 06:00: add the Summer Sale flag (ID 55) to these 20 products. Today, preview how they will be priced once the flag is applied and confirm they are ready."
"At the end of the month, deactivate all products with the Clearance flag (ID 40) that still have zero stock. Run a dry-run now and show me which products would be affected."
"Every Sunday night at 23:00, run a full pricing health check and a supplier setup validation for all active suppliers. If any issues are found, summarise them so they're ready for review on Monday morning."
"On the first of every month, remind me to update the exchange rate on our Norwegian price list. When the reminder fires, fetch the current NOK/SEK rate and tell me what value I should enter in the Admin UI."
Note: updating exchange rates directly through the MCP server is not supported in the current version — the update must be made in the Admin UI. The AI can remind you when it is due and provide the recommended value, but the final step is manual. Exchange rate write support is planned for a future version.
Tips
Use the Norce Assistant MCP alongside the Backend MCP Servers. The Norce Assistant MCP knows the full API reference and data model. When you need to understand the structure of a specific API response, construct a complex OData filter, or look up which fields are available on a resource, ask the Assistant MCP — then use the Backend MCPs to apply what you learned. The two complement each other well in a developer session.
Store identifiers in your LLM instructions. Application IDs, price list codes, warehouse codes, and sales area IDs are stable across sessions. Add them to your system prompt once so the AI can use them immediately without having to look them up every time.
Name test products clearly. When building and iterating on the data model, use a distinct prefix (for example TEST-) for test product part numbers. This makes them easy to find, filter, and clean up after the design is finalised.
Always validate the supplier setup chain before importing. norce_supplier_check_supplier_setup catches missing warehouse connections, missing standard locations, and missing primary price lists — all of which silently break imports. Make it the last step of any supplier infrastructure setup.
Combine health checks with go-live checklists. The MCP servers can produce a structured readiness report across all domains in one prompt. Build this into your deployment checklist so it runs as a formal step before every go-live, not as an afterthought when something goes wrong.