An MCP connector should be treated as a business boundary: an organisation needs to define which AI actions may reach business systems, who grants authority, when human confirmation is required, and how each consequence is reviewed. Technical connectivity without these decisions expands access without a clear owner. Business authority for an MCP connector therefore starts with an action catalogue, not with the connection itself.
An MCP connector can connect an AI application with tools, data, or processes. In a business setting, that capability immediately raises operational questions: can an action only retrieve data, may it prepare a proposal, may it send a document, or may it change an official ERP record?
The distinction is not semantic. Reading material availability, drafting a purchase requisition, and posting a document have different effects, decision owners, and control needs. Official ERP transactions belong to a business process, not only to an integration layer.
The source note on MCP describes a protocol change and migration. Such a change is a reason to review contracts, technical scope, responsibilities, and access governance. It does not, by itself, establish support, compatibility, or availability of an existing connector for any particular client. The relevant contract, documentation, and environment need review before work continues. The MCP specification notes, July 28 2026 are a starting point for that review.
An allowed AI action catalogue is a business list of what a connector may do. It should not be only a list of technical functions such as search or update . Each entry needs to state its business purpose, limits, and ownership.
For every action, record:
This catalogue separates the question "can the tool do it?" from the question "may the process do it?" A technically possible action without business authority does not belong in production scope.
It is useful to group actions by effect. Read-only actions may carry narrower risk, but still need a data-scope rule. Actions that create a proposal need to mark the output as a draft and identify the decision owner. Actions that change an official record or send binding communication require explicit authority, confirmation, and a reviewable consequence trail.
A signed-in user does not automatically give a connector the right to perform every action. Business authority should link three levels: the identity of a user or system, the business role, and the specific action from the catalogue.
For a change to an official record, confirmation should show at least:
Confirmation is meaningful only when the person can understand the consequence and reject the action. A click without a clear summary turns control into formality. Conversely, confirmation for every harmless action can slow work without practical benefit. Set the boundary according to effect, data sensitivity, reversibility, and business responsibility.
Responsible authority does not end with confirmation. The process needs to answer simple questions: what did the AI request, which inputs did it use, which authority was checked, what did the system execute, and what state remained afterwards?
This review does not necessarily require a full reconstruction of every internal model step. For the business process, a verifiable operational trail matters more. It can include a request identifier, the action used, the scope of affected records, the result, execution status, a rejected exception, and a link to the official transaction where one exists.
The process owner should assign responsibility for reviewing failed actions, partially completed changes, and differences between a proposal and the actual result. Without that owner, an exception remains a technical event rather than a business task.
Hypothetical scenario: procurement wants an AI assistant to find open material requirements and prepare a draft purchase requisition. The first question is not whether the assistant can retrieve ERP data. The first question is who owns the requirement data, who decides that a requisition should exist, and whether the assistant may ever send it without confirmation.
A sensible initial scope could limit the connector to reading relevant requirements and preparing a draft. The catalogue would prohibit changes to quantity, supplier, price, or status without authorised confirmation. The procurement process owner approves the operating rules. The data owner confirms the permitted record scope. The exception owner receives cases with incomplete or conflicting inputs.
An acceptance criterion does not need an invented target metric. It can be verifiable: test scenarios must show that the connector rejects an action outside the catalogue, requests confirmation for every marked change, records the decision owner, and returns an exception to the agreed work queue. This criterion tests process behaviour and does not promise a business outcome.
A protocol migration may change the connection method, identity, permissions, exchange format, or monitoring. Establish the scope of change from current technical documentation and the contractual obligations of the relevant parties. It is not sound to assume an existing connector is compatible solely because of the protocol name or an earlier implementation.
Before migration, review:
This review is not only a safeguard against technical error. It returns ownership of the connector to the business process.
Before approving an MCP connector, bring together the process owner, input-data owner, decision authority, technical connector owner, and exception owner. Then complete the following checklist:
For organisations still shaping these roles, Business process screening can help map decisions, inputs, and exceptions before technical scope is set. The practical next step is to review the existing action catalogue and connector contract scope before any migration or expansion of authority.