Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.
“We support MCP” can be a useful answer to an integration question. It is not a complete answer to a business question. You still need to know which information the assistant can read, which actions it can take, who operates the connection and what happens when access is revoked.
The Model Context Protocol is a way for AI applications and connected services to exchange context and expose capabilities. It can reduce integration friction, but it does not remove the need to evaluate the particular server, client and application involved. A common connector shape is not a common guarantee of quality or trust.
Understand the three participants
The official MCP architecture overview describes a host, clients and servers. The host is the AI application the user interacts with. A client handles the connection to a server. The server exposes capabilities or information to that application. The protocol does not dictate how the application should use its model or manage all of the context it receives.
In a hypothetical sales assistant, the host might be the application where a salesperson requests an account briefing. One connected server exposes approved CRM lookups; another exposes document search. The assistant can use those connections to gather evidence, subject to the controls implemented around them.
This architecture does not mean the assistant has unrestricted access to either system. The useful procurement questions concern the actual capabilities exposed: can it search every customer record, only assigned accounts or only a particular report? Can it prepare a note, save it or send it externally? Those distinctions matter more than a compatibility badge.
Ask for a capability inventory
Request a list of the server’s tools and the information each returns. Read the descriptions as if they were an employee’s permission sheet. A search tool is different from a deletion tool. A broad query interface can have a larger risk surface than a narrowly scoped lookup even if both appear as a single tool.
Also ask which capabilities the client actually supports. Protocol support does not establish that every client handles every server feature in the same way. Test the exact combination you intend to deploy, including authentication, result handling and any approval experience. Keep the negotiated protocol and implementation versions in the technical record.
The OpenAI Agents SDK MCP documentation illustrates that integrations can be configured in different ways, including different server connections and approval patterns. It is an implementation reference, not evidence that a particular third-party server is safe or suitable for your data.
Trace where the connection runs
A locally launched server process and a remotely hosted service create different operational questions. For a local process, ask which files, credentials and network destinations the process can access. For a remote service, ask who operates it, where requests are handled and which subcontractors or systems receive the data.
Do not assume that “local” means no data leaves the machine. A local connector may call a remote business API. Conversely, a remote connector can be configured with narrow authority. Draw the data path and credential path separately. The place where a program runs is only one part of the trust boundary.
Identify the owner who will patch the connector, monitor failures and respond if a dependency becomes compromised. A proof-of-concept installation performed by one enthusiastic employee needs an operating plan before it becomes a shared business dependency.
Keep authorization separate from convenience
The fact that a user connected an application once should not be interpreted as permission for every future action. Determine which scopes were granted, which account they belong to and how the application checks a proposed operation. A model-generated request must remain subject to those controls.
The official MCP security guidance discusses risks including confused-deputy behavior, token handling and scope minimization. For a buyer, these translate into practical demands: credentials should be used for their intended audience, permissions should match the task and an integration should not become a shortcut around access controls.
Ask how the product behaves when a scope is insufficient. Does it clearly request a narrower additional permission, fail safely or encourage someone to grant broad access? Ask how revocation works while a task is running. The answer should describe an actual control, not just an instruction telling the assistant to be careful.
A short acceptance test beats a long feature list
- Use an authorized account to retrieve a known record and verify the returned fields.
- Attempt a record outside that account’s authority and confirm access is denied.
- Run a read-only task and verify that no write operation occurs.
- Exercise a consequential action and inspect its approval and audit trail.
- Revoke access, repeat the task and confirm that cached state does not bypass the restriction.
- Interrupt the server and check that the assistant reports the limitation accurately.
These are proposed acceptance tests, not a complete security assessment. Their value is that they turn the general claim of integration into observable behavior. Include a realistic document with irrelevant instructions as well, because retrieved information should not gain authority merely by arriving through a connector.
Buy the operating system around the protocol
MCP can make a capability easier to connect, but the purchase decision includes much more: identity, permissions, data handling, error recovery, monitoring and support. Ask the vendor to separate what the protocol provides from what its own product implements.
A useful final deliverable is a one-page integration record containing the server operator, client version, exposed capabilities, approved scopes, data destinations and revocation procedure. With that record, a team can evaluate the connection in concrete terms. Without it, “MCP support” risks becoming a reassuring phrase that conceals the questions the business most needs answered.
Sources and further reading
MCP: Architecture overview. Protocol participants and scope; versioned documentation checked October 2026.
OpenAI Agents SDK: MCP. Integration configuration and approval patterns; checked October 2026.
MCP: Security best practices. Versioned guidance on security risks and least-privilege scopes; checked October 2026.
Leave a Reply