Connect an Agent Platform with MCP OAuth Clients
Bring your CloudZero cost data into an enterprise agent platform such as Amazon Bedrock AgentCore, Google Gemini Enterprise, or Microsoft Foundry (formerly Azure AI Foundry). You register an OAuth client in CloudZero, enter its credentials in the platform's connector configuration, and everyone on that platform can query CloudZero by signing in with their own CloudZero account.
Most AI tools register themselves with the CloudZero MCP server automatically the first time you connect them, so they need no setup beyond the steps on Set Up AI Hub. Enterprise agent platforms work differently: they cannot register themselves, so they need a client ID and client secret issued in advance. An OAuth client is that pre-issued pair of credentials.
Prerequisites
- A role with the Modify MCP Settings permission set, under the MCP Settings category. View MCP Settings grants read-only access to the client list, and Delete MCP OAuth Clients is required to revoke a client. See Users and Permissions for how to assign permission sets to a role.
- An agent platform that supports the OAuth 2.0 authorization code flow with Proof Key for Code Exchange (PKCE) using the S256 method. PKCE is required in addition to the client secret.
- Administrative access to that platform, so you can enter the credentials and retrieve the callback URL (also called the redirect URI) that it uses to complete a sign-in.
Step 1: Create an OAuth client
- In CloudZero, go to Settings > Preferences & Extensions > MCP OAuth Clients.
- Select Create OAuth Client.
- Enter a Client name your users will recognize, for example
Gemini Enterprise. This name appears on the CloudZero sign-in screen when someone authorizes the platform. - Leave Redirect URIs blank. You add the platform's callback URL in Step 3 once the platform gives it to you.
- Select Create Client.
- Copy the Client ID and Client secret from the confirmation dialog and store them in your organization's secrets manager.
The client secret appears only in this dialog. CloudZero does not display it again, and there is no way to retrieve it later. If you lose it, rotate the secret to issue a new one.
Until the client has at least one redirect URI, it appears in the client list with a Setup Incomplete badge. The client is valid; no one can sign in through it until you add a redirect URI.
Step 2: Configure your agent platform
What you enter depends on whether your platform discovers the CloudZero OAuth endpoints on its own or asks you to type each one in. Check the platform's connector form: if it has fields named Token URL or Authorization URL, use both tables below.
Platforms that take a server URL
Platforms that follow the MCP authorization specification, such as Amazon Bedrock AgentCore and Google Gemini Enterprise, discover the authorization and token endpoints from the server URL. Enter these values in the platform's connector configuration for the CloudZero MCP server:
| Setting | Value |
|---|---|
| Server URL | https://czca-server.discovery.cloudzero.com/mcp |
| Client ID | The client ID from step 1 |
| Client secret | The client secret from step 1 |
Platforms that ask for individual endpoints
Platforms with a generic OAuth 2.0 connector, such as the custom OAuth option in Microsoft Foundry and custom connectors in Microsoft Power Platform, have no discovery step. Enter the server URL, client ID, and client secret from the table above, plus these values:
| Setting | Value |
|---|---|
| Authorization URL | https://czca-server.discovery.cloudzero.com/authorize |
| Token URL | https://czca-server.discovery.cloudzero.com/token |
| Refresh URL | https://czca-server.discovery.cloudzero.com/token |
| Scopes | openid profile email offline_access |
| Client authentication | Client secret in the request body (client_secret_post) |
| PKCE | Required, S256 method |
- All four scopes are required. Separate them with a single space, not a comma.
- CloudZero has no separate refresh endpoint. The Token URL handles refresh requests, so enter it in the Refresh URL field as well.
- Send the client secret in the body of the token request. CloudZero does not read credentials from an
Authorization: Basicheader, so a connector set to send them that way is rejected withinvalid_client.
The Token URL must be
https://czca-server.discovery.cloudzero.com/token. A.well-knowndiscovery URL in that field fails with405 Method Not Allowed, and the Authorization URL fails as well.
Refer to your platform's documentation for where these values go and how to retrieve its callback URL. You need that URL for the next step. For the tools this connection makes available and the permission sets they require, see MCP Server Reference.
When you share the client ID and secret with a platform administrator, use a secure channel such as your organization's secrets manager or a password manager. Do not send the secret over Slack or email in plaintext.
Step 3: Add the redirect URI to your client
- Return to Settings > Preferences & Extensions > MCP OAuth Clients.
- Find your client and select Edit from its row actions. On a client that has no redirect URIs yet, you can also select Add redirect URI directly in the Redirect URIs column.
- Enter the callback URL from your platform in the Redirect URI 1 field.
- Select Add redirect URI to register additional URLs if the platform uses more than one.
- Select Save Changes.
Redirect URIs must be absolute HTTPS URLs. CloudZero also accepts HTTP for loopback hosts (localhost, 127.0.0.1, and [::1]) so you can test locally.
What to expect
The client starts accepting authorizations as soon as you save the redirect URI. The Setup Incomplete badge clears, and the client ID and client secret stay the same, so nothing needs to change on the platform side.
Each person using the platform signs in to CloudZero once through their browser and authorizes the connection. The client name you chose in step 1 appears on that sign-in screen. From then on, their queries return the cost data their CloudZero role allows.
Manage your OAuth clients
The MCP OAuth Clients page lists every client in your organization with its name, client ID, redirect URIs, and a record of who created it, who last updated it, and when its secret was last rotated. Select a client to open its details, or use the row actions to edit, rotate, or revoke it.
Edit a client
Use Edit to change the client name or the registered redirect URIs. The client ID and client secret are unchanged, so the platform connection keeps working through the edit.
Saving replaces the entire redirect URI list with what is in the form. Every URL that should stay valid must still be listed when you select Save Changes.
Rotate the client secret
Rotating issues a new client secret and keeps the same client ID. Use it when a secret is lost or you want to cycle credentials on a schedule.
- Select Rotate secret from the client's row actions.
- Select Rotate Secret to confirm.
- Copy the new secret from the confirmation dialog. As with creation, CloudZero displays it only once.
- Enter the new secret in your platform's connector configuration.
The old secret stops working the moment you confirm, so requests from the platform fail until you enter the new one. The connection resumes as soon as you do. Redirect URIs, the client ID, and any active user sessions are untouched.
Revoke a client
Revoking removes the client permanently. Use it when a platform is decommissioned or a credential is exposed.
- Select Revoke from the client's row actions.
- Type the exact client name to confirm. Matching is case-sensitive.
- Select Revoke Client.
New sign-ins, token requests, and token refreshes stop immediately. Access tokens CloudZero already issued keep working until they expire on their own, which takes up to about two hours.
Revoking cannot be undone, and a replacement client gets a new client ID. To replace a compromised secret without taking the connection down, rotate the secret instead.
What to know
- OAuth clients do not expire. A client stays valid until you revoke it.
- The client grants no access on its own. It lets the platform start a CloudZero sign-in. Every user still authenticates individually, and their role's data access controls and permission sets apply to every query. This is the opposite of API Key Authentication, where role-based restrictions do not apply.
- Redirect URIs are matched exactly. An authorization fails if the platform's callback URL is not registered character for character. Loopback URIs are the one exception: they match on any port.
- Every change is recorded. Creating, editing, rotating, and revoking a client each write an audit event with the CloudZero user who made the change.
For failure modes and their fixes, see AI Hub Troubleshooting.
Have questions or feedback? Reach out to your account manager.
Updated about 2 hours ago

