Geoprise Technologies - AI Agents

Tales From The Front: Building MCP Servers From GM-X Auto OpenAPI Documentation

admin — Mon, 21 Sep 2026 04:44:43 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

My first boss, Ken Bordner, was fond of constantly telling me, “you may know theory but, goddammit, I know it practical!”

So it is with building Model Context Protocol (MCP) servers from OpenAPI documentation. In this post, I’ll explain:

How hard it is to produce production-grade OpenAPI specifications;
Once they are production-ready, how easy it is to generate MCP servers; and
Gotchas you won’t have to worry about when deploying our newly-published GM-X Auto OpenAPI MCP Bridge documentation.

Preparing OpenAPI Documentation

The OpenAPI specification, established in 2016, is derived from Swagger, an application programming interface (API) project which first appeared in 2011―13 years before Anthropic introduced the MCP standard. Over the years it evolved to become the de facto standard for describing Representational State Transfer (REST) APIs because it facilitates the automated production of machine-readable contracts between providers and consumers of Web services. According to Riya Sethi, a Senior Software Engineer for Truto, a unified API and embedded integration platform, raw OpenAPI specifications are

written for humans who read documentation and machines that validate payloads.

One prominent feature of the OpenAPI specification is its support for modularization and re-use by references that point to objects or components defined elsewhere in the same file, in a separate file on the same local machine, or even on a remote machine. The specification strongly encourages references to eliminate redundancy, improve readability, and simplify maintenance―exactly the same benefits developers reap from normalizing databases or writing subroutines. Accordingly, all source code for Geoprise’s GM-X Auto OpenAPI documentation is generated and maintained in highly modular “referenced” form wherein each path has its own file, and re-usable schema components are documented in a separate file.

The creators of Swagger and OpenAPI never envisioned supporting MCP; instead, MCP relies upon OpenAPI-compliant documentation as a complete, machine-readable contract setting out API endpoints, parameters, and schemas that the protocol requires to make remote procedure calls (RPCs) on behalf of Large Language Model (LLM) applications such as Claude Desktop or the ChatGPT Desktop App. Sethi explains that LLMs neither read documentation nor validate payloads; they

read schemas as prompts. A description field is not metadata to them; it is the instruction.

Furthermore, according to Sethi, MCP requires schemas to be

completely self-contained, meaning they cannot reference anything outside themselves. This requires ‘dereferencing’ – a process of resolving all references and inlining them into a single schema,

including detection of recursive references to avoid infinite loops.

For us, dereferencing meant having to undo all the hard work already invested in modularizing our GM-X API documentation by reference. We discovered through trial and error that to ward off server-side request forgery (SSRF) attacks and threats posed by path traversal vulnerabilities, the most forgiving of the MCP server generators we tested would only resolve references to components within the same document―even when an option to allow external references is available. To work around those safeguards, we had to copy and bundle together the schemas for each path by API, and also append a copy of the re-usable components to every bundle.

Even after bundling, however, we found that none of the MCP server generators were capable of successfully resolving internal references to path item or schema objects outside the components section of the API documentation, despite the fact that, for e.g. path item objects, Versions 3.x of the OpenAPI specification allow us to

logically replace the [referencing object] with a Path Item Object that combines the [referenced object’s] fields with [other] fields of the [referencing object], as long as none of those fields conflict.

We ultimately overcame that limitation by re-labeling all remaining path item and schema object references within API bundles using the description keyword. This tactic eliminates resolution errors when generating MCP servers, while preserving our API bundles’ human readability.

Such limitations, I believe, reflect the relative immaturity of MCP server generation software. Let’s not forget that, as I write this, the MCP protocol isn’t quite two years old, and getting AI agents up to speed using MCP has been a much higher industry priority than making MCP server generator software smarter.

Moreover, our workaround has no adverse impact whatsoever on out-of-the-box performance of automatically generated MCP servers, because only in output schema do we re-label references as descriptions in our API bundles. Unlike input schema, output schema are optional for MCP server tools, according to Sections 5.1 and 5.2.7 of the MCP Specification, and MCP server generator developers apparently assume that LLM applications require no further assistance when parsing whatever output they receive from tool responses. Should such assumptions prove wrong, then the human-readable descriptions inside our API bundles will make it much easier to add output schemas manually where needed to improve the performance of MCP server tools.

All of our 452 API bundles are available from GitHub as OpenAPI documents in JavaScript Object Notation (JSON) format. Each bundle is a single file artifact comprising a fully self-contained assembly of OpenAPI components to promote error-free use. This is the preferred way of interacting with Geoprise GM-X Auto OpenAPI descriptions when generating MCP servers automatically.

Generating MCP Servers Automatically

This process is highlighted in Figure 1, below.

Figure 1 – Automatic MCP Server Generation Process

You can install and use the self-hosted open-source openapi-mcp-generator to generate MCP servers automatically. We successfully tested it by following these steps:

Install Node.js first, if you haven’t done so already. Point your browser to the official Node.js download page and follow the instructions to get and run a prebuilt Node.js Installer or Binary.
To install the generator software, open a command line interface (CLI) on your computer and use your keyboard to type the npm install -g openapi-mcp-generator command, followed by the Enter key. When the installation is complete, you’ll see something like:

added 108 packages in 17s

35 packages are looking for funding
run `npm fund` for details

Now that the generator software is installed, create one MCP server for each GM-X Auto API that the LLM application will utilize. For example, to create an MCP server for the GM-X Auto logon API:

Point your browser to the Geoprise GM-X Auto GitHub models page.
On the GM-X Auto GitHub models page, or at its left sidebar, browse for and click or tap the GMXAuto_logon.json link. The API documentation page appears for the logon API.
Near the upper right corner of the API documentation page, click the Download raw file button. The GMXAuto_logon.json file is copied to the Downloads folder on your computer.
Navigate to the Downloads folder on your computer, cut (or copy) the GMXAuto_logon.json file you downloaded at Step 5, above, and paste it into the folder you wish to use as your source document repository. This is the path/to/ folder at Step 8, below.
Create a new folder for the MCP server on your computer. This is the path/to/output/directory folder at Step 8, below.
In the CLI, use your keyboard to type the openapi-mcp-generator --input path/to/GMXAuto_logon.json --output path/to/output/directory command, followed by the Enter key. Substitute path/to/ and path/to/output/directory, respectively, with the paths to the folders described at Steps 6 and 7, above. In a split second, you’ll see the result illustrated in Figure 2, below.
Repeat Steps 3 through 8, above, for each additional GM-X Auto API that requires an MCP server.

Note that for obvious reasons it is mandatory to create an MCP server for the GM-X Auto logon API, unless you’ve configured your AI agents to use Amazon Web Services (AWS) application load balancer (ALB) authentication session cookies.

It is also mandatory to create a separate MCP server for the GM-X Auto menu API (GMXAuto_menu.json file), which provides access to all GM-X ERP functions, forms, and reports while strictly enforcing all role-based access controls that prevent AI agents from escaping and running wildly free.

Note also that our API bundles available at GitHub describe a reference implementation of the GM-X ERP application, not live sites. For MCP servers generated from those bundles to actually work, you must first modify the files you downloaded at Step 5, above, so Line 17 points to a real running server that hosts the GM-X ERP application. Lines 17 and 21 show exemplary uniform resource locators (URLs) for production using different authentication methods. Line 25 shows an exemplary URL for final staging QA, while Line 29 shows an exemplary URL for integrating testing and Line 33 shows an exemplary URL for development. As you can see in Figure 2, the MCP server generator uses the first URL (Line 17) by default.

Figure 2 – Automatic MCP Server Generation Using Open-Source openapi-mcp-generator

Alternatively, you can subscribe to various MCP generator services such as Postman, Speakeasy Gram, liblab, Prefect FastMCP, and Stainless. We successfully tested the Speakeasy Gram service for the GM-X Auto logon API by following these steps:

Point your browser to the Speakeasy service and log on to your Speakeasy account. The Speakeasy Dashboard screen appears.
On the Speakeasy Dashboard screen, in the PROJECTS section, search or browse for and then tap, or click, the project for which you wish to create the new MCP server. The Project Overview section appears on the Speakeasy Dashboard screen.
At the left sidebar of the Speakeasy Dashboard screen, select the MCP Gateway link. The MCP Servers section appears on the Speakeasy Dashboard screen.
Within the MCP Servers section on the Speakeasy Dashboard screen, tap or click the + Add new button. The Add MCP server screen appears.
In the Advanced section on the Add MCP server screen, click the Continue -> link in the From your API box. The Import OpenAPI specification screen appears.
Navigate to the path/to/ folder on your computer described at Step 6, above.
On the Import OpenAPI specification screen, drag and drop the GMXAuto_logon.json file into the box beneath the UPLOAD button of the Upload OpenAPI Specification section, which is activated by default. The name of this file appears by default (in lowercase) in the Name Your API text box below. Optionally, in the Name Your API text box, you can rename the API to your liking
Tap or click the CONTINUE button to the right of the Name Your API text box. The Speakeasy Gram service creates the MCP server and displays the Continue -> button in the Generate Tools section in a second or two.
In the Generate Tools section, tap or click Deployment details to view a log of the outcome. Figure 3, below, illustrates.
Tab or click the Continue -> button beneath the Deployment details. The MCP Servers section re-appears on the Speakeasy Dashboard screen displaying the new server you added at Steps 13-18, above.
Repeat Steps 13 through 19, above, for each additional GM-X Auto API that requires an MCP server.

Figure 3 – Automatic MCP Server Generation Using Speakeasy Gram Service

Both of the above examples prove that GM-X Auto API bundles can be input to MCP generators to create new MCP services without errors. Geoprise has produced all the production-ready OpenAPI specifications for the GM-X Auto ERP application, so you don’t have to.

To see for yourself, I invite you to visit our GitHub site, choose one or more models of greatest interest to you, and follow the steps I've set out here. There's no need to book any demos.

Additional Self-Hosting Configuration Steps

As you can see from the Figure 2, the self-hosting option requires you to complete a few additional configuration steps before AI agents can reach the new MCP servers. You’ll need to:

In the CLI, use your keyboard to type the npm install command, followed by the Enter key, to install the MCP server’s dependencies.
In the CLI, use your keyboard to type the npm run build command, followed by the Enter key, to generate TypeScript code for the MCP server.
In the CLI, use your keyboard to type the npm start command, followed by the Enter key, to start and run the MCP server.
Open the settings or desktop configuration file for your LLM application; for e.g., navigate to Settings -> Connectors -> Create for the ChatGPT Web or desktop client, or open the claude_desktop_config.json file for Claude Desktop.
Modify the settings or desktop configuration file you opened at Step 24, above, to insert the MCP server, and then re-save the settings or desktop configuration file.
Repeat Steps 21-25, above, for each additional GM-X Auto API that requires an MCP server.

Gotchas You Won't Have To Worry About When Deploying The GM-X Auto OpenAPI MCP Bridge

Riya Sethi, the Truto Software Engineer, doesn’t mince words in her blog post OpenAPI to MCP: How MCP Servers Auto-Generate Tools From API Docs:

If you are building AI agents that interact with external SaaS platforms, you have likely hit a wall. Manually writing and maintaining JSON Schema tool definitions for every API endpoint across dozens of providers is an unscalable architecture.

Why? Because:

Vendor APIs change constantly. Endpoints are deprecated, required fields shift, and documentation often lies. Hardcoding your AI agent's tools against these moving targets guarantees your engineering team will spend their cycles patching broken schemas instead of improving agent reasoning … Auto-generating MCP tools from OpenAPI specifications is not a simple parsing exercise. It is a solved problem in the trivial case and a hard problem at production quality.

Having done all that work, even if you successfully:

take a vendor's OpenAPI specification, run it through a script, and expose every single endpoint as an MCP tool [, such] naive 1:1 mapping fails in production immediately.

That’s because of “tool explosion” or “context bloat” which means:

A REST API with 200 endpoints becomes 200 tools. LLMs struggle with tool selection accuracy when presented with more than 25 to 50 tools at once. Frontier models degrade sharply once the tool list crosses a few dozen entries because every tool description competes for the same context budget and the router has to disambiguate more candidates per call. Ship all 200, dump an entire spec into an MCP server, and the agent starts guessing while wasting massive amounts of valuable context window space.

Every tool description you expose to an LLM costs tokens on every request. A 200-endpoint API shipped as 200 MCP tools burns 15-30k tokens before the model has read the user's message. Context bloat is not a rounding error; it is the dominant cost driver for agent workloads … Because LLMs degrade when exposed to more than 50 tools, you cannot serve a massive API surface on a single MCP endpoint. You must implement filtering. The fix is tool scoping. Group endpoints by functional area and let the MCP server owner select which groups to expose … Combined tag and method filters routinely cut a 200-tool provider dump down to 12-30 relevant tools per server, which is the sweet spot where models stop hallucinating tool names and context windows are preserved.

The GM-X Auto OpenAPI MCP Bridge documentation consists of 452 API bundles that expose a total of 7,870 endpoints, or 17 endpoints per API on average. This means only four of the APIs (less than one percent) expose more than 50 tools per MCP server, of which the largest (GMXAuto_invoice_header.json) ships with 87―far short of the 200-tool “dumps” that SaaS vendors tend to provide.

By contrast, 398 of the GM-X Auto API bundles (88 percent) ship with 30 or fewer tools per server, and those API bundles expose just 14 endpoints per API on average.

In short, the overwhelming majority of GM-X Auto API bundles fit well within the “sweet spot” that preserves context windows and avoids hallucinations, without requiring any additional filtering. Only the judicious selection of APIs to fit specific narrowly-scoped AI deployments is needed.

Sethi mentions another important architectural aspect concerning “snake case,” the naming convention for objects, properties, and methods which replaces spaces with underscore (_) characters, and uses lowercase letters only:

LLMs handle get_single_hubspot_contact_by_id or create_a_crm_contact more reliably than getContact. The tool name doubles as a strong semantic hint about the operation. Names derived from the provider label plus resource plus method survive tokenization better and reduce hallucinated tool calls.

The good news is that nearly all objects and properties within the GM-X ERP application are natively identified using “snake case,” as our Programming Guidelines have strongly recommended for the past twenty years. Names that comply with those guidelines not only provide the optimal semantic hints for LLMs; they eliminate difficulties that LLMs encounter when trying to comprehend labels used in legacy ERP systems.

To illustrate, as shown in the GMXAuto_unit_of_measure_conv.json API, the GM-X object name is uom_conversion and one of its property names is conversion_factor. The name of the path which adds a new conversion factor is uom_conversion(add2) which is derived from the resource and method. Comparable names within the legacy SAP S/4HANA ERP system offer much weaker semantic hints for LLMs; for example, BAPI_MATERIAL_SAVEDATA (the method for adding a new conversion factor for material), BAPIMATMRM (unit of measure conversions object for material), UMREZ (conversion numerator), and UMREN (conversion denominator).

Conclusion

In conclusion, the foregoing constitutes irrefutable proof that the GM-X Auto OpenAPI Bridge documentation can genererate working Model Context Protocol (MCP) servers automatically, without the explosion of tools, context bloat, or token consumption waste that plagues APIs provided by vendors of most ERP applications, including Software-as-a-Service (SaaS) as well as legacy ERP APIs.

GM-X Auto OpenAPI Bridge Documentation Now Available at GitHub

admin — Thu, 10 Sep 2026 10:23:30 +0000

BANGKOK, September 8, 2026―Today, just 3 weeks after its launch announcement, Geoprise published machine-readable documentation at GitHub for GM-X Auto, the first and only enterprise resources planning (ERP) application suite in the world to expose all of its 3,887 functions, screens, and reports to Model Context Protocol (MCP) servers through 452 published application programming interfaces (APIs) that are compatible with the OpenAPI Specification (OAS).

All 452 OpenAPI documents are available in bundled format, and are located in the models folder.[1] They are single file JavaScript Object Notation (JSON) artifacts comprising assemblies of OpenAPI components to promote useability and portability. This is the preferred way of interacting with Geoprise GM-X Auto OpenAPI descriptions. They reflect a reference implementation of the GM-X ERP application, Version 11.3.0.

Because all GM-X Auto APIs are documented in compliance with the OAS (formerly known as the Swagger Specification), they can be transformed automatically into functional MCP servers that expose them as tools to frontier large language model (LLM) applications, such as Claude Desktop, that have titles, descriptions, and input schema which AI agents can discover and interpret to create natural-language requests. The MCP server converts those requests into API calls which activate the documented Web application functions that generate and return the results to the AI agent.

The documentation is licensed under the GNU Affero General Public License v3.0.

[1] The final tallies of APIs, functions, screens, and reports are slightly different from what Geoprise announced last month, and were primarily motivated by the firm's decision to disable four APIs reserved for developers and implementors only, and therefore deemed to introduce unacceptable security risks for GM-X end users.

About Geoprise

Geoprise Technologies Corporation was formed in 1999 by a group of software executives with over a century of previous cumulative experience building ERP and manufacturing operations management systems and implementing them worldwide. The privately held company's mission, then and now, is to create exceptional value for its customers by harnessing the power and economy of information technology to enable lean, world-class industrial operations on a global scale. Today, Geoprise focuses exclusively on delivering its state-of-the-art GM-X Auto ERP solution to businesses operating in North America, Europe, Asia, and the Pacific Rim. Geoprise values integrity by maintaining strict independence, intense commitment to business ethics and profound respect for intellectual property rights. For further information, visit the company's website at geoprise.com.

Geoprise Announces First-Ever OpenAPI Bridge To Fully Connect ERP and Agentic AI

admin — Wed, 12 Aug 2026 09:18:35 +0000

BANGKOK, August 12, 2026 ― Geoprise Technologies today released GM-X Auto, the first and only enterprise resources planning (ERP) application suite in the world to expose every single one of its 3,871 functions, screens, and reports to Model Context Protocol (MCP) servers through 456 published application programming interfaces (APIs) that are compatible with the OpenAPI Specification (OAS). Previously, according to Openapi, Europe’s biggest API Marketplace, no commercial ERP applications exposed all their screens, internal functions, and reports as OpenAPI-conforming APIs out of the box.

“GM-X Auto is a truly revolutionary breakthrough,” said Geoprise Founder Nelson Nones. “Not one of the legacy ERP applications on the market today exposes its entire set of functions, screens, and reports through OAS-compatible APIs. Although a few challengers offer API-first, metadata-driven ‘headless ERP’ systems, none has screens that people can use, nor do any of them address the mission-critical finance requirements that GM-X Auto does, such as general ledger, receivables, payables, or assets,” he added.

Nones likens the new GM-X Auto OpenAPI Bridge to a famous high-speed input-output bridge introduced 44 years ago that enabled IBM mainframes to offload scientific number crunching to Cray supercomputers for the first time. In 1985, the New York Times reported that “manufacturers, and now even movie companies, are also buying the machines, which provide far-greater computing power than any mainframe can deliver,” quoting an industry analyst who proclaimed, “It’s clear the market is poised for explosive growth.”

According to Nones, “just as Cray connected its powerful new supercomputers to existing business mainframes in the past, MCP today harnesses the reasoning, planning, and decision-making capabilities of advanced, state-of-the-art frontier large language models (LLMs) by giving LLM Applications like Claude Desktop a reliable way to discover, rationalize, and interact with Web applications” such as the GM-X Auto ERP system. The business opportunity driving LLM adoption is the automation of repetitive, tedious ERP data entry and reporting tasks using AI agents.

The Geoprise motto for GM-X Auto is, “ERP for AI when you can; for people when you must,” signifying that when tasks must be entrusted to people instead of AI, GM-X Auto is fully functional using any smartphone, tablet, or desktop browser; yet when the same tasks can be safely delegated to AI agents, MCP servers expose them as tools that AI agents learn to execute in exactly the same way, and between the same guardrails, that human users would.

The GM-X Auto Audit subsystem holds both people and AI agents accountable by keeping complete histories of who (or which agent) changed what, what they changed, and when they changed it. The GM-X Auto ERP system also mitigates AI risks by employing exactly the same role-based access controls for AI agents that enterprises can configure the system to enforce for human users.

For further information, please visit the blog post.

About Geoprise

ERP For AI When You Can; For People When You Must

admin — Tue, 11 Aug 2026 09:46:05 +0000

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

Nearly a half-century ago, Cray Research, Inc. owned the high-end scientific computing market. It faced practically no direct commercial competition ever since launching its CRAY-1 supercomputer in 1975.

But the niche market for high-end scientific computers was small, so the company’s president, John Rollwagen, engaged my father, Walter Nones, to conduct a marketing strategy study to discover new growth opportunities.

Drawing upon in-depth interviews with senior business executives across the United States, my father concluded that the commercial business data processing market long dominated by International Business Machines Corporation (IBM) was ripe for exploitation, but required a new kind of high-speed input-output bridge allowing IBM mainframe computers to offload scientific number crunching to Cray supercomputers at the back end.

Accepting those findings, Rollwagen initiated a strategic shift to multi-processor architectures and parallel computing, culminating in the launch of the CRAY X-MP in 1982. Thereafter, Cray’s revenues and net earnings grew over fourfold, from 516 million to 2.2 billion USD of revenue and 69 to 289 million USD of net earnings in today’s dollars by 1991, and the number of employees grew apace from about 1,300 to nearly 5,400.

According to a 1985 New York Times article,

“all three of the nation's largest auto makers have installed supercomputers in their design centers, seeking to test-drive their prototypes without ever building them … Aerospace and chemical manufacturers, and now even movie companies - seeking to create three-dimensional special effects for science fiction films - are also buying the machines, which provide far-greater computing power than any mainframe can deliver. ‘It's clear the market is poised for explosive growth,’ said Jeffry Canin, an analyst at Hambrecht & Quist Inc., ‘because now it's not just the Defense Department and the universities that are grabbing them up.’”

The Model Context Protocol Bridge

The Cray Research story reminds me of the way many businesses are adopting advanced, state-of-the-art frontier large language models (LLMs) today. Just as the CRAY X-MP connected powerful new supercomputers to existing business mainframes, Model Context Protocol (MCP) harnesses the reasoning, planning, and decision-making capabilities of LLMs such as Anthropic Claude, Microsoft Copilot, Google Gemini, and OpenAI ChatGPT by reliably connecting autonomous AI agents to application programming interface (API) endpoints exposed by Web applications.

Simply put, MCP gives LLMs a way to discover, rationalize, and interact with Web applications including mission-critical enterprise resources planning (ERP) software. The business opportunity driving the adoption of LLMs is the automation of repetitive, tedious data entry and reporting tasks using AI agents.

First released by Anthropic in November 2024, MCP is today’s universal standard for connecting AI agents to APIs. Any API that is documented according to the OpenAPI Specification―formerly known as the Swagger Specification―can be transformed automatically into functional MCP servers that expose the API as a tool to LLM Applications such as Claude Desktop, as shown in the illustration below. Transformation is done using popular MCP generator services including Postman, Speakeasy Gram, liblab, Prefect FastMCP, and Stainless (now part of Anthropic); and self-hosted generators such as the open-source openapi-mcp-generator are also available.

Each tool visible and available to an LLM Application has a title, description, and input schema which AI agents can discover and interpret to create natural-language requests. The MCP server converts those requests into API calls which activate specific Web application functions that generate and return the results to the AI agent.

The Legacy ERP Conundrum

Generally, ERP applications are a class of business software dominated by well-known legacy incumbents including SAP ECC and older SAP R/3 releases, Oracle E-Business Suite (Oracle EBS), Oracle NetSuite, PeopleSoft, JD Edwards, Infor, and older Microsoft products like Dynamics Great Plains (GP) and Dynamics NAV.

Those mission-critical systems were expensive to buy, even more expensive to customize and implement, and are proving exceedingly difficult to replace due to their broad enterprise footprint. Increasingly, they are obstructing the adoption of AI agents for the purpose of automating repetitive, tedious data entry and reporting tasks, because they expose few―if any―APIs that comply with the OpenAPI Specification (OAS).

In fact, not one single legacy ERP application on the market exposes its entire set of transactions (functions, screens, and reports) as OAS-compatible APIs today, and many of them require proprietary adapters or API gateways to generate OAS-compatible documentation for specific transactions like Accounts Payable or Order Management.

According to Seth Ravin, CEO of Rimini Street, a global provider of end-to-end enterprise software support,

“A Censuswide survey of 4,295 CFOs, CISOs, CIOs, and CEOs found that 70% do not see traditional ERP as the future of enterprise software. That is not a fringe opinion from a handful of disgruntled IT directors — it is a majority position among the people who sign off on enterprise technology budgets. The alternative they are increasingly pointing to is headless ERP: an architecture that separates the system that runs your business from the interface your employees actually use.”

Headless ERP Architecture And Its Pitfalls

Ravin continues,

“Traditional ERP systems are monolithic: the database, the business logic, and the user interface are bundled together and shipped as one product … Headless ERP inverts this. It separates the backend, the database, business logic, and core operational functions like finance, inventory, and HR, from the ‘head,’ the user interface layer that employees, customers, and partners actually interact with. In a headless architecture, the ERP engine exposes its functions through APIs rather than through a fixed set of screens.”

A much newer class of “API-first” or “metadata-driven” ERP applications is emerging that expose all their transactions as OAS-compatible APIs requiring no proprietary middleware or custom-coded wrappers, but the leading headless ERP challengers have two major weaknesses.

First, they are truly headless in that they provide no user interface whatsoever, which makes them impossible to use when businesses must entrust the execution of specific transactions (such as the approval and initiation of electronic payments) to people because AI agents are too risky.

Second, the leading headless ERP challengers have a much narrower ERP footprint than legacy ERP incumbents. As just one example, none of them offer any finance capabilities such as General Ledger, Accounts Payable, Accounts Receivable, or Fixed Assets.

GM-X Auto – A Revolutionary Breakthrough

Today, Geoprise Technologies became the first and only ERP software house in the world to offer an ERP application—GM-X Auto—that exposes every single one of its 3,871 functions, screens, and reports to MCP servers through 456 OAS-compatible APIs requiring no proprietary middleware or custom-coded wrappers.

Unlike the offerings of headless ERP challengers, GM-X Auto also provides a browser user interface for each of those 3,871 transactions, so they are equally accessible and useable by people as they are by AI agents. Originally introduced in 2018, the GM-X Auto user interface is fully responsive, allowing it to run equally well on smartphone, tablet, and desktop browsers.

GM-X Auto, therefore, can function in either headless or traditional (“headful”) modes. The motto for our unique capability is,

“ERP for AI when you can; for people when you must.”

When tasks must be entrusted to people instead of AI, the GM-X Auto ERP application works exactly the same as GM-X itself has done for many years.

When tasks can be delegated to AI agents, on the other hand, MCP servers expose them as tools that execute those transactions in exactly the same way that human users would when using a smartphone, tablet, or desktop browser.

Also, unlike the software capabilities of headless ERP challengers, 21 different GM-X Auto subsystems cover an exceptionally broad enterprise footprint encompassing finance (General Ledger, Accounts Receivable, Accounts Payable, Fixed Assets), customer relationship management (CRM), supplier relationship management (SRM), supply chain management (SCM, including manufacturing and logistics), strategic human resources (HR), and business process management (BPM).

How GM-X Auto Mitigates Autonomous AI Agent Risks

Without human oversight, it’s no secret that AI agents introduce major security and governance risks because of their ability to plan, decide, and act autonomously. Those risks can multiply exponentially when AI agents hold broad, long-lasting API keys or tokens, potentially allowing attackers to move laterally through an ERP system.

The GM-X Auto ERP application substantially mitigates those risks by employing exactly the same role-based access controls for AI agents that you can configure the application to enforce for human users.

As a non-negotiable best practice, Geoprise strongly recommends assigning a permanent and unique GM-X User Id to each running AI agent instance, just as you would assign a unique User Id to each human user. This practice will hold every AI agent accountable for its actions through the built-in GM-X Audit subsystem which automatically maintains a complete history of who (or which agent) changed what, what they changed, and when they changed it.

It also allows you to assign roles you configure for AI agents that grant access to the narrowest possible scope of data and transactions needed to perform the tasks delegated to AI agents, thereby enabling you to erect strong guardrails that prevent autonomous AI agents from spawning cascading streams of errors, unforeseen liabilities and financial costs, or leaking vital secrets, should they escape and run amok.

GM-X Auto also saves you money. Assigning a permanent and unique User Id to each AI agent instance can become prohibitively expensive under user-based ERP licenses or Software-as-a-Service (SaaS) subscriptions, because each one requires a separate paid-up account no matter when or how often the instance runs. But this is never a problem with the GM-X Auto ERP application, which is licensed and paid for by application server. Each GM-X Auto server supports unlimited users, whether AI agents or people.

Geoprise Technologies - AI Agents

Tales From The Front: Building MCP Servers From GM-X Auto OpenAPI Documentation

Tags:

GM-X Auto OpenAPI Bridge Documentation Now Available at GitHub

Tags:

Geoprise Announces First-Ever OpenAPI Bridge To Fully Connect ERP and Agentic AI

Tags:

ERP For AI When You Can; For People When You Must

Tags: