Context.dev · OAuth Scopes

Context.dev OAuth Scopes

OAuth 2.0 searched

Context.dev publishes 2 OAuth 2.0 scopes. Scopes are the fine-grained permissions an application requests at authorization time to act against the Context.dev API on a user’s behalf.

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.

Web ScrapingBrand IntelligenceData EnrichmentAI AgentsWeb DataClassificationWebsite MonitoringCompany DataDeveloper ToolsAPIs
Scopes: 2 Flows: Method: searched

Scopes (2)

ScopeDescriptionFlows
api.read Read access to Context.dev API endpoints (brand lookup, web scrape/crawl, search, enrichment, and related read operations).
api.write Write access for mutating API operations (e.g. creating/updating/deleting monitors). Agent credentials are issued with both api.read and api.write after the claim ceremony.

📄 Provider scope reference: https://www.context.dev/auth.md

Source

OAuth Scopes

Raw ↑ 
generated: '2026-08-14'
method: searched
source: https://www.context.dev/.well-known/oauth-authorization-server, https://www.context.dev/auth.md,
  https://mcp.context.dev/.well-known/oauth-authorization-server, https://mcp.context.dev/.well-known/oauth-protected-resource/mcp
docs: https://www.context.dev/auth.md
schemes:
- name: AgentAuth
  source: well-known/contextdev-oauth-authorization-server.json
  authorization_server: https://www.context.dev
  token_endpoint: https://www.context.dev/oauth2/token
  revocation_endpoint: https://www.context.dev/oauth2/revoke
  grant_types:
  - urn:ietf:params:oauth:grant-type:jwt-bearer
  - urn:workos:agent-auth:grant-type:claim
- name: MCP OAuth (hosted MCP server)
  source: well-known/contextdev-mcp-oauth-authorization-server.json
  authorization_server: https://mcp.context.dev
  issuer: https://mcp.context.dev
  authorization_endpoint: https://mcp.context.dev/authorize
  token_endpoint: https://mcp.context.dev/token
  registration_endpoint: https://mcp.context.dev/register
  grant_types:
  - authorization_code
  - refresh_token
  response_types:
  - code
  code_challenge_methods:
  - S256
  token_endpoint_auth_methods:
  - client_secret_post
  - none
  dynamic_client_registration: true
  protected_resource: https://mcp.context.dev/mcp
  bearer_methods:
  - header
  added: '2026-08-14'
  note: Discovered 2026-08-14. This is the browser sign-in flow an MCP client uses to reach https://mcp.context.dev/mcp
    — distinct from the AgentAuth JWT-bearer/claim ceremony on www.context.dev, and distinct again from
    the static ctxt_secret_ API key. Same two scopes across all three.
scopes:
- scope: api.read
  description: Read access to Context.dev API endpoints (brand lookup, web scrape/crawl, search, enrichment,
    and related read operations).
  sources:
  - well-known/contextdev-oauth-authorization-server.json
  - well-known/contextdev-mcp-oauth-authorization-server.json
  - well-known/contextdev-mcp-oauth-protected-resource-mcp.json
  granted_by:
  - AgentAuth (www.context.dev)
  - MCP OAuth (mcp.context.dev)
- scope: api.write
  description: Write access for mutating API operations (e.g. creating/updating/deleting monitors). Agent
    credentials are issued with both api.read and api.write after the claim ceremony.
  sources:
  - well-known/contextdev-oauth-authorization-server.json
  - well-known/contextdev-mcp-oauth-authorization-server.json
  - well-known/contextdev-mcp-oauth-protected-resource-mcp.json
  granted_by:
  - AgentAuth (www.context.dev)
  - MCP OAuth (mcp.context.dev)
note: 'Context.dev exposes the SAME two scopes (api.read, api.write) through three different credential
  paths: a static ctxt_secret_ API key (no scopes attached, full key privilege), the AgentAuth JWT-bearer/claim
  ceremony on www.context.dev, and OAuth authorization_code + PKCE on mcp.context.dev for the hosted MCP
  server. The OpenAPI declares only bearerAuth (http bearer); the scope surface lives entirely in the
  well-known metadata and auth.md, so a consumer reading the spec alone would not know scopes exist. Only
  two scopes cover a 49-operation API, so the granularity is coarse — an api.write token can delete every
  monitor and every batch.'