Norce Backend MCP Servers — Limitations

This page lists known limitations in the current release of the Norce Backend MCP Servers. It is intended to help partners, customers, and integration teams plan their work and set accurate expectations.

For things the MCP servers are intentionally not designed for — such as high-volume automation or replacing direct API integrations — see the When to use section of the setup guide.

API and operational limits

These limits apply regardless of which MCP server or tool you use. They are constraints of the underlying Norce APIs and the conversational runtime, not of the MCP servers specifically.

API quota — shared across all integrations

The Backend MCP Servers call the same Norce APIs as your other integrations — the Management API, Connect API, Query API, and Commerce Services APIs. MCP traffic counts against the same quota as your ERP sync, your storefront, and any other integrations running against your environment.

This has a practical implication: a heavy MCP session — for example a large pre-go-live validation or a bulk data quality sweep — can consume a meaningful share of your API capacity. If other integrations are running at the same time, both may be affected.

For routine interactive use this is rarely a problem. For large-scale operations, schedule them during off-peak hours or run them on a stage environment where the quota impact is isolated.

Query API rate limit and paging

The Query API — used by most read tools across all five servers — is a direct, uncached window into the Norce database. It has two constraints to be aware of:

Rate limit — the Query API enforces a request rate limit. If the limit is reached, requests return HTTP 429 (Too Many Requests). The AI will surface this as an error. If you hit rate limits during a session, slow down by breaking the work into smaller steps with pauses between them.
Page size — query results are paginated at 500 records per page. Tools that retrieve large result sets make multiple calls automatically, but very large catalogues will take longer to process than small ones.
Expand depth — the Query API supports a maximum expand depth of three levels. MCP tools are built within this constraint, but it means some deeply nested data relationships cannot be retrieved in a single call.

Import batch size

Bulk import tools across the Pricing, Inventory, and Supplier MCPs accept a maximum of 5,000 records per call. For datasets larger than this, split the data into batches of 5,000 or fewer and import them sequentially.

Import processing time

All bulk imports run asynchronously. After submitting an import, the AI polls for completion and reports the result when the job finishes. Typical processing times:

Small batches (under a few hundred records): 5–30 seconds
Large batches (thousands of records): several minutes

If an AI session times out before an import job completes, the import continues running in Norce — only the AI's polling stops. Check the job status via the Norce Admin UI or ask the AI to poll for the job ID when you restart the session.

Price propagation delay

After a price import completes, there is a short propagation delay before the storefront preview reflects the new values. Querying a price immediately after an import may return the old value. Wait a moment before running a verification check.

Data constraints

These are constraints on the Norce data model that the MCP tools enforce and cannot work around.

Supplier code and currency are immutable — once a supplier is created, its code and currency cannot be changed. Choose these values deliberately before creating the supplier record.
Warehouse name is used as code — in the Supplier MCP, the warehouse name field doubles as the warehouse code used in Connect API imports and Query API lookups. Renaming a warehouse after products have been imported against it will break existing stock and price update flows. Treat the name as a permanent identifier, not a display label.
Variant groups require a shared code — all SKUs in the same variant cluster must share the same code field value. This is enforced at import time; records with mismatched codes will be rejected.

Continuous development

The Backend MCP Servers are actively developed based on partner and customer feedback. New tools and capabilities are added as patches to the current version on an ongoing basis — without breaking existing integrations or requiring changes to your configuration.

If you have encountered a missing capability, reach out through your Norce contact. Feedback from real use cases is the primary input to what gets prioritised.

Future versions

A future major version of the Backend MCP Servers is in planning. It will introduce capabilities that require deeper changes — both to the underlying Norce APIs and to the authentication model. Expect breaking changes in that release, particularly around how credentials and access are configured. Partners and customers will be notified ahead of time with a migration path before any breaking version is released.