> ## Documentation Index
> Fetch the complete documentation index at: https://docs.glood.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect any MCP client

> The Glood MCP endpoint, its transport, and how authorization works

Glood exposes one MCP endpoint. Any client that implements the Model Context
Protocol and its authorization spec can connect — there is no Glood-specific
SDK, and no key to paste.

```
https://platform.glood.ai/api/v1/mcp
```

## What your client needs to support

<Check>Streamable HTTP transport — not SSE, and no session id to carry</Check>
<Check>OAuth 2.1 authorization code flow with PKCE (`S256`)</Check>
<Check>Dynamic client registration (RFC 7591), or a client we issue by hand</Check>

That is the whole requirement. Clients that already speak MCP authorization —
Claude Code, claude.ai, ChatGPT, Codex, Gemini CLI, opencode, and anything
built on an MCP SDK — need nothing beyond the URL.

## How the connection opens

Nothing is configured in advance. Your client discovers every endpoint it needs
starting from a `401`:

<Steps>
  <Step title="Your client calls the endpoint and gets a 401">
    The response carries the pointer it needs:

    ```http theme={null}
    WWW-Authenticate: Bearer resource_metadata="https://platform.glood.ai/.well-known/oauth-protected-resource"
    ```
  </Step>

  <Step title="It reads the protected resource metadata (RFC 9728)">
    Which names Glood as the authorization server for this resource.

    Both URL forms are served — the bare path and the path-suffixed form
    (`/.well-known/oauth-protected-resource/api/v1/mcp`) — because clients
    build it both ways.
  </Step>

  <Step title="It reads the authorization server metadata (RFC 8414)">
    `/.well-known/oauth-authorization-server` gives it the authorize, token and
    registration endpoints.
  </Step>

  <Step title="It registers itself (RFC 7591)">
    Unauthenticated, and it becomes a public client. Nothing is shared in
    advance, so there is no credential to leak or to rotate.
  </Step>

  <Step title="Your browser opens the consent screen">
    Tick which organizations this connection may reach, approve, and the client
    exchanges its code for a token on its own.
  </Step>
</Steps>

## What the server advertises

|                     |                                                   |
| ------------------- | ------------------------------------------------- |
| Response types      | `code`                                            |
| Grant types         | `authorization_code`, `refresh_token`             |
| PKCE                | `S256` only — `plain` is deliberately not offered |
| Token endpoint auth | `none` — every client is a public client          |
| Bearer methods      | `header`                                          |

## Token lifetimes

|                    |                                                       |
| ------------------ | ----------------------------------------------------- |
| Access token       | 1 hour, refreshed by your client automatically        |
| Refresh token      | 30 days. Unused past that, reconnect from your client |
| Authorization code | 10 minutes                                            |

Revoking a connection from the dashboard kills every credential it holds
immediately, refresh tokens included. See
[Access and privacy](/platform/access-and-privacy#turning-it-off).

## The one exception

**ChatGPT Custom GPTs with Actions cannot do dynamic registration.** That path
alone needs a pre-registered confidential client — a client id and secret,
issued against ChatGPT's fixed redirect URI. Email
[support@glood.ai](mailto:support@glood.ai) for one; see
[Custom GPT and Actions](/platform/connect#custom-gpt-and-actions).

Every other client registers itself.

## Scope of a connection

A token is scoped to **the organizations you ticked at consent**, and carries
**your own role** in each of them. The two together are the ceiling: a tool call
that your role does not permit in that organization is refused, exactly as it
would be in the dashboard.

There is no tool that widens a connection's reach — structurally, not by
policy. See [Access and privacy](/platform/access-and-privacy).

## Self-hosted or staging

The URL is the only thing that changes. Point your client at your own API host
and discovery does the rest: the well-known documents are served from that
origin and name it as their own issuer.
