Skip to main content
Twinbay runs a hosted MCP server at https://mcp.twinbay.ai/mcp. Add it to any MCP client and your agent can find a twin, get a sandbox of it, point the code under test at that sandbox, and read back what the code sent. Transport: Streamable HTTP. Auth: OAuth through WorkOS AuthKit, so the client signs the user in and no API key goes into a config file.

Connect

The first call opens a browser for sign-in. After that the client holds a token bound to this server, which cannot be replayed against Twinbay’s other APIs. Any client speaking MCP can connect. Twinbay keeps no allowlist: a client publishes a Client ID Metadata Document or registers itself dynamically, and neither path needs anything from us.

Tools

The tools are the API’s own twin and sandbox routes, generated from the OpenAPI spec, so each one behaves like the endpoint it comes from. The API Reference tab documents them. Organizations, users and API keys stay out. An agent works inside the organization the signed-in member belongs to, and every tool scopes its queries the same way an HTTP request does, so it cannot read another organization’s sandboxes.

What an agent does with them

Two habits keep an agent out of trouble. Collect a credential once, because a second call is refused. Read a not modelled refusal as the edge of a twin rather than as a bug to work around.

Prefer a key

Scripts and CI jobs should use the CLI or the API with an organization API key. The MCP server exists for interactive agents, where a user signs in.