MCP server

POST /v1/mcp is a remote Model Context Protocol server, so Saxeo'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 saxeo \
https://www.saxeonetwork.tech/__api/v1/mcp \
--header "authorization: Bearer $SAXEO_API_KEY"

Tools

Tool	What it does
`sable_chat`	What it doesRun a completion. Takes `prompt`, optional `model`, `system`, `privacy_tier`, `max_tokens`.
`sable_run_code`	What it doesExecute `code` in a metered sandbox. `language`, `timeout_secs`, `network` optional.
`sable_verify_receipt`	What it doesVerify a `receipt` + `signature` pair and recover the signer.
`sable_attestation`	What it doesCurrent confidential-tier attestation status and measurement.
`sable_balance`	What it doesRemaining credit on the account behind this key.
`sable_models`	What it doesCatalog 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

Two ways in, both ending at the same place: a sk-sable_… key.

Paste a key

Clients that let you set a header (Claude Code, custom agents, anything driving an MCP SDK directly) send an API key you minted in the portal:

authorization: Bearer sk-sable_...

One-click connect (OAuth 2.1)

Connector UIs that expect to run an OAuth flow can, as of the OAuth authorization server the gateway now ships: discovery (RFC 8414 / RFC 9728), dynamic client registration (RFC 7591), PKCE S256 — mandatory, plain is refused — and rotating refresh tokens.

Point the client at the MCP URL and let it do the dance:

{
"type": "url",
"url": "https://www.saxeonetwork.tech/__api/v1/mcp",
"name": "Saxeo"
}

What happens: the client registers itself, sends you to Saxeo's consent page, you sign in with your wallet and choose a spend cap and an expiry, and the client receives a token.

The token it receives is an ordinary Saxeo API key, minted under your account with exactly the cap and lifetime you picked. That is the whole design: there is no second, parallel credential system to reason about — the connector's access is a key you can see on the API keys page, whose spend rolls into your usage, and revoking that key ends the connection. The client refreshes it periodically while your consent lasts; when the consent expires, it has to ask again.

An unauthenticated call to /v1/mcp answers 401 with a WWW-Authenticate header naming the resource metadata document, which is how a connector finds the authorization server without being told.

Endpoint	Purpose
`GET /.well-known/oauth-authorization-server`	PurposeAuthorization-server metadata (RFC 8414).
`GET /.well-known/oauth-protected-resource`	PurposeProtected-resource metadata (RFC 9728).
`POST /v1/oauth/register`	PurposeDynamic client registration. Public clients only.
`GET /v1/oauth/authorize`	PurposeValidates the request, then sends the browser to the consent page.
`POST /v1/oauth/token`	Purpose`authorization_code` (PKCE) and `refresh_token` grants.
`POST /v1/oauth/revoke`	PurposeRevoke a refresh or access token (RFC 7009).

Deliberate limits, stated plainly: only public clients are issued (a secret baked into a desktop app protects nothing), redirect URIs must be https or http to loopback and are matched exactly, authorization codes are single-use and live 10 minutes, and refresh tokens rotate on every use — replaying an old one is treated as a leak and revokes the whole grant, keys included.