Connecting CRM, ERP and agents: what a standard connector layer changes

Most business automation work is plumbing: a customer record in the CRM must match the order in the ERP, an approval must reach the right person, and a notification must fire when something changes. Adding an AI agent to that picture creates a new integration problem, because the agent needs access to many systems, and each connection has its own credentials, error handling and audit needs. The Model Context Protocol (MCP) is the open standard that has emerged for that connector layer. This post reads the specification revision dated 2025-11-25, the current revision at the time of writing, as an integration brief: what it standardizes, what it leaves to you, and which parts matter for CRM and ERP work.

What the connector layer standardizes

Before a shared protocol, connecting an assistant to a CRM, a ticketing system and a spreadsheet meant three custom adapters, each with its own way of describing capabilities. An MCP server presents a system's operations as named tools with typed inputs, and any compliant client can discover and call them. For a business, the practical benefit is that the same connector can serve more than one assistant or workflow tool, and the connector can be reviewed once.

That is the easy half. The harder half is who the call is made on behalf of, and what happens when it takes minutes instead of milliseconds.

Authorization: the part to read carefully

MCP authorization is optional, but when it is supported over an HTTP-based transport the specification says implementations should conform to it ^[2]. It builds on OAuth 2.1 and related standards: the MCP server acts as a resource server, the client acts as an OAuth client, and a separate authorization server issues tokens ^[2]. Several requirements matter directly for an ERP or CRM connection:

• Tokens are bound to one server. Clients must include a resource parameter naming the MCP server they intend to use, and servers must validate that a token was issued specifically for them. Servers must not accept tokens meant for other resources, and must not pass a received token through to downstream services ^[2].

• Least privilege is the stated default. Clients should request only the scopes they need, and servers can return an insufficient-scope response that triggers a step-up request for additional permissions ^[2]. The 2025-11-25 revision added incremental scope consent for exactly this flow ^[1].

• Client identity. The revision added OAuth Client ID Metadata Documents as a recommended way for clients to identify themselves when they have no prior relationship with a server ^[1][2].

• Short-lived credentials. Authorization servers should issue short-lived access tokens, and for public clients must rotate refresh tokens ^[2].

The specification also warns about a confused-deputy problem, in which an MCP server acting as a proxy to a third-party API could be tricked into obtaining tokens without user consent ^[2]. In practice this is why a connector to a system of record should be treated as security-sensitive code, not a convenience script.

Long-running work

ERP operations such as posting a batch, reconciling a ledger or generating a report rarely finish in one request. The 2025-11-25 revision added experimental support for tasks, which track durable requests with polling and deferred result retrieval ^[1]. It is explicitly experimental, so a production design should assume the pattern may change, and should keep its own job records for anything that matters.

Other changes in the same revision are smaller but practical: input validation errors should be returned as tool execution errors rather than protocol errors so a model can correct itself, and servers must respond with HTTP 403 for invalid Origin headers on the HTTP transport ^[1].

The last row is the important one. The protocol standardizes the call, not the record of it.

Where this fits in a workflow

A well-run automation connects systems with a mix of deterministic and agent-driven steps. Trigger-based automations, such as a closed deal creating an ERP order, are better as plain workflows with webhooks or REST calls: they are predictable and cheap. An agent adds value where the input is unstructured, for example reading an inbound email and deciding which system to update. A connector layer such as MCP sits between the two, giving the agent a bounded set of operations while the surrounding workflow handles approvals and notifications.

Sinthetix builds this kind of integration work as part of its Business Automation service: CRM and ERP integration with bidirectional sync, trigger-based workflow automation, custom connectors over REST, webhooks or middleware, and multi-step approval workflows with audit trails.

Why this matters now

Agent platforms are shipping their own governance tooling. At Computex on June 1, Nvidia introduced an Agent Toolkit and an OpenShell runtime that provide sandboxing and centralized policy enforcement for autonomous agents ^[3]. These are the same concerns the authorization and audit rows in the table above address.

For any integration where an agent can write to a system of record, define the narrowest permission set first, log every call, and require approval for irreversible actions; the protocol makes that easier to implement but does not do it for you. Talk to us: sales@sinthetix.com