Skip to main content
The MCP server uses the same credentials as the direct REST API — an API key or an OAuth 2.0 access token. There’s nothing to register or configure specifically for MCP.

​
Always send Bearer

The Model Context Protocol’s HTTP transport requires every request to carry its credential as:
This is different from the direct REST API, where an API key is normally sent with the token prefix (see API Keys) and only an OAuth 2.0 access token uses Bearer. Over MCP, always use Bearer, regardless of which kind of credential you’re sending — the server inspects the token and routes it to the verification path that recognizes it. You don’t need to know or declare which kind it is.
Both requests above are identical apart from which credential is in the header — the server tells them apart for you.

​
Permissions and rate limits

A call made through invoke_api is authenticated and authorized exactly like a direct call to the same endpoint:
  • It runs as the caller identified by the token, with that caller’s existing permissions. An operation the caller couldn’t perform through the CRM directly (or through the REST API) is refused here too, with the same error.
  • It’s subject to the same rate limits as a direct REST call to that endpoint — using MCP doesn’t grant a separate quota.
  • OAuth 2.0 access tokens are still scoped to whatever your application was granted in the Developer Portal. Calling an operation your app hasn’t been granted returns the same 403 / 200100 your app would get calling the REST API directly.

​
Credential visibility and revocation

MCP doesn’t introduce a separate credential store — an API key or OAuth token you hand to an MCP client is the same one you’d use for a direct REST call, managed the same way:
  • API keys — view, rotate, or revoke yours under Settings → Integrations → API in the Lofty CRM. There’s no separate list of “which MCP clients are using this key” — revoking the key there immediately stops every caller using it, MCP or otherwise.
  • OAuth 2.0 tokens — manage your application’s grants in the Developer Portal; revoking or expiring an access token there has the same immediate effect on MCP calls as on direct REST calls.
If an MCP client is going to hold a long-lived credential (most are configured once and left running), treat it like any other long-lived integration credential — scope it to the narrowest permissions that work, and rotate it if the client or its host ever changes hands.

​
Invalid or missing credentials

If the credential is missing, expired, or doesn’t resolve to a real user or application, invoke_api surfaces the underlying API’s own error rather than a generic MCP failure — for example:
See Error Codes for what each code means.