# How to build an MCP server for SYSPRO

> Source: https://netray.co/integrations/syspro-mcp-server
> Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems.
> Section: Integrations

## 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.

## System

SYSPRO

## Capability

mcp-server

## Intro

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.

## Use Cases

### Item and stock lookup

**Description:** 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

**Description:** Given an order number, return header, lines, quantities shipped and invoiced, and expected ship dates.

### Purchase order and receipt tracking

**Description:** List open PO lines by supplier or item, with due dates, quantities received and any recorded changes.

### BOM and where-used

**Description:** 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

**Description:** Return job header, operations, material allocations and completion status for shop-floor and planning questions.

### Customer and supplier master look-ups

**Description:** Return contact, terms and balance fields allowed for the user's role, excluding anything sensitive.

## System 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

### List tools from real questions

**Detail:** Interview planners, buyers and CSRs, collect 30 questions, and group them into a tool list of 8 to 12 read operations.

### Design inputs and outputs

**Detail:** 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.

### Implement data access

**Detail:** 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.

### Choose transport

**Detail:** Stdio is simple for one user on one machine. Streamable HTTP behind a reverse proxy and OAuth suits a team and central logging.

### Add scoping and limits

**Detail:** Enforce company, warehouse and field allow-lists per user role, cap rows per call, and apply query timeouts.

### Add audit and metrics

**Detail:** Log user, tool, arguments, duration and row count to a store outside the SYSPRO database.

### Test with several clients

**Detail:** 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.

**Steps:**

- 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.

**Steps:**

- 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.

## 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

- 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.

## Options

### Open-source or community SYSPRO MCP server

**Fit:** Check whether a maintained one exists for your version; review its code and permissions before trusting it.

**Effort:** Days to evaluate.

### Build in-house

**Fit:** Good if a developer knows e.NET or SQL Server and the tool list is small and stable.

**Effort:** 2 to 6 weeks for a read-only server with logging.

### Partner build and run

**Fit:** Good when you want tested tools, evaluation sets and an on-prem model path without dedicating internal developers.

**Effort:** A pilot in weeks, then extended as workflows grow.

## 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.

## Faq

### What is an MCP server for SYSPRO?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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?

**Answer:** 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.

## Search terms

syspro mcp server, syspro model context protocol, mcp server for syspro erp, build mcp server syspro, syspro e.net mcp, syspro mcp claude, syspro ai tools api, erp mcp server on-prem, syspro mcp read only

---
Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json