AdlyseAdlyseMCP Docs
⌘K
Overview
adlyse-insights
list_ad_accountsget_dashboard_snapshotget_impact_analysislist_guidelinesget_guideline
adlyse-reports
list_report_templateslist_reportsget_reportgenerate_reportlist_report_targets
adlyse-ads
list_campaignsget_performancelist_adsget_ad_performancelist_change_eventsupdate_campaign_statusupdate_campaign_budget
adlyse-workflows
list_workflowsget_workflowrun_workflowget_run_status
  1. Overview
authentication

Authentication

Every request to an Adlyse MCP server must include an Authorization: Bearer <token> header. Two token types are supported and behave identically at the protocol layer.

API keys#

Create one from Admin → API Keys. Keys start with mii_prod_ and are scoped to your organization — whatever the key can do, the holder of the key can do against your workspace’s data.

plaintext
Authorization: Bearer mii_prod_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

See API Keys for the full lifecycle — creation, revocation, rotation, and the audit trail.

OAuth#

Adlyse runs a full OAuth 2.1 authorization server (with RFC 7591 dynamic client registration), and tokens it issues start with mf_oauth_ scoped to the signing user’s organization. The validation layer accepts these identically to API keys.

OAuth-capable MCP clients can discover and log into Adlyse automatically — no API key to copy, and tokens refresh on their own. The MCP host advertises its authorization server at https://mcp.adlyse.com/.well-known/oauth-protected-resource (RFC 9728) and answers an unauthenticated request with a 401 + WWW-Authenticate challenge, which is what triggers the client’s login flow. Point a client such as Claude Desktop’s “Add custom connector” at an MCP endpoint, leave the OAuth client fields blank (the server self-registers via dynamic client registration), and complete the browser consent.

Choose based on your client:

  • OAuth — best for interactive desktop clients (Claude Desktop, claude.ai). Auto-refreshing, no long-lived secret stored.
  • API keys — best for Claude Code and headless/automation contexts where there’s no browser to complete consent. See the Quick start for both setups.

Scoping#

Tokens today carry full org-level access. Per-resource scoping (e.g. “read-only”, “reports only”) is on the roadmap. Until it ships, issue separate API keys per integration so you can revoke any one without affecting others.

Errors#

A missing, malformed, or revoked token returns a structured error rather than a protocol-level failure:

json
{ "error": "Invalid or inactive API key", "error_type": "auth_error" }

Rotate the key from Admin → API Keys and retry.