MCP Connectors

[George@DES]

Hello API Team,

We are looking into incorporating MCP servers and AI connectors into our workflows, and we run Simpro as our core job management system. A few questions if you can help:

1. Is an MCP server, or any equivalent AI/agent connector, in beta or on the roadmap? If so, how would we get access?
2. Is a sandbox or build company available to develop and test against without touching live data?
3. Are API requests subject to the authenticating user's security group permissions? If not, is there any way to issue a token restricted to read-only, or to a subset of endpoints? The documentation states the scope parameter is unused and tokens return scope: null. (Or an easier approach I have missed.)

We only need read access at this stage, and would rather not build this out ourselves if something already exists.

Thank you for your help.

[@jAkaria]

Hi George,

I saw your post about connecting Simpro to MCP/AI workflows, especially the requirement for read-only access.

I’ve actually put together a small proof of concept for this use case. It exposes Simpro-style jobs, customers, schedules and invoice data through read-only MCP tools, with the integration layer intentionally restricted to GET operations.

I’m currently testing it with representative data since I don’t have access to a Simpro sandbox.

If this is close to what you’re looking for, I’d be happy to show you the POC and, if you have a sandbox/build company available, connect it to that for a no-cost initial test.

If it works for your workflow, we can then discuss taking it further.

Happy to send over a short demo first.

[SimproAPITeam]

Hi, thanks for the detailed questions — happy to help.

1. MCP server / AI-agent connector
We don't have a published MCP server or equivalent AI/agent connector available today. I can't speak to roadmap timing from here, so for visibility (and to add your vote/use case) please submit this via the product portal: https://helpguide.simprogroup.com/artic ... uct-portal. In the meantime, any AI/agent workflow would need to be built against the existing REST API.

2. Sandbox / build company
This is best set up through your account manager or our support team rather than something configured via the API — they can advise on provisioning a separate build/test company so you're not developing against live data. I'd suggest raising this via the helpdesk: https://helpdesk.simprogroup.com/

3. Security group permissions and token scope
You've read this correctly. API requests authenticate as the employee tied to the token, but that employee's assigned security group does not currently restrict what the token can access via the API — an API token effectively has full access within the company(ies) it's connected to. The scope parameter is accepted on the token request but isn't currently used to restrict access, which is why you're seeing scope: null — that's expected behavior, not a bug.

There currently isn't a native way to issue a read-only or endpoint-limited token. Since you only need read access at this stage, a couple of practical options in the meantime:
- Put a lightweight proxy/gateway in front of your integration that only forwards GET requests to the simPRO API, giving you an enforced read-only boundary on your side.
- Use a dedicated integration login/employee (rather than a real staff member's credentials) for the token, so at minimum you can audit and revoke access independently of any individual's account — note this won't limit what the token can do, just isolates it from other users.

Since there's no existing mechanism for scoped/read-only tokens, I'd also encourage submitting this as a feature request via the product portal (same link as above) so it can be tracked and prioritized — restricting API tokens to read-only or a defined endpoint set is a reasonable ask, particularly for AI/agent use cases like yours.

Let us know if you'd like help with anything else as you scope this out.

[MatthewG]

3. Security group permissions and token scope
You've read this correctly. API requests authenticate as the employee tied to the token, but that employee's assigned security group does not currently restrict what the token can access via the API — an API token effectively has full access within the company(ies) it's connected to. The scope parameter is accepted on the token request but isn't currently used to restrict access, which is why you're seeing scope: null — that's expected behavior, not a bug.

Are you joking!? The scope parameter is used to gate access for the issued token, not the underlying user account.

If the API does not care about endpoint authorisation after authentication thats a massive security implication that is not documented anywhere. This is not normal behaivour and contrary to nearly every other API in existance.

Can you please confirm that Authorisation code and Resource owner Oauth tokens are full access to the API and are not gated at all by the users underlying permissions.