MCP serverJD Edwards EnterpriseOne Agent view

How to build an MCP server for JD Edwards EnterpriseOne

Short answer

An MCP server for JD Edwards EnterpriseOne is a small service that translates MCP tool calls into AIS requests that run Orchestrator orchestrations. Expose read-only tools first, authenticate each call as an E1 user, bound every result, and log everything. It then works with Claude, ChatGPT and any other MCP client.

The Model Context Protocol gives AI clients a standard way to discover and call tools. For E1 that is attractive because there is no single obvious API for an assistant: there are forms, orchestrations, business services and thousands of tables. An MCP server lets you present a curated, safe slice of that surface instead.

The craft is in deciding what the tools are. A tool called run_sql is a liability. A tool called get_po_status that takes a PO number and company and returns a typed record is something you can reason about, secure and test.

This page covers the tool design, auth, transport and operational choices for a real E1 estate, including the on-prem constraints that most MCP tutorials ignore.

What teams use it for

Item and inventory lookup

Tools for item master basics, on-hand by branch/plant and location, and lot or serial status.

Order status tools

Sales order, purchase order and work order status with promise dates and quantities.

Bill of material and routing reads

Return a single-level or exploded BOM and the routing for an item, bounded by depth.

Planning message retrieval

List MRP action messages for a branch/plant and buyer, with the related supply and demand.

Controlled write proposals

Later, tools that create a proposed change in a staging table or approval queue rather than updating E1 directly.

Data dictionary and UDC help

A lookup tool for UDC values and data dictionary descriptions so models stop guessing what a status code means.

JD Edwards EnterpriseOne integration surface

  • AIS Server: POST to orchestration endpoints with a JSON body, authenticated by a token obtained from the token request service for an E1 user and environment.
  • Orchestrator Studio: define inputs, outputs, form requests, data requests and rules; the Orchestrator output becomes the tool result.
  • Orchestrator Studio service requests and aliases can wrap business functions and UBEs; use only supported ones.
  • Direct read-only database access for analytical tools, using a reporting user and views rather than raw F-tables.
  • E1 security: user and role, application, row and exit security, which AIS enforces for the authenticated identity.

How it works

  1. 1

    Define the tool catalogue

    Write each tool with a name, a one-sentence description, typed parameters and a response schema. Start with 6 to 10 read tools.

  2. 2

    Implement orchestrations

    One orchestration per tool where practical. Keep outputs small and use plain field names via aliases.

  3. 3

    Build the server

    Use the official MCP SDK. Handle AIS token acquisition and refresh, retry with backoff, and map AIS errors to clear tool errors.

  4. 4

    Pick the transport

    stdio is fine for a developer desktop. Use streamable HTTP behind TLS and an identity provider for a shared server.

  5. 5

    Implement identity

    Pass the end user identity through so E1 role security applies, or use a scoped service account with an allowlist per client.

  6. 6

    Add limits and audit

    Row caps, timeouts, per-user rate limits and an immutable log of tool name, parameters, user and result size.

  7. 7

    Test with real prompts

    Build a set of 50 questions with expected tool calls and check them on every change.

Example flows

Item availability tool call

Trigger: Client asks whether item 1001 is available in branch/plant 30.

  1. Client calls get_item_availability with item and branch/plant.
  2. Server authenticates to AIS as the mapped E1 user.
  3. Orchestration returns on-hand, committed and on-order quantities.
  4. Server returns a trimmed record with a data timestamp.

Result: The model answers from structured data and quotes the timestamp.

Denied by security

Trigger: A user without access to branch/plant 50 asks about it.

  1. Tool call reaches AIS under the user's identity.
  2. E1 row security denies the request.
  3. Server returns a clear permission error without leaking data.

Result: The model tells the user it has no access, rather than inventing an answer.

Keeping data on-prem

Run the MCP server on a host inside the same network zone as the AIS server and your identity provider. Use streamable HTTP with mutual TLS or an internal reverse proxy, and keep the model on GPUs in the same environment if data cannot leave. The server itself has no cloud dependency. For air-gapped sites, package the server and its dependencies in an internal registry, pin versions, and use stdio or an internal HTTP endpoint. If a hosted client such as Claude or ChatGPT needs to reach it, put an authenticated gateway in your DMZ and expose only the tools that are safe for that client class.

Security checklist

  • Per-user identity propagation into E1 so role and row security apply.
  • Tool allowlists per client; a read-only client never sees write tools.
  • Input validation on every parameter: types, lengths, allowed values, company and branch/plant scope.
  • Result caps and field-level redaction, with a data timestamp on every response.
  • Immutable audit logging shipped to your SIEM, and secrets held in a vault, not in config files.

Ways to get it done

Generic database MCP server over the E1 database

Effort: Hours, with significant risk.

Fine for a developer sandbox. Poor for production because it bypasses E1 security and logic.

Custom MCP server over Orchestrator and AIS

Effort: About 3 to 6 weeks for a first version with audit.

The right default for most E1 customers with a developer on hand.

Netray-built server with a tested tool library

Effort: Pilot in weeks, depending on how many tools and what security review is needed.

When you want a hardened starting point and on-prem models in the same package.

Pitfalls

  • !Exposing a free-form SQL tool and calling it a feature.
  • !Using one shared AIS user for everyone and losing accountability.
  • !Returning wide rows with every column of F4101 and burning context.
  • !Letting token expiry bubble up as a confusing error instead of refreshing.
  • !Skipping a regression set so tool changes silently break agent behaviour.

Frequently asked questions

Does Oracle provide an MCP server for JD Edwards?

I am not aware of one that is generally available, and the landscape moves quickly, so check current Oracle and community sources. Building your own over AIS and Orchestrator is common because you control the tools and the security model.

Which tools should I expose first?

Read-only ones that answer frequent questions: item availability, PO status, sales order status, work order status and BOM. Avoid anything that writes or runs arbitrary queries until you have audit and approval in place.

stdio or HTTP transport?

stdio is simple and good for a single developer or desktop client. HTTP is what you want for a shared, centrally managed server with identity, rate limiting and monitoring. Most production E1 deployments use HTTP behind TLS.

Will it work with ChatGPT as well as Claude?

MCP is an open protocol with support across multiple clients, though client support and remote-server requirements differ and change. Design the server to standards and test each client you intend to use.

How do I handle write operations?

Do not give the model direct updates. Expose a tool that creates a proposal in an approval queue, and run the actual orchestration as the approving user after review.

Want MCP server working on your JD Edwards EnterpriseOne?

A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.

Get a free assessment