Skip to main content
Consile follows MCP’s standard authorization. An MCP-aware client does all of this automatically; here’s the flow if you implement it yourself.

​
The flow at the protocol level

1

Call /mcp without a token → 401

A call to /mcp without a valid token responds 401 Unauthorized with a WWW-Authenticate header that points to the resource metadata document.
2

Fetch the protected-resource metadata (RFC 9728)

GET /.well-known/oauth-protected-resource returns (publicly) which authorization server belongs to this endpoint.
3

OAuth 2.1 against the authorization server

The client registers (dynamic client registration where supported), takes the user through login and consent with PKCE, and exchanges the result for an access token.
4

Call a connector endpoint with your token

Send Authorization: Bearer <access_token> on every call to the connector’s own URL (e.g. /gsc/mcp). The token determines the account and connectors.
The access token’s audience is Consile’s authorization-server project identifier (from the dynamic-client-registration flow) — not the MCP resource URL. Verify against that audience if you inspect the token yourself.

​
Two tokens — keep them separate

The most important thing to understand:

Your token → Consile

The access token your client holds authenticates you to Consile’s MCP server. It is the only token your client ever sees.

Consile's token → the data source

Access to e.g. Google is held by Consile as a separate, encrypted token. It is never handed to your client (no token passthrough).
This means your MCP token can never be used to reach Google directly — only to call Consile’s read-only tools on your own account.

​
Scopes & access

  • Read-only: all connectors are read-only. For Google Search Console the upstream scope is webmasters.readonly.
  • Subscription determines tools: tools/list returns only the tools your account is subscribed to. Buy a new connector and its tools appear with no extra setup.
  • Per-call check: your access is verified on every tools/call.
Connecting the upstream account is a separate flow that varies by connector: OAuth login (Google Search Console), an API-key form (Uniconta) or hosted app consent (e-conomic). See Forbind din konto.

​
Token renewal

Follow the expiry and refresh fields the authorization server returns at the token exchange (standard OAuth). The upstream credential Consile holds (e.g. a Google refresh token) is refreshed silently server-side where applicable — your client never handles it. Some connectors instead use a static grant token or API key with no refresh.