Picture your Tuesday. An agent you run in a cloud sandbox has been investigating a mobile app problem. It starts a session, calls a CLI, hits an auth wall, and you sign in again. Then the VM rotates, the token disappears with it, and the next session asks you to sign in once more. You have a CLI that works fine on your laptop and a lot of friction everywhere else.
That is the situation behind a post on APIs.io about bitdrift, an observability company. bitdrift's Snow Pettersen wrote up why the company added a remote MCP server after it had already shipped a public API, a bd CLI and agent skills. The reason, the post says, is not the one usually given.
You have probably heard the usual objection to MCP: token cost. The post notes that tool search and code mode have narrowed that. What decided it for bitdrift was auth. A CLI in an ephemeral cloud sandbox has to re-authenticate every session, and the token vanishes when the VM rotates. With MCP, in the words the post quotes, "the authentication context is lifted out of the session and handled by the harness." So you sign in once, and the sandbox stops being your problem. bitdrift supports both Client ID Metadata Documents, now the recommended registration path, and Dynamic Client Registration for clients that have not moved over.
The engineering detail is where the post is most useful to you if you build APIs yourself, and the post says none of it is a marketing number. Tools are generated from annotations on the same Protobuf definitions that produce the public API and the CLI. Those annotations include read-only, destructive and idempotent hints, so one set of protos feeds both front doors. The 2026-07-28 stateless spec let the team mount MCP routes on the existing API server, with one tool call mapping to one RPC.
The hardest lesson is about size. Exported as-is, the Workflow API's create schema came to 32k tokens. So the tools grew options for asking for less: field selection on logs and spans, and summary data instead of full chart series. The team notes this makes the MCP surface feel more like GraphQL. The line you may want to keep: "For an agent, asking for less is the whole point."
Now the turn. APIs.io also keeps a record on bitdrift, and the post checks the company's story against it. The record agrees with the architecture: a schema-first protobuf API over gRPC, Connect and gRPC-over-JSON, operated through a web portal and the bd CLI, catalogued as a single bitdrift Public API page. That page is what the post says both the CLI and the MCP server are re-exports of, which is why the catalog files it as one page and not three.
The scores are less flattering. The Kin Score is 58.6, rated strong, carried by access clarity at 81.6 and developer ergonomics at 78.6, with contract governance at 18.2. Agent Readiness is 26.3, agent-aware. Agent skills, auth clarity, error semantics and the event surface are lit. Four checks are not: mcp_server, dynamic_client_registration, protected_resource_metadata and idempotency. Every one of those, the post says, bitdrift now ships, and idempotency is literally an annotation on each tool.
So the catalog is marking bitdrift down for things the company says it built. The post does not hide that, and it does not blame bitdrift. The record was scored on 2026-11-06, nine days after the post, and the probes have not found mcp.bitdrift.io. The post leaves the fix to the next rescore.
What you take away is twofold. If you run agents in disposable environments, auth is the argument for MCP worth weighing, more than token counts. If you publish an API, building the server is only half the job. The gap between what bitdrift built and what an outside agent can find is, in the post's words, the measurement worth watching. If your own server cannot be found, your own record will say you do not have one.
Read the original: https://apis.io/2026/11/11/bitdrift-moved-auth-out-of-the-sandbox-and-into-mcp/