The Hog · OAuth Scopes

The Hog OAuth Scopes

OAuth 2.0 probed

The Hog 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.

CompanyGTM IntelligenceSales IntelligenceData EnrichmentWeb ScrapingPeople DataCompany DataDeep ResearchSocial MonitoringMCPAI AgentsY Combinator
Scopes: 0 Flows: Method: probed

Scopes (0)

The Hog 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: https://docs.thehog.ai/guides/use-mcp

Source

OAuth Scopes

Raw ↑ 
generated: '2026-08-14'
method: probed
source: https://mcp.thehog.ai/.well-known/oauth-authorization-server
checked: '2026-08-14'
http_status: 200
docs: https://docs.thehog.ai/guides/use-mcp

scope_count: 7
scope_model: oauth2-authorization-code-pkce
applies_to: hosted MCP server (https://mcp.thehog.ai/mcp)

important: >-
  These are NOT REST API authorization scopes. The Hog's REST API at
  https://developer.thehog.ai is authorized with a static dual API-key header pair
  (X-Access-Key / X-Secret-Key) and declares NO oauth2 securityScheme in its
  OpenAPI -- there is no scope model on the REST surface at all, so an agent cannot
  request least-privilege access to the API itself. The scopes below govern only the
  OAuth handshake that fronts the hosted MCP server, and they are Clerk identity
  scopes (the authorization server is a Clerk tenant at clerk.thehog.ai, whose own
  service_documentation points at clerk.com/docs/oauth/scoped-access). None of them
  narrows what a connected agent may DO with The Hog data once the token is issued.

authorization_server:
  issuer: https://clerk.thehog.ai
  authorization_endpoint: https://clerk.thehog.ai/oauth/authorize
  token_endpoint: https://clerk.thehog.ai/oauth/token
  revocation_endpoint: https://clerk.thehog.ai/oauth/token/revoke
  registration_endpoint: https://clerk.thehog.ai/oauth/register
  registration_note: >-
    RFC 7591 dynamic client registration is open, which is what lets an MCP client
    connect without a pre-provisioned client_id.
  grant_types_supported: [authorization_code, refresh_token]
  response_types_supported: [code]
  code_challenge_methods_supported: [S256]
  token_endpoint_auth_methods_supported: [client_secret_basic, client_secret_post, none]
  id_token_signing_alg_values_supported: [RS256]
  jwks_uri: https://clerk.thehog.ai/.well-known/jwks.json
  claims_supported: [sub, iss, aud, exp, iat, email, name, org_id]

protected_resource:
  resource: https://mcp.thehog.ai/
  authorization_servers: [https://clerk.thehog.ai]
  authorization_data_types_supported: [oauth_scope]
  authorization_data_locations_supported: [header, body]
  source: https://mcp.thehog.ai/.well-known/oauth-protected-resource

scopes:
  - name: openid
    kind: identity
    description: OpenID Connect base scope; requests an ID token for the signed-in user.
  - name: profile
    kind: identity
    description: Basic profile claims for the signed-in user (name).
  - name: email
    kind: identity
    description: The signed-in user's email address claim.
  - name: public_metadata
    kind: identity
    description: Clerk public user metadata attached to the account.
  - name: private_metadata
    kind: identity
    description: Clerk private user metadata attached to the account.
  - name: offline_access
    kind: session
    description: >-
      Issues a refresh token so the MCP client can keep the connection alive without
      re-prompting the user.
  - name: user:org:read
    kind: organization
    description: >-
      Read the organizations the user belongs to. This is the scope that lets the MCP
      connect flow present the organization picker -- The Hog bills and rate-limits
      per organization-and-user, so the selected org determines which balance the
      agent's calls are charged against.

gaps:
  - >-
    No resource scopes. Nothing in scopes_supported distinguishes read from write,
    search from enrichment, or monitors from scrapers. An agent granted MCP access
    holds the full published tool surface for the selected organization.
  - >-
    No scope model on the REST API. The OpenAPI declares only apiKey schemes, so REST
    consumers get all-or-nothing credentials with no per-capability narrowing.
  - >-
    Spend, not scope, is the control. The published cost boundary is the customer-set
    spend cap on the pricing page, not an authorization boundary.

refs:
  authentication: authentication/the-hog-authentication.yml
  well_known: well-known/the-hog-well-known.yml
  mcp: mcp/the-hog-mcp.yml
  plans: plans/the-hog-plans-pricing.yml