DoorDash wraps MCP tool calls in one gateway for permissions, credentials and audit

As ByteByteGo describes it, MCP gives an agent two calls. The agent application's MCP client sends tools/list to a server and gets back a catalog with each tool's name, description and expected inputs ^[6][4]. It then sends tools/call with a tool name and arguments, and the server runs it ^[5]. The application hands the result back to the model, which decides what to do next ^[15].

I'd map the gateway's five jobs onto those two calls ^[1]. At discovery, the gateway chooses which tools an agent can see, so the model only ever reasons over a filtered catalog ^[2]. At execution, it checks permission, supplies credentials, forwards the request and records what happened ^[2]. ByteByteGo's outline treats discovery and execution as the two phases the gateway handles ^[11].

The pressure to centralise comes from the tool mix. DoorDash's tools come from internal services, engineering systems, documentation platforms and third-party software ^[7]. Some only read. Others update tickets or open pull requests ^[8]. The account's case for MCP is that without a shared interface, each agent application has to handle every tool's own API ^[14]. I think the same case applies one layer up. Leave permissions and credentials to each agent and every team writes its own token handling for every third-party system. Audit logging is the dullest of the five jobs right up until someone needs to know which agent closed a ticket.

The design choice I'd single out as good engineering is the split between identifying the caller and supplying credentials. The account treats these as separate problems ^[9]. Knowing that a request comes from a given agent acting for a given employee is one question. Holding a token that a downstream system will accept for that employee is another. In my view, keeping them apart means the gateway can refuse a call before it touches a secret. The account also covers a user connecting an account in the middle of a tool call ^[10]. If that works the way the section heading suggests, the gateway has to hold or retry the call while the user links the account.

ByteByteGo says its post is assembled from publicly shared details ^[13]. The text does not say how permissions are expressed, how many agents or tools sit behind the gateway, or how much latency the extra hop adds. So the case for copying it rests on your shape matching DoorDash's: many agents sharing many tools with different owners ^[7]. A team running one agent against three internal tools pays for the extra hop and a shared service while having little to centralise. DoorDash seems to have treated that cost as a problem in its own right. The account gives a full section to how the company made the platform easy to adopt ^[12].