How to build an MCP server for IFS Cloud

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. 1

   List the questions first

   Interview users and collect twenty real questions. Group them into tools that each answer one kind of question.

2. 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. 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. 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. 5

   Enforce scope and audit

   Map users to permission sets, filter by company and site, and log tool, arguments, caller and result size.

6. 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. 7

   Add write tools last

   If needed, add propose-only tools that create drafts or approval items, never direct posting.

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.