MCP server

POST /v1/mcp is a remote Model Context Protocol server, so Sable's capabilities become tools inside an agent: run a completion, execute code in a metered sandbox, verify a receipt, read the confidential attestation, check credit.

Connect

claude mcp add --transport http sable \
https://api.buildsable.com/v1/mcp \
--header "authorization: Bearer $SABLE_API_KEY"

Tools

Tool	What it does
`sable_chat`	Run a completion. Takes `prompt`, optional `model`, `system`, `privacy_tier`, `max_tokens`.
`sable_run_code`	Execute `code` in a metered sandbox. `language`, `timeout_secs`, `network` optional.
`sable_verify_receipt`	Verify a `receipt` + `signature` pair and recover the signer.
`sable_attestation`	Current confidential-tier attestation status and measurement.
`sable_balance`	Remaining credit on the account behind this key.
`sable_models`	Catalog with pricing, tier, and open-weight status.

Tool calls are metered and billed exactly like direct API calls, and both sable_chat and sable_run_code return their signed receipt in structuredContent so an agent can keep proof of what it ran.

Authentication

This server authenticates with the same sk-sable_… bearer key as the rest of the API.

The MCP specification calls for OAuth 2.1 with PKCE and dynamic client registration on public remote servers, and that is not implemented here. In practice: clients that can set an Authorization header work (Claude Code, custom agents, anything using an MCP SDK directly), and one-click connector UIs that expect to run an OAuth flow do not. Standing up an authorization server is a separate piece of work, and it's listed as outstanding rather than half-shipped.