Skip to main content
Use this when you are building the client rather than configuring one: your own MCP client, an agent platform that connects on behalf of its users, or any application that should spend a user’s Goro balance rather than your own. The authorisation server is at https://mcp.usegoro.ai, and the resource it issues tokens for is the MCP endpoint at https://mcp.usegoro.ai/mcp.
OAuth access tokens authenticate the MCP endpoint only. The /v1 HTTP API takes goro_live_ API keys and nothing else. If you want the HTTP API, you want the Skill quickstart.

1. Read the metadata

Both documents are public and need no credentials.
https://mcp.usegoro.ai/.well-known/oauth-protected-resource describes the resource itself: which authorisation server protects it, the same two scopes, and that bearer tokens go in the header. An unauthenticated request to /mcp answers 401 with a WWW-Authenticate header pointing at that document, which is how a client discovers all of this without being told.

2. Register a client

Dynamic client registration is open, per RFC 7591. There is no client secret: Goro issues public clients and PKCE is the proof of possession.
redirect_uris must be a non-empty array of http or https URIs. Anything else answers 400 invalid_client_metadata. Register once and store the client_id. This endpoint is rate limited per IP, 10 per minute and 50 per day, so do not register on every connection.

3. Send the user to authorise

Generate a PKCE verifier and its S256 challenge, then redirect the user to the authorisation endpoint.
The user lands on Goro’s consent screen, where they approve the connection with their goro_live_ API key. That key is what binds the grant to their workspace and balance. On approval Goro redirects to your redirect_uri with code and your state. Errors that happen after the redirect URI has been validated come back the same way, as error and error_description on the query string. Errors before that point, an unknown client_id or a redirect URI that does not match, answer directly as JSON and never redirect. Authorisation codes are single use and live for 10 minutes.

4. Exchange the code

All four fields are required on this grant. A missing one answers 400 invalid_request.

5. Refresh

Both fields are required. You get a new pair back, and the refresh token you sent is retired.
Replaying a burned authorisation code, or a refresh token that has already been rotated, revokes the entire family of tokens descended from that authorisation. This is deliberate: a replay means the token leaked, and the safe response is to end the session. Store the newest refresh token and never retry an old one.

6. Call the MCP endpoint

You get the six tools described in the MCP quickstart. POST carries every JSON-RPC message, and DELETE is accepted for clients that send it. GET answers 405: this server offers no server-sent event stream, and conforming clients treat that as “no stream” and carry on. An expired or revoked token answers 401 with a WWW-Authenticate header, at which point refresh and retry. Scope is enforced per tool. Calling run_tool with a token that only carries tools:read answers a forbidden tool error naming the missing scope.

Error shapes

The OAuth endpoints answer {"error": ..., "error_description": ...}, per RFC 6749, which is a different shape from the {"code", "message"} used everywhere else in Goro.

What the tools do

The six tools your token unlocks.