The Model Context Protocol specification dated 28 July 2026 provides a way to organise how AI applications connect to resources and tools. In an organisational setting, what matters to me is what happens once the connection works: what information can be read, what action can be carried out, and how do we know which user authorised it? The protocol is part of the solution, while the business rules need to be designed explicitly.
A narrow-purpose tool is easier to understand
In a concept for an applications-processing system, I would keep searching for a request separate from changing its status. The first returns information the user is permitted to see; the second requires additional checks on the user's job role and the current stage. The accepted fields should also be clearly defined, rather than exposing a general command that can change any part of the record.
A tool's name and description become useful when they reflect its real effect. A tool that prepares a draft should not send it automatically. A read tool should not quietly update the record. This separation makes technical review easier and helps the user understand what will happen when the operation is approved.
Authorisation does not pass along unchecked
The specification's security considerations stress verifying that an access token was issued for the intended server, and prohibit passing it through unchanged to other services. In practice, an assistant's connection to one service does not automatically give it open-ended authorisation for the other systems linked to it.
For each integration, I suggest documenting the user's identity, the purpose, and the scope of access. If the operation needs an external service, its relationship to the original authorisation and the way its data is protected should be reviewed. Tool descriptions and external content should also be treated as inputs that need evaluating, not as instructions that carry more authority than the application's policy.
Four cases to test before launch
- A user tries to access a request outside their job remit.
- An operation that has already been carried out is resubmitted after the connection drops.
- The status of the application changes between the draft being shown and being approved.
- The linked service fails, leaving the operation without a confirmed outcome.
These proposed cases help test what a successful demo does not reveal. It is useful for the system to record the final outcome of every attempt, and to distinguish between an operation being rejected, a connection failure, and uncertainty about whether it was carried out.
In my view, the best start for this kind of integration is a limited read tool and a clearly defined task. Once the permissions and the quality of record-keeping have been verified, adding other actions can be considered.