Sage X3 MCP: use your ERP from an AI assistant

Hunter BI has completed a Sage X3 MCP project enabling the client to perform work from an AI assistant. The shared experience indicates improved productivity. No before-and-after figures, time savings or financial outcome are published, so it would be inaccurate to infer a percentage for your team.

A new project must translate that general benefit into a verifiable result. It might involve answering a business question more directly or preparing an operation for approval. The users and process owner make that choice. Examples on this page are possibilities to evaluate, not a catalogue of commands confirmed in the referenced customer implementation.

The Sage X3 v12 integration guide describes SOAP web services for classic objects and subprograms, and REST services for classes and representations. Check which services are enabled and usable on your installation. API documentation does not automatically grant access to every ERP record.

Specify the version, hosting, authentication method and integration account permissions. Distinguish supported functions from experimental extensions or custom work. Sage X3 should not be presented as software without APIs: the project chooses an authorised interface appropriate to the task, then exposes a bounded tool to the assistant.

Vendor reference: Sage X3 v12 integration guide

A question such as ‘What stock is available?’ needs a precise meaning. Agree the item, site, date and business definition of availability. Physical stock, reserved stock and usable stock are not interchangeable quantities. This is a scoping example, subject to the information your interface exposes.

The result should retain references that let the user verify it. If context is missing, the assistant asks for clarification rather than choosing a location or unit silently. Your acceptance tests should include multiple sites, unknown item codes and records with similar names. A plausible sentence is not evidence that the correct stock position was retrieved.

Each tool needs documented parameters, expected outputs and explicit error behaviour. Start with a recurring task whose correct answer is already known to the team. An enquiry or summary can help validate record associations, returned fields and the level of explanation useful to the user before adding write operations.

Test unknown references, incomplete responses and information too old for the requested decision. An empty result must differ from a connection error. When the interface cannot perform an operation, the server reports that limitation so the assistant cannot announce a success that never occurred. Do not expose a general-purpose execution endpoint as a substitute for defining business tools.

Define which companies, folders and data areas each user can access. Separate read operations from those that modify the ERP. A write needs an identifiable target, precise content and an approval rule agreed with the business owner. Having a tool available does not authorise every user to invoke it.

Acceptance must examine the effect on the existing process and verify what was recorded. If execution is uncertain, inspect its state before retrying. Document information sent to the assistant provider and retained in logs. Only the fields needed for the workflow should be returned, and access revocation must be tested rather than merely described.

Measure total time to an accepted outcome: preparing the request, receiving the answer, checking it in the ERP and making corrections. Compare equivalent situations and record errors of reference, context or interpretation. A fast but unusable response is not an operational gain.

Before wider access, require the tool catalogue, permissions matrix, test results and operating conditions. Name the person who can suspend the connection and the owner who reviews incidents. Changes to Sage X3 or the assistant should be accompanied by checks on the selected workflows. The maintenance scope is agreed explicitly, including responsibilities for dependencies and updates.