Every JD Edwards site now has people asking AI assistants for help: a C business function to call, a query to write, a code value to decode, a report to explain. The assistant answers instantly — and the details are guesses. Column names, parameter lists and code meanings are exactly what a language model fabricates most fluently, because plausible-looking names are its speciality and your system’s real names were never in its training data. The fix is not a smarter model. It is a reference the assistant can consult: the metadata of your system, served as a tool it can call mid-answer.

An assistant that can look a definition up does not need to invent one.

The shape of the solution, briefly

A small read-only MCP server carries a copy of your system’s metadata — data dictionary items, table layouts with keys and indexes, code types with their values, business views, business functions and their parameter structures — and answers lookups and searches immediately, entirely from memory. The extraction from your own system is included and happens on your side, once per refresh. At runtime there is no database connection and no SQL anywhere in the assistant’s path: it is a reference, not an access route, so it can be given to an assistant without giving that assistant your data. It ships with several levels of helpful guiding for the target LLM, so answers are not just correct but read the JDE way. Both local (STDIO) and network (Streamable HTTP) editions exist, so it fits a desktop assistant and an enterprise deployment alike.

With the shape established, the rest of this article is the use-case list: the problem as it happens on real sites, and what changes when the assistant can consult the model.

C business function development

Problem. Working with JDE business functions means knowing which function does the job, which module it lives in, and exactly what its parameter structure looks like — every field, its type, its direction, whether it is required. That knowledge lives in a fat client several screens deep, and a developer without it either interrupts a colleague or reverse-engineers headers.

Solution. The assistant has immediate access to the full function catalogue, the structures they use, and the data types behind every parameter. “Find the master business function for address book updates, show me its structure, and tell me which parameters are required” becomes one exchange — with the answer drawn from your system, not from folklore.

SQL development and reporting

Problem. Writing SQL against JDE means translating between the business question and a physical model with terse column names, implied decimals, dates that are not SQL dates, and blank-padded values. Generic AI produces syntactically beautiful queries over columns that do not exist, or worse, columns that do exist but are read wrongly.

Solution. Table and column lookup with meaning, storage type and decimals attached, so the assistant writes SELECT ABALPH FROM F0101 WHERE ABAN8 = ? because it looked the names up — and interprets what comes back correctly, dividing where decimals are implied and treating Julian dates as Julian dates.

Index-aware query performance

Problem. A query that scans a large JDE table where it could seek is the difference between seconds and an operational incident. Whether it seeks depends on which indexes exist and their exact column order — information most query authors never see.

Solution. Key and index lookup per table, in column order, so the assistant can shape predicates to an index that exists — or tell you plainly that the filter you want has no index behind it and what that will mean.

Decoding code values

Problem. Half of reading JDE data is decoding it: single letters and short codes whose meanings live in user defined code tables. People keep private cheat sheets; reports ship with codes unexplained; the same letter means different things in different contexts.

Solution. Every code type with every value and its description, on demand — “what does this status mean here, and what are the other possible values?” answered from the same source JDE itself uses, including the context to know which code table applies.

Impact analysis

Problem. “If we repurpose this field, what does it touch?” is a question that decides project scope, and answering it honestly means knowing every table, view and function structure the data item appears in. Few sites can answer it quickly; fewer can answer it completely.

Solution. Reverse lookups are first-class: where a data item is used, which views read a table, what a function module contains. The assistant enumerates the footprint exactly — not by text-matching names that merely look similar.

Business views for reporting and BI

Problem. JDE already contains thousands of curated joins — business views — that report writers rebuild by hand because discovering what a view joins and exposes is slower than starting over.

Solution. View lookup with member tables, join logic and the full column list resolved to real names, plus search by description when nobody remembers what the view is called. Existing curation becomes reusable instead of archaeological.

Building Orchestrations over business functions

Problem. An Orchestration step that calls a business function needs the function’s data structure filled correctly — and finding that structure is the slowest part of building the step.

Solution. Ask for the function, get the structure: every parameter, typed and ordered, with required flags. The assistant can draft the mapping while you are still in the designer. (For running and introspecting the Orchestrations themselves, see the Orchestration side of the story.)

Integration and interface mapping

Problem. Interface and staging work lives or dies on exact physical names, types and lengths. A mapping document with one guessed column costs a test cycle; a misread decimal costs a reconciliation.

Solution. The assistant drafts mapping documents from the real layout — names, types, lengths, decimals — for both sides of the interface, and flags the fields whose storage conventions the receiving system will need to convert.

Onboarding developers and consultants

Problem. The JDE data model is famously large, and fluency in it has traditionally taken years of accumulated exposure. New team members are productive in inverse proportion to how often they must interrupt the one person who knows.

Solution. The reference answers the interruptions: what this table is, how it is keyed, what this item means, where it is used. The veteran’s time goes to judgement instead of lookups — and the newcomer learns the model by asking it questions in plain language.

Grounding every other AI task

Problem. Any AI work that touches JDE — generated code, generated documentation, a data quality review, a migration plan — inherits the model’s tendency to invent identifiers. One fabricated name in generated output silently poisons everything downstream of it.

Solution. With the reference attached, identifiers in generated work are looked up, not sampled. It is the difference between an assistant that sounds right and one that can be checked — and the same grounding is why an assistant helps write correct, index-aware Compositions in a governed capability catalogue rather than plausible ones.

What it is — and deliberately is not

  • Included extraction. The metadata is extracted from your own system, on your side, with the included utility. Nothing about your system leaves your network.
  • No direct SQL access. The server answers about the model, never from the data. There is no database connection at runtime, so attaching it to an assistant grants exactly nothing beyond the reference.
  • Immediate response. Answers come from memory, at conversational speed, however large the model.
  • STDIO or Streamable HTTP. The same server plugs into a desktop assistant locally or serves over HTTP/HTTPS to networked clients.
  • Guidance included. Several levels of helpful guiding travel with the answers, so the assistant reads JDE storage conventions the way JDE means them.
  • Read-only by construction. There is nothing to misuse into a write path.
Ground your assistants in the real model

The JDE Metadata MCP Server is part of the AI MCP Servers collection, alongside servers for JDE Orchestrations, controlled files and distributed log analysis.

See the JDE Metadata MCP Server All AI MCP Servers