How to build an MCP server for SYSPRO
Short answer
A SYSPRO MCP server is a small service that exposes named, read-only tools such as item lookup, order status, stock and BOM, backed by e.NET queries or a read-only SQL Server login. Any MCP client, including Claude and ChatGPT, can then call those tools without touching SYSPRO directly.
Model Context Protocol is an open standard for connecting AI applications to tools and data. Instead of building a separate integration for each assistant, you build one server for SYSPRO and every MCP client can use it. For a manufacturer, that means the same item and order tools can serve a planner in a desktop client, a support chatbot and a scheduled agent.
The design question is not how to implement the protocol, since SDKs handle that. It is which tools to expose, how to authenticate to SYSPRO, and what to refuse. A server that mirrors every table is both a security risk and a poor interface for a model. A server with ten well-named tools that match how planners think is far more useful.
This page is the design checklist: tool list, SYSPRO access paths, transport, permissions and audit, with attention to the cases particular to SYSPRO such as multiple companies and operator security.
What teams use it for
Item and stock lookup
Tools return description, unit of measure, warehouse quantities, allocations and on-order for an item, so a client can answer availability questions.
Sales order status
Given an order number, return header, lines, quantities shipped and invoiced, and expected ship dates.
Purchase order and receipt tracking
List open PO lines by supplier or item, with due dates, quantities received and any recorded changes.
BOM and where-used
Return a bill of materials with components and quantities, and where an item is used, for engineering and costing questions.
Work in progress and job status
Return job header, operations, material allocations and completion status for shop-floor and planning questions.
Customer and supplier master look-ups
Return contact, terms and balance fields allowed for the user's role, excluding anything sensitive.
SYSPRO integration surface
- e.NET Solutions: XML-based business objects for queries and transactions. Query objects such as INVQRY and SORQRY respect SYSPRO business logic, and the available objects and parameters vary by version, so confirm in your e.NET documentation.
- e.NET session handling: a logon returns a session identifier used for subsequent calls and should be logged off cleanly, so the MCP server needs session pooling and timeouts.
- SQL Server company databases: tables such as InvMaster, InvWarehouse, SorMaster, SorDetail, PorMasterHdr, PorMasterDetail, WipMaster and BomStructure support fast set-based reads. Table and column details differ across versions, so build a schema check at startup.
- SYSPRO operator security: operators have program-level permissions, and an MCP server should run under a dedicated operator whose rights match the tools exposed.
- SYSPRO REST-style and newer web service layers: if your version provides them, they can replace COM or WCF e.NET access and simplify deployment.
How it works
- 1
List tools from real questions
Interview planners, buyers and CSRs, collect 30 questions, and group them into a tool list of 8 to 12 read operations.
- 2
Design inputs and outputs
Use typed parameters such as item_code, order_number, warehouse, company_id. Return compact JSON with units and a source field naming the e.NET object or table.
- 3
Implement data access
Wrap e.NET in one client with session pooling, and keep SQL in parameterised, reviewed statements. Prefer e.NET where business logic matters, such as availability calculations.
- 4
Choose transport
Stdio is simple for one user on one machine. Streamable HTTP behind a reverse proxy and OAuth suits a team and central logging.
- 5
Add scoping and limits
Enforce company, warehouse and field allow-lists per user role, cap rows per call, and apply query timeouts.
- 6
Add audit and metrics
Log user, tool, arguments, duration and row count to a store outside the SYSPRO database.
- 7
Test with several clients
Connect Claude, a ChatGPT-compatible client and a local model, and fix tool descriptions where clients misuse them.
Example flows
Availability to promise
Trigger: A client calls get_item_availability for item and warehouse.
- The server authenticates the user and checks warehouse permission.
- It calls an e.NET inventory query for on-hand and allocated quantity.
- It reads open PO lines due within the horizon.
- It returns on-hand, available and inbound with dates.
Result: The client can state what can be promised and when, with sources for each number.
Blocked write attempt
Trigger: A prompt injected via a supplier note tells the client to change a PO.
- The client looks for a write tool and finds none registered.
- The server exposes only query tools, so no call is possible.
- The attempt is visible in the client transcript and logs.
Result: The read-only design contains the damage and the event can be reviewed.
Keeping data on-prem
An MCP server is a good fit for on-prem SYSPRO because it runs wherever your network allows. Deploy it on a server that can reach the e.NET service and SQL Server, expose it over internal HTTPS with your corporate identity provider, and point clients at it. Pair it with a locally hosted open-weight model if prompts must stay on site. For stdio use on managed desktops, ship the server as a signed package, and keep database credentials in a vault rather than in client configuration files.
Security checklist
- Start with read-only tools only; add writes later as separate tools with approval flows and distinct credentials.
- Authenticate users with OAuth or your SSO, and pass user identity through so scoping and audit are per person.
- Use a least-privilege SQL login and a restricted SYSPRO operator, stored in a secrets vault.
- Validate every argument with strict types and parameterised queries; never build SQL from model-provided strings.
- Return only allow-listed fields and redact values such as bank details, and log all calls outside the ERP database.
Ways to get it done
Open-source or community SYSPRO MCP server
Effort: Days to evaluate.
Check whether a maintained one exists for your version; review its code and permissions before trusting it.
Build in-house
Effort: 2 to 6 weeks for a read-only server with logging.
Good if a developer knows e.NET or SQL Server and the tool list is small and stable.
Partner build and run
Effort: A pilot in weeks, then extended as workflows grow.
Good when you want tested tools, evaluation sets and an on-prem model path without dedicating internal developers.
Pitfalls
- !Exposing a generic run_sql tool lets a model write heavy or unsafe queries, so offer purpose-built tools instead.
- !Leaking e.NET sessions exhausts licences, so pool sessions and log off on timeout and shutdown.
- !Returning thousands of rows overwhelms the model and context, so paginate and summarise.
- !Hard-coding company IDs breaks multi-company installs, so make company an explicit parameter with permission checks.
- !Skipping contract tests on e.NET outputs means an upgrade can change XML and break tools silently.
Frequently asked questions
What is an MCP server for SYSPRO?
It is a service implementing Model Context Protocol that exposes SYSPRO data as tools an AI client can call. Each tool wraps an e.NET query or a safe SQL statement, returns structured results and enforces access rules. The model never connects to SYSPRO directly.
Should I use e.NET or SQL in the server?
Use e.NET where SYSPRO business logic matters, such as available quantities and pricing. Use read-only SQL for fast, simple lookups and aggregates. Many servers use both, with e.NET for calculated values and SQL for lists and history.
Which AI clients can use it?
Any MCP-capable client, including Claude Desktop and Claude connectors, and other assistants that support MCP. Support for remote servers and authentication varies by client and plan, so test the transport you plan to use.
How do I keep it safe?
Keep it read-only at first, authenticate each user, apply role-based scoping in code, cap result sizes and log every call. Treat any text coming back from SYSPRO as untrusted input to the model.
Can it work with a local model?
Yes. MCP is model-agnostic. A local open-weight model with tool calling, served through vLLM or Ollama and a compatible client, can use the same server, though complex multi-step reasoning may be weaker than larger hosted models.
Want MCP server working on your SYSPRO?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment