> ## Documentation Index
> Fetch the complete documentation index at: https://www.quo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Connect to Quo MCP
> Connect Claude, ChatGPT, another MCP-compatible client, or a custom MCP client to Quo.
Quo MCP is a hosted remote server. You do not need to download a package, run a local process, create a Quo API key, or manage server infrastructure.
## Connection endpoint
Use the Streamable HTTP endpoint:
```text theme={null}
https://mcp.quo.com/mcp
```
Use the complete URL, including `/mcp`. `https://mcp.quo.com` on its own is not an MCP transport endpoint.
## Official Claude connector
Quo's official Claude connector is named **Quo**.
In Claude, open **Settings → Connectors**, then browse the connector directory. You can also open the [Quo connector listing](https://claude.ai/directory/connectors/quo).
Find **Quo** and choose **Connect**.
Sign in to the Quo account you want to connect and approve access. Return to Claude after authorization completes.
## Official ChatGPT connector
Quo's official ChatGPT connector is named **Quo MCP**.
In ChatGPT, open **Settings → Connectors** and browse the available connectors.
Find **Quo MCP** and choose **Connect**.
Sign in to the Quo account you want to connect and approve access. Return to ChatGPT after authorization completes.
Connector availability can depend on your AI client's plan and your organization's admin settings.
## Other MCP clients
If your client supports remote MCP servers, add the Streamable HTTP endpoint:
```text theme={null}
https://mcp.quo.com/mcp
```
Many clients accept a configuration similar to this:
```json theme={null}
{
"mcpServers": {
"quo": {
"url": "https://mcp.quo.com/mcp"
}
}
}
```
The exact property names vary by client. Some clients use `serverUrl` instead of `url`, or provide a form where you paste only the server URL. Follow your client's instructions for adding a remote Streamable HTTP server.
After saving the connection, the client should open a browser to complete OAuth authorization. If it does not, look for an **Authenticate**, **Connect**, or **Sign in** action in the client's MCP settings.
## Authentication and dynamic client registration
Quo MCP uses the OAuth 2.1 Authorization Code flow with S256 PKCE. Compatible clients can discover the OAuth endpoints and register dynamically, so most third-party client developers do not need to request a static client ID or secret from Quo.
Start discovery from the MCP resource URL. Quo publishes protected-resource and authorization-server metadata that identify the authorization, token, and registration endpoints.
If the client is not preconfigured, register it at the advertised `registration_endpoint` using [RFC 7591 dynamic client registration](https://datatracker.ietf.org/doc/html/rfc7591). Persist the returned client credentials and reuse them for future authorizations.
Generate a high-entropy code verifier and its SHA-256 challenge. Quo accepts `S256` only; the `plain` challenge method is not supported.
Open the advertised authorization endpoint with `response_type=code`, the registered redirect URI, state, and the S256 code challenge.
For a dynamically registered third-party client, Quo first shows the client-reported name and redirect host. The user then signs in to Quo and approves the connection.
Exchange the authorization code with the original verifier. Store the resulting tokens securely, save each rotated refresh token atomically, and reauthorize if the server returns `invalid_grant`.
### OAuth endpoints
| Purpose | Endpoint |
| --------------------------------------- | ------------------------------------------------------------ |
| Authorization server metadata | `https://mcp.quo.com/.well-known/oauth-authorization-server` |
| Dynamic client registration | `https://mcp.quo.com/register` |
| Authorization | `https://mcp.quo.com/authorize` |
| Token exchange, refresh, and revocation | `https://mcp.quo.com/token` |
Clients should read the discovery metadata instead of hard-coding every OAuth endpoint. The metadata is the source of truth if the server configuration changes.
### Dynamic registration requirements
* Register no more than five redirect URIs.
* Use an absolute HTTPS redirect URI. Loopback hosts such as `localhost` and `127.0.0.1` may use HTTP for local clients.
* Do not include user information or a URL fragment in a redirect URI.
* Send the exact registered redirect URI during authorization and token exchange.
* Keep `client_name` at 120 characters or fewer. Quo displays this self-reported value to the user for third-party consent.
* Public clients should use S256 PKCE and can register with `token_endpoint_auth_method` set to `none`.
A third-party client's name is self-reported and does not mean Quo has verified the client. Approve a connection only when you started it and recognize the redirect host shown on the consent page.
## Troubleshooting
### The client opens the documentation site
Confirm that the server URL includes `/mcp`. The correct Streamable HTTP endpoint is `https://mcp.quo.com/mcp`.
### The client never opens a sign-in window
Confirm that the client supports OAuth for remote MCP servers. Then look for an **Authenticate** or **Connect** action in its MCP settings. Local-only clients that support only stdio cannot connect directly to the hosted endpoint.
### Authorization fails or repeatedly restarts
* Disconnect Quo in the MCP client, add it again, and complete a fresh authorization.
* For a custom client, reuse the registered `client_id`, send the exact registered redirect URI, and use S256 PKCE.
* Persist the newest refresh token after every successful refresh. A stale or revoked grant requires a new authorization.
### The wrong Quo workspace is connected
Disconnect the integration in the MCP client. In your browser, sign in to the intended Quo account and then reconnect.
## Next steps
* Review the [complete tool list](/docs/mdx/mcp/tools).
* Apply the [security best practices](/docs/mdx/mcp/security) before enabling write actions.