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

​
The flow at the protocol level

1

Call a connector endpoint without a token → 401

A call to e.g. https://mcp.consile.ai/gsc/mcp without a valid token returns 401 Unauthorized with WWW-Authenticate: Bearer resource_metadata="https://mcp.consile.ai/.well-known/oauth-protected-resource/gsc/mcp" and the JSON-RPC body {"jsonrpc":"2.0","error":{"code":-32001,"message":"Unauthorized: missing or invalid access token"},"id":null}.
2

Fetch the protected-resource metadata (RFC 9728)

GET the resource_metadata URL from the header. Each endpoint has its own document (the endpoint path appended to /.well-known/oauth-protected-resource), e.g.:
The document is public and cacheable for one hour. The bare /.well-known/oauth-protected-resource describes only the Concierge (/mcp).
3

OAuth 2.1 against the authorization server

Read authorization_servers[0] and fetch that server’s metadata (RFC 8414, /.well-known/oauth-authorization-server on the authorization server). mcp.consile.ai itself does not serve authorization-server metadata, so your client must support RFC 9728 discovery. Register with Dynamic Client Registration (RFC 7591) and run the authorization-code flow with PKCE. The user signs in on app.consile.ai with their Consile login (an existing portal session is reused) and approves access on a consent screen. The authorization response carries an iss parameter (RFC 9207) equal to the issuer in the authorization server’s metadata, so a client that checks it (such as mcp-remote) accepts the response. The token is bound to the organization the user is signed in to.
4

Call a connector endpoint with your token

Send Authorization: Bearer <access_token> on every call to the connector’s own URL (e.g. https://mcp.consile.ai/gsc/mcp). The token identifies your user and organization; what you can call is checked on the server on every request.
Treat the access token as opaque and do not validate it yourself. Which connector you reach is decided by the URL you call, and your access is checked on the server on every request. Access tokens are short-lived; renew them as the token response specifies.

​
Two tokens: keep them separate

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 credential. It is never handed to your client (no token passthrough).
This means your MCP token can never be used to reach the underlying data source directly. It can only call Consile’s tools on your own organization’s account.

​
What decides access

Consile does not use OAuth scopes to decide what you can call. On every tools/call, before the upstream credential is used, the server checks these things:
  1. Subscription: your organization subscribes to the connector. Subscriptions and upstream connections belong to the organization.
  2. Seat: an administrator has assigned your user to the connector under Team in the portal. The buyer gets the included first seat automatically. One seat covers all portals of that connector. See Team.
  3. Tool access for the organization: an administrator can switch any tool off for the whole organization on the connector’s page in the portal. A tool released after the organization bought the connector stays off until an administrator activates it. See Tools and new tools.
  4. Tool access for the user: on connectors with access levels (today e-conomic and Uniconta), a user set to Kun læsning can only use the read tools (28 on e-conomic, 21 on Uniconta). Consile blocks all write operations on the server for that user. Fuld adgang gives all tools (40 on e-conomic, 25 on Uniconta). On every connector, an administrator can also choose Tilpasset and pick the exact tools a user gets. All levels cost the same. A user only gets tools that pass both step 3 and step 4.
What your client sees in each situation:
  • Seat assignments, access-level changes and tool switches take effect within seconds, with no new authorization. The server sends no notifications/tools/list_changed, so call tools/list again (in chat clients: start a new conversation) to see a new subscription or a changed access level.
  • Removing a user from the team deletes the user’s seats, so their connector tool calls stop within seconds.
  • The Concierge (/mcp) is available to every signed-in user, with or without a subscription or seat.
The exact error texts are listed in Errors & limits.

​
Connectors and upstream scopes

  • Connector capability: Google Search Console, CVR, Dinero, Billy, Ordrestyring and Business Central are read-only: your AI can read your data but never modify, create or delete anything. e-conomic, Uniconta, Shopify, HubSpot CMS, HubSpot Marketing Email, Meta Ads and LinkedIn Ads expose additional write tools behind guardrails; see Write tools & guardrails.
  • Upstream scope: for Google Search Console the upstream OAuth scope is webmasters.readonly, and for Dinero dineropublicapi:read. For Meta Ads, Consile requests ads_read, ads_management, leads_retrieval, business_management and the Page permissions pages_show_list, pages_read_engagement and pages_manage_ads in one consent; declining any of them fails the connection. For LinkedIn Ads: r_ads, rw_ads, r_ads_reporting (22 LinkedIn Ads tools are not available yet; see the LinkedIn Ads reference). The HubSpot scopes are listed in the HubSpot CMS and HubSpot Marketing Email references.
  • Upstream access of read-only connectors: Billy and Ordrestyring have no OAuth scopes, and their connectors contain only read tools. Ordrestyring’s API key, issued per agreement by Ordrestyring’s support, also allows writes in Ordrestyring, but the connector only reads. Microsoft offers no read-only Business Central permission, so the consent also covers writing, but the Business Central connector only reads.
  • Uniconta has no OAuth scopes either. What its write tools can do is limited by the connector (only lines in the daily journal) and by the Server-Login User’s rights in Uniconta: read access is enough for the read tools, while creating, changing and posting journal lines needs write access to the daily journal and the right to post. An administrator can keep users on Kun læsning.
Connecting the upstream account is a separate flow that varies by connector: OAuth login (Google Search Console, Dinero, Shopify, HubSpot CMS, HubSpot Marketing Email, Meta Ads, LinkedIn Ads, Business Central), a credential or token entered in the portal (Uniconta, Billy, Ordrestyring) or hosted app approval (e-conomic). CVR needs no connect step. 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 is refreshed server-side where the provider supports it; your client never handles it. These connectors do not use a standard OAuth refresh_token:
  • e-conomic (grant token): the upstream grant token is static and does not expire, so no refresh is needed. If e-conomic rejects it, the tool error says that a reconnect is required; reconnect in the portal.
  • Uniconta (credential form): the connection uses a Uniconta Server-Login User (username and password) and a Company ID. Nothing is refreshed. The credential stops working if the password changes or the server user reaches an expiry date set in Uniconta; reconnect in the portal.
  • Billy and Ordrestyring (API token or key): the token or key you enter is not refreshed. If it is revoked or replaced, reconnect in the portal with the new one.
  • Meta Ads (OAuth): Meta issues no refresh_token. Expect to reconnect Meta Ads in the portal about every 60 days.
When a connection has expired or the provider rejects the stored access, the tool error usually says that the connector must be reconnected. This applies to every connector except CVR, which has no connection of its own. Other provider failures mostly return the generic text Tool invocation failed., so if calls keep failing, check the connector’s status in the portal and reconnect it there. See Errors & limits.