SchemaBounce in the MCP Registry
Connect an MCP client to the hosted SchemaBounce platform server and understand its registry identity, authentication, and workspace boundaries.
SchemaBounce exposes one hosted Model Context Protocol server for operating workspaces, data pipelines, schemas, and hosted agents. A hosted agent can also be assigned work from an external orchestrator instead of operating through this server; see Connect an Orchestrator for the Paperclip, Linear, and A2A paths.
| Field | Value |
|---|---|
| Registry name | com.schemabounce/platform |
| Remote endpoint | https://mcp.schemabounce.com/mcp |
| Transport | Streamable HTTP |
| Authentication | Browser OAuth or workspace service account |
The registry entry is metadata. MCP clients can connect directly to the remote endpoint without downloading a SchemaBounce package or running a local server.
Connect with browser OAuth
Use browser OAuth for an interactive MCP client that supports remote HTTP servers.
- Add
https://mcp.schemabounce.com/mcpas a remote Streamable HTTP server. - Start the connection in your MCP client.
- Sign in to SchemaBounce in the browser.
- Select the workspace and review the requested permissions.
- Return to the client after authorization completes.
The issued authorization is scoped to the selected workspace and approved permissions. To change workspaces, start a new authorization instead of reusing the existing session.
Connect an unattended client
Use a workspace service account for CI, a server process, or another client that cannot complete browser OAuth.
- Open Workspace Settings → Service Accounts.
- Create a service account with only the permissions the client needs.
- Exchange its client ID and secret through the SchemaBounce OAuth token endpoint.
- Send the access token as a bearer token when connecting to the MCP endpoint.
Keep the client secret in a managed secret store. Do not put it in source control or browser storage. Rotate or revoke the service account from workspace settings when the integration no longer needs access.
See Service Accounts for creation, scope, and rotation details.
Workspace and tool boundaries
- Every request is authorized against one workspace.
- Tool permissions are checked for the authenticated user or service account.
- Write, destructive, cost-incurring, and read-only behavior is declared in the tool metadata.
- Workspace-owned connected accounts remain subject to their individual agent grants.
- Audit events retain the authenticated actor and workspace context.
- Judgment-specific reads and drafts follow their own domain rules; see Managed judgments through MCP.
The hosted platform MCP operates SchemaBounce itself. External systems such as GitHub, Slack, and HubSpot are separate MCP connections that workspace owners configure and grant to agents. To connect a server that is not in the catalog, see Add a custom MCP server.
Related guides
- Hosted MCP builder guide
- MCP integration
- MCP connection ownership
- MCP connection setup
- Add a custom MCP server
- Connect an Orchestrator: let an external work system assign tasks to a hosted agent instead.
- Managed judgments through MCP: what an agent can read and draft for judgment features specifically.
Related Documentation
Continue exploring