· By Milton Yan
Original series: December 18–28, 2025 · Adapted for this blog on September 9, 2026
MCP Gateway: from local tools to real users
Why we built a shared layer for MCP authentication, consent, metering, and billing—and why the work around a tool matters as much as connecting it.
Original artwork from the December 2025 MCP Gateway series.
In December 2025, we shared a series of posts about a problem we kept running into at CoreSpeed. Building an MCP server was only the beginning. Once other people wanted to use it, the work quickly expanded into authentication, permissions, consent screens, usage tracking, and payments.
That was the reason we built MCP Gateway: to give MCP servers a shared entry point for the infrastructure around the tool, so developers could spend more time on what their tool actually did.
The work that starts after the demo
A local demo can answer a narrow question: can an agent call this tool? Opening it to users raises a different set of questions. Who is making the request? What have they authorized? How much usage should be allowed? If the tool costs money to run, how will that usage be paid for?
Our December 18 introduction described the gateway as a single front door covering authentication and policy, routing and rate limits, metering and billing, and logs and metrics. Those pieces belong together because they describe the same request from different angles.
A tool call needs a route to the right server. Access needs to follow the user’s permissions. Usage needs to be attributed to an account. And when something fails, the developer needs enough information to understand where it happened.
Handle the shared infrastructure once
By December 24, one question kept coming up: after integrating with the gateway, did developers still need to build their own OAuth flow?
The answer we gave was that the gateway was there to take on that shared work. The architecture we published showed an MCP client obtaining authorization through the CoreSpeed auth server, then making requests through MCP Gateway. The gateway handled token validation and the proxy and billing path to the MCP server.
For me, this was the useful division of work: developers focus on their server’s behavior, while the common access and usage infrastructure lives in one layer. Rebuilding those pieces for every new server makes each tool a larger project than it needs to be.
Connect payments to access
Our December 25 post made the payment thesis explicit. We wanted to connect established authorization and payment infrastructure—OAuth and Stripe—so that paid access could be enforced as part of the connection flow.
The flow we described used OAuth 2.1 with payment verification at consent. For paid access, a missing payment method prevented token issuance. An HTTP 402 response supplied a checkout link so the user had a next step. Once access was granted, requests were metered and attributed, with developer compensation tied to calls.
The design connected three things that have to agree: permission to use a tool, the account responsible for usage, and the record of what was consumed. Our argument was that this could be built on familiar infrastructure. The post acknowledged the vision behind x402 while explaining why we were pursuing that approach.
Make consent understandable
The last post in the series, on December 28, returned to the user experience. Authentication alone does not tell someone what they are agreeing to. A useful consent screen needs to make permissions and costs visible before access is granted.
The screen we shared named the client and MCP server, listed the requested permissions, and displayed a per-request price alongside the usage-based billing permission. It brought the commercial terms into the same decision as granting access.
This was the thread connecting all four announcements: help developers make their tools available through a consistent access path, and help users understand the permissions and costs attached to that access.
The tool is where a developer’s idea becomes useful. The infrastructure around it is what lets other people start using it with a clear agreement about access and usage. That was the motivation behind MCP Gateway.
Original posts
This article combines our December 18–28, 2025 posts and reflects the product and architecture described at that time. It was adapted for this blog on September 9, 2026.