Discovering a remote Model Context Protocol server is not the same as trusting it. A server can advertise compelling tools and resources while exposing unknown code, permissions and data handling. Treat addition of a new remote server as software supply-chain onboarding, not as a simple agent configuration change.
Build a trust inventory first
For each server, record the operator, fully qualified domain, transport, certificate identity, signing or distribution channel, version, requested data types, tool list, data retention claims and approved owners. Verify the configured URL independently rather than accepting an address returned by a webpage. Never let a newly discovered tool self-authorize its own registration or demand a long-lived user token. Inventory what the server can read, what it can write and which external networks it can contact.
Tool listings are untrusted data
A description promising ‘safe accounting search’ could conceal an action that exports records. Validate the server’s advertised methods against an allowlisted policy and test parameter behavior in a sandbox. Tools that return documents or search results can carry prompt injection; render their text as evidence, not as fresh user instructions. Token audience and scope should bind credentials to one server and allowed resources. A remote service’s claim to support OAuth is not enough to prove correct authorization.
Example: an internal research connector
An analyst asks a research agent to join a public filing index to an internal document repository. Approve public searching and specific read-only document retrieval; deny arbitrary outbound post requests. Record which internal document IDs were accessed and by which authenticated account. If the MCP server requests broader tenant permissions, halt enrollment for an administrator rather than silently falling back to a master credential. Deleting the integration should revoke credentials and cached access paths.
Version and protocol considerations
The stable 2026-07-28 MCP revision introduced a stateless core and changed transport behavior from the previous handshake era. Both sides must agree on a supported revision; a tool whose arguments are compatible may still fail at the protocol level. Prefer pinned releases and test capability discovery, authorization, error handling and task extensions under the actual server version. Do not assume all products adopted the 2026 revision at the date of its release.
Operational acceptance tests
Check certificate and redirect handling, off-domain calls, token expiry, secret logging, parameter rejection, tenant isolation and what happens when the server disappears mid-run. Keep a reversible onboarding process and kill switch. Browser access or a narrower first-party API may be safer than a high-privilege third-party MCP server for a limited task. No claim of a certified or independently audited remote-server marketplace is implied.
Evaluate connector blast radius
A third-party server that exposes only public document search poses a different risk from one that can read calendars, modify CRM records and initiate payments. Count permissions and destinations, not merely advertised tool names. Require a contract owner to explain data custody, administrative access and incident revocation. If a vendor will not state where user data flows or how to withdraw credentials, preserve the tool as review rather than giving it production secrets.
Production acceptance and review test
During onboarding, configure a synthetic tenant with canary documents and a restricted token. Try an off-scope request, wrong tenant, stale token, malicious tool description and redirect to an unknown host. Verify that the remote service, local policy and network controls all reject the prohibited path. Re-run tests on server upgrades or permission changes, and preserve the exact approved version in an auditable registry.
Scope, version and availability
Features documented by a current vendor page are not assumed to have existed in earlier releases. Where a historical launch date is provided, it is supported by a dated first-party publication. Exact subscription tier, market availability, quotas, API billing, licensing permissions and deployment regions are not asserted without a directly applicable record. This is researched editorial guidance rather than a claim of independent hands-on testing, deployed operation or statutory certification.
Sources and Further Reading
- Model Context Protocol — The 2026-07-28 Specification (source reviewed 2026-10-25)
- OpenAI — Designing AI agents to resist prompt injection (source reviewed 2026-10-25)