CloudChipr · OAuth Scopes

CloudChipr OAuth Scopes

OAuth 2.0 probed

CloudChipr uses OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (e.g. client-credentials or role-based authorization) rather than per-scope consent.

This index is generated from the provider’s OpenAPI security definitions (and, where available, its documented scope reference) and refreshes on every APIs.io network build. Browse every provider’s scopes at scopes.apis.io.

AzureCloud Cost ManagementCost OptimizationFinOpsGCPMulti-CloudResource CleanupRightsizing
Scopes: 0 Flows: Method: probed

Scopes (0)

CloudChipr implements OAuth 2.0 but publishes no discrete scopes — access is governed by the grant itself (client-credentials or role-based authorization) rather than per-scope consent.

📄 Provider scope reference:

Source

OAuth Scopes

Raw ↑ 
generated: '2026-09-05'
method: probed
source: >-
  https://mcp.cloudchipr.com/.well-known/oauth-protected-resource +
  https://auth0.cloudchipr.com/.well-known/openid-configuration
summary: >-
  CloudChipr's OAuth surface is the MCP server only; the REST API is apiKey-authenticated and has
  no oauth2 securityScheme, so derive-oauth-scopes.py correctly found nothing in the spec. The
  scopes recorded here were read from the two live discovery documents, not from the contract.
  They are IDENTITY scopes, not API-permission scopes: the MCP protected-resource document
  advertises exactly openid, profile, email and offline_access. There is no read/write or
  per-resource scope vocabulary anywhere.

surfaces:
  - name: CloudChipr MCP Server
    endpoint: https://mcp.cloudchipr.com/mcp
    auth: oauth2
    resource: https://mcp.cloudchipr.com/mcp
    audience: https://api-bff.cloudchipr.com
    authorization_server: https://auth0.cloudchipr.com
    issuer: https://auth0.cloudchipr.com/
    bearer_methods_supported: [header]
  - name: CloudChipr Enterprise API
    base_url: https://api.cloudchipr.com
    auth: apiKey
    scopes: none
    note: >-
      Single `ApiKey` securityScheme (x-api-key header) applied per-operation. No oauth2 flow, no
      scope vocabulary. Authorization is coarse: the docs state API keys grant "read-only access to
      the Cloudchipr API and your cloud resources" - though the spec declares three mutating
      operations under that same scheme, which is an unresolved contradiction (see notes).

scopes:
  - name: openid
    source: mcp-protected-resource
    type: identity
    description: OIDC - request an ID token identifying the CloudChipr user.
    required: true
  - name: profile
    source: mcp-protected-resource
    type: identity
    description: OIDC - basic profile claims (name, nickname, picture, updated_at).
  - name: email
    source: mcp-protected-resource
    type: identity
    description: OIDC - email and email_verified claims.
  - name: offline_access
    source: mcp-protected-resource
    type: identity
    description: Issue a refresh token so the MCP client can hold a long-lived session.

authorization_server_scopes_supported:
  source: https://auth0.cloudchipr.com/.well-known/openid-configuration
  note: >-
    The Auth0 tenant advertises the full standard OIDC claim-scope set below. This is Auth0's
    default advertisement for the tenant, NOT a CloudChipr-defined permission model - only the four
    scopes in `scopes:` above are the ones the MCP resource actually declares.
  values: [openid, profile, offline_access, name, given_name, family_name, nickname, email, email_verified, picture, created_at, identities, phone, address]

authorization_model:
  style: role-based, server-side
  scope_granularity: none
  notes: >-
    Neither surface exposes a per-resource or per-action scope. What an OAuth-authenticated MCP
    session may see is decided by the user's CloudChipr role and organization membership
    ("scoped to their permissions" - https://cloudchipr.com/mcp), not by a scope granted at consent
    time. An agent therefore cannot request a reduced permission set: it gets whatever its human's
    account can see.
  agent_risk: >-
    There is no way to grant an agent read access to Billing Explorer while withholding Live
    Resources, and no way to down-scope a token below the user's own role.

unresolved:
  - issue: 'API keys are documented as read-only, but the spec declares three mutating operations under the same ApiKey scheme.'
    detail: >-
      https://docs.cloudchipr.com/docs/api-keys states "API keys provide read-only access to the
      Cloudchipr API and your cloud resources", while
      openapi/cloudchipr-enterprise-api-openapi.yml declares POST /data-sources (201 create),
      PUT /dimensions/category-structure (204) and POST /ingest/{destinationId} - all secured by
      `ApiKey: []`. Either the docs statement predates the custom-data write surface or those
      operations require an entitlement the contract does not name. Recorded, not resolved.
    checked: '2026-09-05'

Work with this as data

Every scope set here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for oauth scopes

4 MCP tools reach this
  • find_scopesBrowse and filter every scope set in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This scope set 
curl "https://apis.io/api/v1/scopes/cloudchipr-scopes"
All oauth scopes 
curl "https://apis.io/api/v1/scopes?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

GitHub Google LinkedIn

A second provider on the same verified email joins the account you already have.