Because it runs as a Worker rather than a local process, connecting is a URL and an authorization, and the session pinning means a conversation keeps its state across requests. The one thing to get right before you start is the credential: this is an OAuth resource server, so it wants a token issued for the MCP resource, and the SumUp API key you already have will be rejected.
SumUp's Model Context Protocol server, running as a Cloudflare Worker at mcp.sumup.com. It is the transport between an MCP client and SumUp's APIs, so there is nothing to host and no local process to keep alive.
- A hosted endpoint your client connects to directly: /mcp speaks Streamable HTTP, and /sse remains for clients still on the legacy transport.
- Session state that survives across requests — both routes are pinned to a Durable Object within the same Worker deployment, so a multi-step conversation does not lose its place.
- Authorization discovery without manual configuration: the worker publishes protected resource metadata pointing at SumUp's authorization server, so an OAuth-capable client finds where to authenticate on its own.
- A route in for clients that do not speak the transport natively — mcp-remote bridges to the same endpoint with the token passed as a header.
An OAuth access token issued for the MCP resource — specifically a JWT issued by SumUp's authorization host and valid for the worker's resource URL, sent as `Authorization: Bearer`. A SumUp API key in the sup_sk_ form is not accepted here, which is the mistake worth avoiding up front. OAuth-capable clients discover the authorization server from the endpoint's metadata rather than needing a token configured by hand.
One command plus a key — npx -y @sumup/mcp, then supply credentials