What each server is, and who stands behind it#
Both entries are vendor-verified and both sit in the commerce-and-retail category, so the usual first question (is this a third-party wrapper?) is settled for both. PayPal publishes under the registry name com.paypal.mcp/mcp at version 1.0.0, describing the server as "PayPal MCP server provides access to PayPal services and operations for AI assistants". Stripe publishes under com.stripe/mcp at version 0.2.4, described as "MCP server integrating with Stripe - tools for customers, products, payments, and more." Those version strings are publisher declarations. Nothing in the record ties either number to a stability or support commitment, so 1.0.0 should not be read as the more settled of the two.
Namespace ownership is verified for both, on the same test. PayPal's evidence reads "namespace com.paypal.mcp -> paypal.com; host mcp.paypal.com is within paypal.com"; Stripe's reads "namespace com.stripe -> stripe.com; host mcp.stripe.com is within stripe.com". In each case the endpoint you would actually connect to lives inside the domain the namespace claims. That is the single most useful provenance fact on this page, and it is identical for both.
The curation scores differ: Stripe 100, PayPal 80. The components show exactly where the twenty points went. Both earn namespace.verified_domain (+50), probe.reachable (+15) and probe.spec_auth_chain (+15). Stripe adds repo.license_osi (+10, "license MIT") and repo.recent_release (+10, "release 0 days ago"). PayPal's registry record declares no repository at all, so there was nothing to license-check or date-check.
Read that gap for what it is. It measures how much of the publisher's work is externally checkable, not how capable the payments connector is and not how safe it is to point an agent at your live account. The two records are level on the scored probe components, since both earn probe.reachable and probe.spec_auth_chain. They are not level on everything we observed: the two scope claims differ, and the next section is about exactly that.
The scope lists, read literally#
This is where a feature table will mislead you. PayPal's auth.scopes resolves to supported, with the scope list captured verbatim from Protected Resource Metadata on 19 September 2026: "scopes_supported": ["openid","email","profile"]. Stripe's auth.scopes is not documented in our record, with the reason logged as never_attempted, and the probe recorded no scopes for Stripe at all.
Side by side, that reads as PayPal offering scoping and Stripe offering none. The underlying evidence supports neither half of that reading.
Take PayPal's three entries one at a time. openid, email and profile are scope names defined by OpenID Connect rather than by anything PayPal publishes in this record. There is nothing in the list that names a transaction, an invoice, a refund, a payout or a dispute, and nothing in our record maps any of the three to such an operation. So PayPal's scope list tells you which scope names the resource advertises. It does not tell you what the resulting token can do inside a PayPal account, and that second question is not answered anywhere in the data we hold.
We also tested for the thing an IT evaluator most wants, and found a documented negative rather than a gap. PayPal's auth.scope_separation resolves to unsupported, and this is an observed finding from our own probe, not a registry declaration. The evidence is explicit: "scopes_supported is [\"openid\",\"email\",\"profile\"] -- no separate read-only scope is offered". No read-only scope appears in the advertised list.
Stripe's position is different in kind, not in degree. Its auth.scope_separation is not documented, on the same never_attempted reason. That is an absence of evidence in our record. It does not mean Stripe offers no granularity, and it must not be written up as if it did. It means that if scope granularity matters to your approval, Stripe's metadata as we captured it will not answer you, and you will have to raise it with Stripe directly.
The practical consequence is the same for both, and it is the one worth carrying into a control review. Neither record lets you assert, on published evidence, that an agent holding this connection is confined to reading. For PayPal we can say that positively. For Stripe we simply cannot say it at all. Either way, a claim of "read-only access to payments" in your approval document would not be supported by what these servers publish.
The authentication chain, and the hosts it quietly touches#
Both servers were probed identically: the same user agent, the same accept: application/json, text/event-stream, and the same mcp-protocol-version: 2025-06-18 header, within the same second on 19 September 2026 (PayPal at 17:17:16.381Z, Stripe at 17:17:16.500Z). Both returned HTTP 401 to an unauthenticated initialize. Neither is an open endpoint.
Both then implement the full spec auth chain. All four compliance bits are true for each: a WWW-Authenticate challenge, Protected Resource Metadata, Authorization Server metadata, and Dynamic Client Registration. That is the cleanest result available on this dimension, and it is worth saying plainly: of the 33 published servers in this directory, 21 have Dynamic Client Registration recorded as supported, and both of these are among them. For the other twelve the claim is not documented, which is not the same as a failure.
The paths differ in ways that matter to tooling. PayPal serves its Protected Resource Metadata at a resource-suffixed path, https://mcp.paypal.com/.well-known/oauth-protected-resource/mcp; Stripe serves it at the root path, https://mcp.stripe.com/.well-known/oauth-protected-resource. A scanner or gateway hard-coded to the root form will resolve Stripe and silently miss PayPal.
The registration endpoints diverge more consequentially. PayPal's authorisation server metadata gives "registration_endpoint": "https://mcp.paypal.com/register", on the same host as the MCP endpoint. Stripe's gives "registration_endpoint": "https://access.stripe.com/mcp/oauth2/register", on a second host. If you build your egress allow-list from the MCP URL in the registry record, Stripe's dynamic client registration will fail, and the failure will look like a client bug rather than a firewall rule. Put access.stripe.com on the list before you start troubleshooting.
Credential declaration differs too. PayPal's registry record declares an Authorization header on both remotes, each marked required and secret, and secrets.declared resolves to supported with the evidence "2 credential input(s), all marked isSecret". Stripe's single remote declares an empty headers list, and secrets.declared is not documented in our record. If your onboarding tooling reads the registry record to work out which secrets to provision, PayPal gives it something to act on and Stripe does not. That is a difference in what is declared, not a finding about how either service handles credentials in practice.
Deployment: both are hosted remotes, and that settles the perimeter question#
Neither record declares a way to run the server inside your own network. Both have an empty packages list, and deploy.self_host resolves to unsupported for both with the same evidence: "no installable package declared". deploy.hosted_remote is supported for both: PayPal declares two endpoints, https://mcp.paypal.com/mcp and https://mcp.paypal.com/sse; Stripe declares one, https://mcp.stripe.com.
So the perimeter question resolves the same way for both. On the endpoints these records declare, every prompt, every tool argument and every response travels to vendor infrastructure. There is no in-VPC or on-prem variant in either record. For a CPG or foodservice business whose payments data sits inside a PCI scope or a DLP policy, the review question is therefore not "can we keep this internal" (nothing here declares that option, for either) but "what do the vendor's own commercial terms cover", and those terms are not part of this record.
One trap deserves calling out. Stripe's repo.public resolves to supported and a licence of MIT is recorded, and that reads as the more open option. It does not make the server self-hostable. deploy.self_host is still unsupported. You can read code; you cannot run the remote you would be connecting to. Treat the repository as a source-review asset, not a deployment option.
There is also a discrepancy worth reconciling before you cite source review in a control document. The registry record declares the repository as https://github.com/stripe/agent-toolkit, but the licence claim ("license: MIT") and the maintenance claim ("last push 0 days ago") were both resolved against https://github.com/stripe/ai. Two different URLs sit behind one provenance story. Confirm which repository carries the code for the hosted remote before you record that you reviewed it.
Transport is the one operational difference in the declarations. PayPal declares both streamable HTTP and SSE. Stripe declares streamable HTTP only, and transport.sse resolves to unsupported with the evidence "no sse remote declared". If a client, gateway or proxy in your stack is pinned to the older SSE transport, PayPal gives you a declared endpoint to point at and Stripe does not. Conversely, PayPal's two endpoints are two URLs to allow-list, two paths to monitor and two surfaces to review.
What neither server documents#
Four control claims are not documented for either server: audit logging, access control, data residency and retention. For both records the reason is logged as not documented. This is the part of the page most easily misread, so it is worth being blunt: these are gaps in published evidence, not findings that the controls are absent. Our record says nothing either way about what either vendor operates. What neither has done is publish it in a form attached to this MCP server, which is what an evaluator needs when the question is specifically about the connector rather than the platform.
Practically, that means four questions you will have to put to the vendor in writing rather than lift from a page: is agent activity through the MCP endpoint logged distinguishably from ordinary API traffic; can access be restricted per user or per role at the connector level; where is the data processed; and how long is it retained. On these four claims the two records are identical, so neither is further ahead than the other.
Neither exposed a tool list to our unauthenticated probe. toolNames is null for both, which is consistent with both returning 401 before initialize completes, but it has a real consequence: you cannot enumerate the operation surface before you authorise. The only inventory available up front is each publisher's prose description, and prose is not an inventory. "Access to PayPal services and operations" and "tools for customers, products, payments, and more" both leave the important question open. Plan to connect in a sandbox or test account, list the tools, and review that list before the connector reaches a production credential.
pkg.deprecated is not documented for either, which is unsurprising given that neither declares an installable package. PayPal additionally has no repository in its registry record, so licence and maintenance recency are not documented for it. Stripe's maintenance signal is concrete by contrast: last push recorded as 0 days before our check on 19 September 2026, against https://github.com/stripe/ai. That tells you the repository was active; it does not by itself tell you anything about the hosted service you would be calling.
What to do when the protocol layer will not contain the agent#
Since neither record gives you a documented read-only grant, containment has to be assembled from the three layers that are still under your control. Note that our data documents none of these three layers for either server; that is the point of the section.
The identity you authorise with. Both servers require authentication and both were observed to support OAuth, but neither record documents what a token permits once issued. Until the vendor states otherwise in writing, plan on the assumption that the connection can reach whatever the authorising account can reach. Complete the flow from a dedicated platform user rather than a personal finance-administrator login, give that user the narrowest role the payments platform offers if it offers roles at all, and record which identity was used.
The client. Decide which tools your MCP client actually exposes to the model, and require human approval on anything that moves money or mutates a record. Since the tool list was not visible to our unauthenticated probe, this step cannot be designed in advance from the directory record. It has to be done once you have connected and read the list.
The network. Allow-list precisely: mcp.paypal.com for PayPal, covering /mcp, /sse and /register; mcp.stripe.com and access.stripe.com for Stripe. Dynamic client registration is recorded as supported on both, with a registration endpoint published in each authorisation server's metadata. Decide deliberately whether your clients register themselves or you pre-register a single client. The record tells you the endpoint exists; it does not tell you what governs who may use it.
Finally, note the freshness of what you have just read. All of it rests on a single probe run at 17:17 UTC on 19 September 2026. Protected-resource metadata is served configuration and our record captures it only as at that moment, so PayPal's three-entry list and Stripe's absent one are both snapshots. Before a production approval, fetch the protected-resource metadata yourself and compare it with what is quoted here. It is one HTTP request, and it is the part of this page most likely to have moved.