Connecting an assistant to one API is usually straightforward. Connecting it to a growing collection of internal systems raises a harder question: which operations should each person be able to find and run?
PayPal addresses that problem in its 8 October 2026 engineering post about the Cosmos.AI MCP platform. The company describes a hub for discovering authorised tools and routing calls to certified internal servers.
The numbers describe an internal system
PayPal reports more than 2,000 callable tools and 175 certified servers, using historical figures from May 2026. These are point-in-time figures for its internal platform, not a public payment API offering or a service guarantee.
The hub presents two operations: discovery and invocation. Discovery returns relevant tools from the caller's authorised catalogue. Invocation checks policy again before routing the chosen operation.
That distinction is useful because seeing a tool and being allowed to execute it are different stages of the request.
Carry the user's identity through the call
For a smaller team, our suggested starting point is a single, well-defined service. Consider an assistant that helps staff look up invoices. Decide whose permissions apply and how the downstream API identifies the person or approved service making the request.
A shared credential with broad access can make every user appear equally powerful. That undermines the permission model already built into the application.
Document the identity route from the signed-in person through the MCP server to the business system. A reviewer should be able to explain why this particular caller could perform this particular operation.
Keep read and write operations clear
Looking up an invoice, changing its details and issuing a refund have different consequences. Name the tools and describe their inputs so those differences are obvious to both the assistant and its operator.
Apply the appropriate access checks in the service that executes the operation. A hidden button or a filtered tool list cannot be the only control protecting a write.
For consequential operations, use the approval behaviour agreed for the application. Show the concrete record and proposed action so the person reviewing it has enough information to decide.
Make failures and decisions traceable
Keep an audit record identifying the caller, operation, target, time and result. Decide what must be excluded from logs, particularly credentials and unnecessary customer data.
Give every tool an owner who maintains its description and handles failures. An expanding catalogue becomes difficult to trust when nobody knows which team supports an operation.
PayPal's post describes one large company's implementation choices, rather than universal MCP requirements. The practical lesson for a small integration is to establish identity, permissions and records while the catalogue is still small. Adding another tool then becomes a decision you can explain.
Reporting checked on 13 October 2026. Recommendations for smaller teams are our assessment.
