Authorization and permissions
A connection to Cademí MCP is authorized by an administrator who signs in to Cademí and approves it. From then on, it works on one account, acts as that administrator, and can do only what that administrator can do.
Authorizing a connection
When you connect a client (Connect a client), the client opens the Cademí authorization page in your browser:
- Choose the account you want to connect.
- Sign in as an administrator of that account. The administrator needs two-factor authentication turned on: without it, the page asks for it before you can approve the connection.
- Review the request and approve it.
The browser returns to the client, and the connection is ready. You never type or paste an API key, and the client never receives one: it receives an OAuth authorization that is valid only for the Cademí MCP server.
Which account and administrator
A connection is bound to the account where you approved it and to the administrator who signed in. Every tool call works on that account and acts as that administrator. To check them, ask the assistant which account it is connected to: the answer names the account, its environment (production or sandbox), and the administrator's public ID.
To work with another account, authorize a connection with an administrator of that account.
Permissions
The connection has the permissions of the administrator who authorized it. The Cademí API checks every call, as it does for any other client, and it is the final authority: a call the administrator is not allowed to make fails with PERMISSION_DENIED, and the api_code of the error says why (Errors and limits).
Each tool description ends with the permission it requires, such as Required permission: products.read. Some operations need an extra permission only for certain inputs, and the description says so. For example, users_enrollments_update needs enrollments.update, and also enrollments.delete when it sets status to revoked. Composite tools need the permissions of the operations they read; without an optional one, the part that needs it comes back with a warning. How permissions work in the API is described in Permissions and scope.
The server may also refuse a call before it reaches the API, when it already knows that the administrator lacks a permission. That error is PERMISSION_DENIED with the missing permissions in details.missing_permissions and no api_code.
Approving changes
Every tool carries MCP annotations that describe what it does: read-only, destructive, idempotent, and whether it can send e-mails or notify external systems. Clients that support approval prompts use them to ask you before a tool changes or removes data. The descriptions of destructive tools also tell the assistant to confirm the target with you first.
The server does not ask for a second confirmation. When you approve a tool call in your client, the operation runs. Annotations help the client ask you, but they are not what protects your account: the OAuth authorization and the administrator's permissions are.
Audit trail
Every change made through the connection is recorded in the account's audit log with the administrator who authorized it and the client. To read the audit log through the API, see Audit entries in the API reference.
Credentials
A connection uses no API credential: it acts as the administrator, through a short-lived OAuth access token that the Cademí MCP server obtains for each tool call and never writes anywhere. A connection has no current credential, so credentials_current returns RESOURCE_NOT_FOUND; capabilities_get returns the permissions in effect.
The operations that return a credential secret are not available as tools, so no tool puts a credential secret in the conversation.
Removing access
A connection stops working when the administrator who authorized it is removed from the account, moved to another account, or has their access revoked. Tools then return AUTHENTICATION_REQUIRED, as they do when the authorization of a connection is no longer valid. Connect again from your client to authorize it.