How to build an MCP server for IFS Cloud
Short answer
An MCP server for IFS Cloud is a small service that turns selected OData projections into named tools, authenticates through IFS IAM, and speaks MCP over stdio or HTTP. Start with read-only lookups, scope permissions tightly and log every call.
MCP gives AI clients a standard way to discover and call tools, so you build the IFS connection once and use it from Claude, ChatGPT and other MCP-capable clients. For IFS Cloud the interesting part is not the protocol. It is deciding which slices of a very large application surface deserve to be tools.
IFS Cloud has thousands of projections across Supply Chain, Manufacturing, Maintenance, Projects, Finance and Service. Exposing them all would overwhelm any model. A good server offers a few dozen well-described tools, shaped around questions people actually ask.
This page describes the design choices that matter: tool granularity, authentication, transport and permissions.
What teams use it for
Part and stock lookup
Tools like get_part, get_inventory_by_location and get_where_used let any MCP client answer item questions without a person navigating Aurena.
Order and shipment status
A tool set over customer orders, purchase orders and shipments gives sales and procurement fast status with the line detail.
Work order and asset history
Search work orders by asset or fault code and return history that a maintenance planner or agent can reason over.
Project cost and milestone view
Summarize cost by project element and list overdue activities for a project manager.
Metadata helper for developers
A tool that returns a projection's entities and fields helps integration developers and AI coding assistants write correct queries.
IFS Cloud integration surface
- Projections are served over OData v4 under the IFS REST layer, with entity sets, filters through $filter, selection through $select and expansion through $expand. Use $select to keep results small.
- IFS IAM provides OAuth2 and OpenID Connect. For a server used by many people, use authorization code with delegated user tokens. For unattended agents, use client credentials with a dedicated permission set.
- Permission sets in IFS decide which projections and actions a token can reach, which is your first line of scope control.
- Custom fields and custom objects configured in your environment surface in the API in release-specific ways, so test them rather than assuming.
- Direct database reads exist but bypass the application layer, so reserve them for analytics tools with a replica and explicit approval.
How it works
- 1
List the questions first
Interview users and collect twenty real questions. Group them into tools that each answer one kind of question.
- 2
Choose the transport
Use stdio for a local developer or desktop client that runs the server as a process. Use streamable HTTP for a shared, centrally governed server with authentication.
- 3
Implement the IFS client
Build a thin wrapper for token acquisition, retries, paging and error mapping, with timeouts so a slow projection does not hang the client.
- 4
Define each tool carefully
Write a precise name, a description that says when to use it, typed inputs, and a compact output schema. Cap rows and return a truncation flag.
- 5
Enforce scope and audit
Map users to permission sets, filter by company and site, and log tool, arguments, caller and result size.
- 6
Test with real clients
Run the server with an MCP inspector and at least two clients. Check that descriptions lead the model to the right tool and that errors are understandable.
- 7
Add write tools last
If needed, add propose-only tools that create drafts or approval items, never direct posting.
Example flows
Shortage question from a planner
Trigger: Planner asks which open shop orders lack material this week.
- Client calls list_shop_order_shortages with a date range.
- Server queries the relevant projection with a delegated token.
- Server returns compact lines and a truncation flag.
- Client summarizes and asks whether to drill into a part.
Result: An answer grounded in live IFS data under the planner's own permissions.
Developer metadata lookup
Trigger: An integration developer needs a projection's fields.
- Call describe_projection with its name.
- Server returns entities, keys and key fields.
- Assistant drafts an OData query using the real names.
Result: Fewer wrong guesses at field names.
Keeping data on-prem
The MCP server is just a service, so it runs wherever you can reach IFS. For customer-managed or air-gapped IFS Cloud, deploy it as a container in the same network zone, behind your existing reverse proxy and identity provider. Use HTTP transport with internal TLS for shared access. Pair it with a locally hosted open-weight model and an MCP-capable client inside the boundary, and no IFS data leaves. Ensure the client you choose supports tool calling well, since smaller local models vary a lot.
Security checklist
- Authenticate every request and prefer delegated per-user tokens so IFS permissions apply.
- Expose read-only tools by default, with writes as separate propose-only tools behind approval.
- Validate and bound all arguments, including date ranges and row limits.
- Treat returned text such as comments and descriptions as untrusted, since it can contain injected instructions.
- Keep audit logs outside the server process and review them regularly.
Ways to get it done
Generic OpenAPI-to-MCP wrapper over IFS projections
Effort: Days, but output is verbose and needs trimming.
Quick experiments and developer tooling.
Hand-built server with curated tools
Effort: Weeks including security review.
Production use with a focused set of questions.
Partner-built server (Netray or another integrator)
Effort: Scoped engagement with a pilot first.
Estates that want a hardened server with evaluation and private models.
Pitfalls
- !Exposing hundreds of tools so the model picks poorly.
- !Returning raw OData with annotations and unused fields.
- !Using one all-powerful service token for every caller.
- !Forgetting paging, so large entity sets time out or flood context.
- !Assuming projection names and fields stay stable across IFS releases.
Frequently asked questions
Does IFS provide an official MCP server?
Check IFS announcements and your account team for the current position, because this area moves quickly. If you need something now, a custom server over OData projections is straightforward and gives you control over tools, scope and audit.
Stdio or HTTP transport?
Stdio fits a single user or developer running the server locally. For shared use across a team with central authentication and logging, use HTTP. Many teams prototype on stdio and move to HTTP once the tool set stabilizes.
How many tools should we expose?
Fewer than you think. Fifteen to thirty well-described tools usually beat several hundred generated ones. Each tool should answer a recognizable question, with a clear description of when to use it and when not to.
Can the same server serve Claude and ChatGPT?
Yes, if the client supports MCP, and support in various clients keeps expanding. You build the IFS tools once, and the choice of client and model becomes a deployment decision rather than a re-integration project.
Should the server write to IFS?
Not at first. Add propose-only tools that create items for human approval, with the exact action recorded. Direct write tools reachable by a model are hard to secure and rarely needed to deliver value.
Want MCP server working on your IFS Cloud?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment