Add MCP as an interface, not as a bypass.
MCP is useful when it turns approved enterprise capabilities into small discoverable tools. It is dangerous when it becomes a fashionable excuse to expose a broad backend with no clear authority model.
What MCP adds to an EnterpriseOne estate
A compatible AI client can discover tools at runtime, inspect their descriptions and schemas, and invoke them in a structured way. That makes MCP a natural bridge between an assistant and a collection of JDE capabilities.
The key design decision is the size of each tool surface. A JDE Orchestration MCP should expose approved Orchestrations. A metadata MCP should expose technical discovery. A log-analysis MCP should expose search and evidence operations. Keeping these concerns separate makes security and reasoning easier.
JDE Metadata MCP
Give the model controlled access to JDE metadata and definitions rather than forcing it to guess table, field and object semantics.
Steward
Authenticate, govern and execute compatible MCP backends behind a secure enterprise boundary.
Keep MCP servers small enough to understand
- A JDE server should remain a JDE server.
- A log server should remain a log server.
- A file server should be constrained to approved roots and operations.
- Each server should have a deliberate identity and authorisation model.
This is easier to review than one “enterprise MCP” with dozens of unrelated wildcard capabilities.
Where Steward changes the security model
For Windows/AD-protected resources, Steward can preserve the human user's authority through to the downstream resource. For API-backed MCP servers, the downstream API may instead use its own service credential. Both models can coexist, but they should not be confused.
The downstream resource still needs an explicit answer to “whose authority is this?”