How to build an MCP server for Infor VISUAL
Short answer
An MCP server for Infor VISUAL is a small service that exposes a handful of named, read-only tools, such as part lookup and work order status, over the SQL Server database. Any MCP client, including Claude and ChatGPT-compatible tools, can then call them with scoped permissions and an audit trail.
Model Context Protocol gives AI clients a standard way to discover and call tools. For an ERP like VISUAL it means writing the connector once instead of building a separate integration per assistant.
The design work is not the protocol, which an SDK handles. It is deciding what to expose. VISUAL has hundreds of tables, and a server that offers raw SQL will be slow, risky and unpredictable. A server that offers twenty well-named tools will be fast and easy to audit.
This page assumes a typical VISUAL install on SQL Server, accessed from the plant network, and focuses on tool design, authentication, transport and governance.
What teams use it for
Part and inventory lookup
A tool takes a part id and returns description, unit of measure, on-hand by warehouse and location, and open demand and supply summary.
Order and job status
Tools for customer order status and work order status let assistants answer the most common questions without opening any window.
Purchasing visibility
Open PO lines by vendor, by part or by days late, with received quantity, for buyers and planners.
BOM and routing inspection
Return the structure of a part or the operations of a work order for engineers reviewing changes.
Capacity and labor signals
Summaries of open labor tickets and hours by resource, useful for supervisors and for exception-spotting agents.
Infor VISUAL integration surface
- SQL Server connectivity from the MCP host, using a dedicated read-only login mapped to views. Core tables to wrap include PART, PART_LOCATION, CUSTOMER_ORDER, CUST_ORDER_LINE, WORK_ORDER, OPERATION, REQUIREMENT, PURC_ORDER, PURC_ORDER_LINE and VENDOR. Confirm against your version.
- The Visual API toolkit, which you may later wrap as a separate, approval-gated write tool. Do not expose it in the first release.
- Existing Crystal Reports or stored procedures that already encode trusted business logic, which make better tools than rewriting the logic.
- Windows or SQL authentication details, including service accounts and any per-site databases if you run multiple entities.
- Optional ION or API gateway layers if your version and licensing support them, which can sit between the MCP server and the data.
How it works
- 1
List the questions users really ask
Sample a week of emails and chats with planners, buyers and sales. Group them. These groups become tools.
- 2
Design each tool narrowly
Use clear names, typed arguments and short descriptions that say when to use it. Return compact JSON with units and dates, not whole rows.
- 3
Back tools with views and parameterized SQL
Create read-only views for the tables you need. Use parameterized queries only, set row limits and query timeouts, and avoid scans on large transaction tables.
- 4
Choose transport
Use stdio for a local, single-user setup. Use HTTP for a shared server, with TLS, authentication and rate limits behind your reverse proxy.
- 5
Scope permissions per user or role
Pass the caller's identity through to the tool layer, and filter results by site, plant or customer where required. Hide cost fields from roles that do not see them in VISUAL.
- 6
Audit and monitor
Log tool name, arguments, user, row counts and duration. Alert on slow queries and unusual volume.
- 7
Add writes last, behind approval
If you add a create or update tool, make it write a proposal that a person approves, then apply through the toolkit.
Example flows
Tool call for part availability
Trigger: An MCP client calls get_part_availability for a part id
- Server validates the argument and the caller's role.
- It queries a view joining PART with inventory and open supply.
- It returns on-hand, allocated, on-order and next receipt dates.
- The call is logged with user, duration and row count.
Result: The assistant can answer availability questions with data that matches the VISUAL screens.
Blocked tool call
Trigger: A user without cost access requests a costed BOM
- Server checks the role mapping.
- It returns the structure without cost columns and a note explaining that cost is hidden.
- The denial is logged.
Result: Permissions stay consistent across assistants, instead of depending on prompts.
Keeping data on-prem
An MCP server is naturally on-prem friendly: it is a small process on the plant network talking to SQL Server. Run it on a Windows or Linux host near the database, bind it to the internal network, and connect it to a local open-weight model if no data may leave. If a hosted assistant such as Claude needs to reach it, publish only the HTTP endpoint through a reverse proxy with authentication, never SQL Server itself.
Security checklist
- Use a read-only SQL login limited to views, and keep credentials in a secret store.
- Authenticate every HTTP request and tie it to a named user or service.
- Apply row and column filters in the tool layer, not in the prompt.
- Log all calls with arguments and row counts, and retain logs per your policy.
- Keep write tools out of the first release and gate them with human approval later.
Ways to get it done
Write it yourself with an official MCP SDK
Effort: A few days for ten read-only tools, longer with authentication and hosting.
A developer who knows SQL Server and wants full control.
Use a generic database MCP server
Effort: Hours, but raw SQL exposure makes it unsuitable for production.
Quick experiments on a copy of the database.
Partner implementation such as Netray
Effort: Scoped project, usually starting with a small tool set.
You want curated tools, role scoping, audit and a local model option.
Pitfalls
- !Exposing a generic query tool that lets the model write any SQL.
- !Returning thousand-row results that overflow the model's context.
- !Using the application's login for convenience, which breaks auditing.
- !Neglecting query timeouts so one bad call locks up reporting.
- !Copying table names from another VISUAL version without checking.
Frequently asked questions
Is there an official MCP server for Infor VISUAL?
I would not assume one exists. Most teams write a small custom server over the database or a service layer. The protocol is simple; the effort goes into choosing tools and permissions.
Which clients can use it?
Any client that supports MCP, including Claude clients and a growing number of other assistants and developer tools. Support for remote servers varies by client and plan, so test with the clients you actually use.
Should the server read the database directly?
For reads, usually yes, through read-only views. For writes, use the supported toolkit and an approval step. Direct updates risk bypassing business rules in VISUAL.
Stdio or HTTP?
Stdio is simple and keeps traffic on one machine, good for individual use. HTTP is needed for shared access across users, and it requires proper authentication, TLS and monitoring.
How many tools should I start with?
Between five and fifteen. Too many confuse the model's selection. Add new tools when logs show users asking for something the current set cannot answer.
Want MCP server working on your Infor VISUAL?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment