---
title: Access, API keys and scopes
description: Create and manage Queue CallBack API keys in the portal, choose their scopes, and sign in from Claude or ChatGPT instead.
status: Stable
last_updated: 2026-11-05
canonical: https://queuecallback.com/docs/mcp/access
---

# Access, API keys and scopes

Claude and ChatGPT connect to the Queue CallBack MCP server by signing in with a Queue CallBack account, read-only. Every other client, and every task that changes something, uses an API key that an organization admin creates in the portal under **Settings**, **API keys**. Each API key works in one organization only, with the scopes chosen for it, and never with more rights than the admin who created it.

> For AI agents: this page is also available as Markdown at `https://queuecallback.com/docs/mcp/access.md`. The whole MCP documentation in one file: https://queuecallback.com/docs/llms-full.txt

| Fact | Value |
|---|---|
| How a client authenticates | A Queue CallBack API key in the header `Authorization: Bearer qcb_sk_...`. Claude and ChatGPT can sign in instead ([OAuth sign-in](#oauth-sign-in)) |
| Who creates API keys | Organization admins (role `org_admin`), in the portal only, at **Settings** > **API keys** |
| Key format | Starts with `qcb_sk_`, 79 characters, shown once |
| Key lifetime | 30, 60, 90, 180 or 365 days; 90 by default; no key lives forever |
| Keys per organization | At most 25 active keys (suspended keys count) |
| Request limits | 120 API requests a minute per key; at most 8 requests at a time per key at the MCP server; the organization's keys share 300 requests a minute and 4 API requests at a time ([Limits](/docs/mcp/errors#limits)) |
| Scopes | 12, listed under [Scopes](#scopes) |
| OAuth sign-in | For Claude and ChatGPT: sign in with your Queue CallBack account. Read-only, caller numbers masked, no changes ([OAuth sign-in](#oauth-sign-in)) |

The Queue CallBack MCP server does not need the Custom IVR add-on. Without it, an organization uses the server for its queues, its callbacks and the callback reports. The add-on adds the IVR flow tools and the IVR call reports.

## Roles

Only an organization admin can manage Queue CallBack API keys.

| What | Organization Admin (`org_admin`) | User (`user`) |
|---|---|---|
| Sees the **API keys** card under **Settings** | Yes | No |
| Creates, rotates and revokes API keys | Yes, with any scope the organization can grant (the three IVR scopes need the Custom IVR add-on) | No |
| Signs in from Claude or ChatGPT ([OAuth sign-in](#oauth-sign-in)) | Yes, read-only | Yes, read-only, without IVR flows (`ivr:read`) |
| Reads the IVR call reports | Yes, in an organization with the Custom IVR add-on | No |

An API key can never list, create, rotate or revoke keys.

A key follows the current role of the admin who created it. If that admin becomes a User, the key narrows to the scopes a User may hold (`reports:read`, `pii:read`, `callbacks:read`, `callbacks:write`, `callbacks:dial`, `queues:read` and `org:read`) and can no longer read IVR flows or the IVR call reports. If that admin is deactivated or leaves the organization, the key is [suspended](#automatic-suspension).

## Create an API key

An organization admin creates a Queue CallBack API key in the portal, on the **API keys** page at `https://dashboard.queuecallback.com/settings/api-keys`. Only organization admins see the page; a User does not.

1. Sign in to the portal and open **Settings**.
2. On the **API keys** card, choose **Manage API keys**.
3. Choose **Create API key**. The dialog says: "The key acts for this organization with at most your rights, and only with the scopes you choose here."
4. In **Name**, say where the key is used, for example `Claude Code - reporting` (1 to 100 characters).
5. In **Expires after**, choose 30, 60, 90, 180 or 365 days. 90 days is preselected.
6. Under **Scopes**, choose at least one scope. The form groups them as **IVR**, **Reporting**, **Callbacks**, **Queues** and **Organization**, and shows each scope's description. It starts with the read scopes that take effect in your organization already selected, without `pii:read`. The **Read only** button brings back that same set. Nothing that writes, publishes or places calls is preselected. **Clear** removes every scope. Without the Custom IVR add-on the three IVR scopes are not offered, and a note under the list says why. See [Scopes](#scopes) and [Recommended key sets](#recommended-key-sets).
7. Choose **Create key**.
8. Copy the key from the next dialog: "Copy this key now and store it somewhere safe. It will not be shown again." Choose **Copy**, store the key ([Store an API key safely](#store-an-api-key-safely)), then choose **Done**.

Queue CallBack sends no reminder before a key expires, and a key's expiry cannot be changed after it is created. Check the **Expires** column, or `api_key.expires_at` in `get_me`, and rotate the key before that date.

The **Create API key** button is off when the organization already holds 25 active or suspended keys ("This organization has 25 of 25 active keys. Revoke one to create another.") or when Queue CallBack has switched API keys off for the whole service ("API keys are turned off on this server…"). In the second case existing keys can still be revoked, but not rotated, and every request with them is refused.

The key list shows each key as `qcb_sk_...abcd` (its last 4 characters), with the columns **Name**, **Key**, **Scopes**, **Status**, **Created**, **Expires**, **Last used** and **Actions**.

## Store an API key safely

A Queue CallBack API key starts with `qcb_sk_` and is 79 characters long. Anyone who holds it can use its scopes. Queue CallBack never stores the key itself, only a keyed hash of its secret part and, for display, its last 4 characters. A lost key cannot be shown again: rotate it instead.

- Keep the key in an environment variable such as `QCB_API_KEY`, set from a secret store. Client configurations refer to the variable, never to the key.
- Send the key only as `Authorization: Bearer <key>`, never in a URL.
- Never paste the key into a chat with an AI model, a ticket, an email, or a file you commit or share.
- Use one key per client and job, so you can revoke one without breaking the others. Separate keys do not add capacity: the organization's keys share one request limit.
- Use a variable name of your own; do not reuse one another tool reads, such as a name starting `ANTHROPIC_`.

Set the variable for the current terminal. Each command prompts for the key, so it never lands in your shell history.

```bash
# bash (Linux, Git Bash)
read -rs -p "Queue CallBack API key: " QCB_API_KEY && export QCB_API_KEY && echo
```

```zsh
# zsh (the default shell on macOS)
read -rs "QCB_API_KEY?Queue CallBack API key: " && export QCB_API_KEY && echo
```

```powershell
# Windows PowerShell 5.1 or PowerShell 7
$env:QCB_API_KEY = [System.Net.NetworkCredential]::new('', (Read-Host -AsSecureString 'Queue CallBack API key')).Password
```

To keep the key across sessions, store it in the operating system's secret store (macOS, Linux) and load it when a shell starts. On Windows, the simplest option is a user environment variable:

```bash
# macOS: store the key in the login keychain (prompts for it)
security add-generic-password -a "$USER" -s queuecallback-api-key -w
# Then add this line to ~/.zshrc or ~/.bash_profile; it holds no secret
export QCB_API_KEY="$(security find-generic-password -a "$USER" -s queuecallback-api-key -w)"
```

```bash
# Linux with libsecret: store the key (prompts for it)
secret-tool store --label='Queue CallBack API key' service queuecallback-api-key
# Then add this line to ~/.bashrc; it holds no secret
export QCB_API_KEY="$(secret-tool lookup service queuecallback-api-key)"
```

```powershell
# Windows: save the key as a user environment variable (prompts for it). Windows stores it unencrypted in your user profile, where any program you run can read it. Open a new terminal afterwards.
[Environment]::SetEnvironmentVariable('QCB_API_KEY', [System.Net.NetworkCredential]::new('', (Read-Host -AsSecureString 'Queue CallBack API key')).Password, 'User')
```

After a rotation, store the new key over the old one. On macOS, run `security add-generic-password -U -a "$USER" -s queuecallback-api-key -w` (`-U` updates the existing item; without it the command fails because the item exists). On Linux, `secret-tool store` with the same attributes replaces the stored key. On Windows, run the `SetEnvironmentVariable` command again.

On a server or in CI, keep the key in the platform's secret store and expose it to the job as `QCB_API_KEY`.

Check that the variable holds a whole key without printing it. Each command prints `79`:

```bash
echo "${#QCB_API_KEY}"
```

```powershell
$env:QCB_API_KEY.Length
```

Some client commands expand the variable and save the key itself in the client's settings. [Connect a client](/docs/mcp/connect) says which, per client.

## What an API key can and cannot do

A Queue CallBack API key acts in exactly one organization: the one it was created in. No tool takes an organization id. On every request the key acts with at most the current rights of its creator, narrowed to its scopes and to the organization's settings (Custom IVR add-on, drafts, caller-data unmasking).

| An API key can | An API key cannot |
|---|---|
| Use the tools its scopes allow (a tool that needs several scopes needs all of them) | List, create, rotate or revoke API keys |
| Read queues, callbacks and the callback reports and, with the Custom IVR add-on, IVR flows and the IVR call reports | Manage users, billing or the organization's integrations |
| Change a queue's callback settings, voice and language, and work its callbacks, as its write scopes allow. Changes that reach callers or place calls ask for [approval](/docs/mcp/safety#approval-prompts) on every call, and most of them also need a [confirm token](/docs/mcp/safety#confirm-tokens) | Create, delete, start or stop queues: create a queue in the portal, then manage its callback settings and callbacks through the tools |
| See caller numbers unmasked, only with an effective `pii:read` ([Caller data](/docs/mcp/safety#caller-data)) | Export reports as files, or reach another organization |

Queue CallBack can switch changes off on the server; while they are off, clients see only the read-only tools. After a change to a key, its scopes, the organization or a server switch, the tool list can take up to about 90 seconds to update: the server reuses a key's description for up to 30 seconds, and clients may cache the list for up to 60 seconds. Reconnect the client to refresh it. A change to the role of the admin who created the key can take a little longer, because the Queue CallBack API also reads that admin's rights through a short cache. Each tool call is checked again when it runs.

To see what a key can do now, call the `get_me` tool, which every key may call ([Check the connection](/docs/mcp/connect#check-the-connection)). `scopes` lists the scopes in effect:

```json
{
  "actor_type": "api_key",
  "api_key": {
    "id": "<key id>",
    "name": "Claude Code - reporting",
    "prefix": "qcb_sk",
    "last4": "abcd",
    "created_at": "2026-11-05T09:00:00Z",
    "expires_at": "2027-02-03T09:00:00Z",
    "minted_by": "...<masked>"
  },
  "organization_id": "<organization id>",
  "role": "org_admin",
  "scopes": ["callbacks:read", "org:read", "queues:read", "reports:read"],
  "pii_allowed": false,
  "custom_ivr_enabled": false,
  "ivr_reporting_enabled": false,
  "delegation": null,
  "user_id": "apikey:<key id>"
}
```

An API key is a credential for the Queue CallBack MCP server. These pages document the MCP server only.

## Scopes

A scope is one kind of access given to a Queue CallBack API key. There are 12. "What it allows" sums up each scope; the portal describes it in its own words. The IVR flow tools are Preview ([IVR flows](/docs/mcp/ivr)).

| Scope | Portal group | What it allows | Takes effect only when | Example tools |
|---|---|---|---|---|
| `ivr:read` | IVR | Reading IVR flows with their nodes, versions and diffs, reading the node types, and validating a flow | The organization has the Custom IVR add-on, and the credential acts as an organization admin (the User role has no `ivr:read`) | `list_flows`, `get_flow`, `diff_flow`, `validate_flow`, `list_node_types` |
| `ivr:write` | IVR | Changing a flow's draft (its nodes and connections) and discarding it. Callers hear none of it until a publish | Custom IVR add-on, and the organization edits flows through drafts | `create_flow_draft` and `edit_flow_draft` (both with `ivr:read`), `discard_draft` |
| `ivr:publish` | IVR | Publishing a draft or restoring an earlier version, which changes what callers hear | Same as `ivr:write` | `publish_flow`, `restore_flow_version` |
| `reports:read` | Reporting | The callback reports, a callback's journey and live numbers, for every role; also the IVR call reports, for organization admins of organizations with the Custom IVR add-on. Caller numbers masked | Always; the IVR call reports only as [IVR call reports](#ivr-call-reports) says | `get_live_stats`, `get_callback_summary`, `list_callbacks`, `get_callback_journey`; IVR call reports: `get_ivr_summary`, `list_ivr_calls`, `get_ivr_call`, `get_flow_decisions`, `list_ivr_flow_stats` |
| `pii:read` | Reporting | Caller numbers and collected digits without masking | Caller-data unmasking is on, and the organization is not healthcare-locked | `add_callback` (with `callbacks:write`); also unmasks numbers in every tool's answers and allows number search and `caller` filters |
| `callbacks:read` | Callbacks | Reading the callback queue and the status of a requeue | Always | `list_callback_queue`, `get_requeue_status` |
| `callbacks:write` | Callbacks | Marking callbacks complete, and adding callbacks (adding also needs `pii:read`) | Always | `complete_callback`; `add_callback` (with `pii:read`), which places real calls |
| `callbacks:dial` | Callbacks | Requeueing callbacks, which places real calls to agents and customers | Always | `requeue_callback` (with `callbacks:read`) |
| `queues:read` | Queues | Reading queues, without their credentials or RingCentral app details, and the voice catalog | Always | `list_queues`, `get_queue`, `list_voices` |
| `queues:write` | Queues | Changing a queue's callback timeout and requeue settings, and its voice and language, which reach the queue's next callers | Always | `update_queue_settings`, `set_queue_voice` (with `queues:read`), `set_queue_language` |
| `org:read` | Organization | Reading the organization's name and settings | Always | `get_organization` |
| `org:write` | Organization | Renaming the organization | Always | `set_organization_name` |
| (none) | | | Always | `get_me` |

A queue is a Queue CallBack configuration connected to one RingCentral call queue; the portal lists queues under **Configurations**, where an organization admin creates them. The `add_callback` tool is listed only for keys whose `pii:read` takes effect. The [tool reference](/docs/mcp/tools) gives the scopes of every tool.

### How scopes are checked

- The Queue CallBack MCP server lists a tool only when the key holds every scope the tool needs, and the Queue CallBack API checks the same scopes again on every request.
- A tool the key lacks a scope for is not listed. A call to it by name is refused before anything is sent, with the tool error `insufficient_scope` and `required_scope` naming the scope.
- The Queue CallBack API can still refuse a listed tool with the tool error `insufficient_scope`, where `required_scope` names the missing scope. This happens when a scope stopped taking effect after the client fetched its tool list, or when a search by number or a `caller` filter is sent without an effective `pii:read`.
- A key's scopes are limited to its creator's role when it is created, and again on every request.

### IVR call reports

The five IVR report tools (`get_ivr_summary`, `list_ivr_calls`, `get_ivr_call`, `get_flow_decisions`, `list_ivr_flow_stats`) need `reports:read`, and they are open only to organization admins of organizations with the Custom IVR add-on, or of organizations that keep IVR reporting for a time after the add-on lapsed. An API key counts as an organization admin while the admin who created it still is one. A sign-in counts when the signed-in person is an organization admin.

- `get_me` shows `ivr_reporting_enabled`. While it is `false`, the five tools are not listed, and a call to one is refused with [`ivr_reporting_not_enabled`](/docs/mcp/errors#ivr_reporting_not_enabled) before anything is sent.
- The callback reports (`get_callback_summary`, `list_callbacks`), a callback's journey (`get_callback_journey`) and live numbers (`get_live_stats`) stay open to every role with `reports:read`.

### When a scope does not take effect

The Custom IVR add-on is the IVR flow builder; the portal's **Billing** page sells it as the Custom IVA plan. Without it, the **Create API key** dialog does not offer the IVR scopes and says: "Needs the Custom IVR add-on (the IVR flow builder), which this organization does not have." While the plan can be bought, the reason reads: "Custom IVA is not active for this organization. An admin can buy or restore it on the Billing page." IVR scopes an existing key holds stay on it and work again if the add-on returns.

Other organization settings decide whether the remaining scopes take effect. While one is off, the portal gives the reason:

| Scope | Portal reason |
|---|---|
| `ivr:write`, `ivr:publish` | "Takes effect when this organization edits its IVR flows through drafts and publishing." |
| `pii:read` | "Takes effect when unmasking caller data is turned on for this organization." |
| `pii:read` (healthcare-locked) | "This organization is healthcare-locked: caller numbers and collected digits stay masked." |

To turn on caller-data unmasking, an organization admin emails Queue CallBack support (support@queuecallback.com) with the organization's name. A healthcare-locked organization stays masked whatever is asked.

In the key list, a scope that is not in effect is struck through; hover it for the reason. A scope the creator's role no longer allows shows "Not allowed for the role of the admin who created this key."

## Recommended key sets

Start with a read-only Queue CallBack API key, and put write scopes on separate API keys, one per job.

| Key | Scopes | What the agent can do | Watch out for |
|---|---|---|---|
| Read-only reporting | `reports:read`, `callbacks:read`, `queues:read`, `org:read`, plus `ivr:read` with the Custom IVR add-on (what **Read only** selects) | The callback reports, live numbers, the callback queue, queue settings and, with the add-on, IVR flows and the IVR call reports. Changes nothing | Caller numbers stay masked. Add `pii:read` only if people need full numbers and unmasking is on |
| IVR editing (Preview) | `ivr:read`, `ivr:write`, `ivr:publish` | Draft, edit, validate, compare and publish flows; restore earlier versions | `ivr:publish` changes what callers hear; leave it out for a key that only prepares drafts. See [Edit a flow safely](/docs/mcp/ivr#edit-a-flow-safely) |
| Callback operations | `callbacks:read`, `callbacks:write`, `callbacks:dial`, `queues:read` | Read the callback queue, complete callbacks, requeue expired, failed or cancelled callbacks and follow each requeue | `callbacks:dial` places real phone calls to agents and customers, and the portal warns you to grant it only to a client you trust to dial. Leave it out for a key that only reads and completes callbacks |
| Queue settings | `queues:read`, `queues:write` | Change a queue's callback timeout, auto-requeue, requeue attempts and Manual Callback Only flag, and its voice and language | Each change asks for approval and needs a confirm token. A voice or language change reaches the queue's next callers |

To add callbacks with `add_callback`, add `pii:read` to the callback operations key; it works only where caller-data unmasking is on. Adding a callback places real calls even without `callbacks:dial`: the queue rings and, once an agent answers, the customer is called.

## Rotate, revoke and suspension

Organization admins rotate and revoke Queue CallBack API keys on the **API keys** page (**Settings**, then **Manage API keys**). Each key has one of four statuses:

| Status | Portal help text |
|---|---|
| **Active** | "Requests with this key are accepted." |
| **Suspended** | "The admin who created this key is no longer an active user of this organization, so the key is refused. Rotate it to make it yours, or revoke it." |
| **Expired** | "This key is past its expiry date and is refused. Rotate it to issue a fresh key." |
| **Revoked** | "This key was revoked or replaced and is refused for good." |

Revoked and expired keys stay listed as records, so past changes stay attributable; tick **Show revoked and expired keys** (shown with a count once there is at least one) to see them. A refused key gets HTTP 401 `invalid_token` when a client connects, or the tool error `invalid_credentials` during a session ([Errors](/docs/mcp/errors#tool-errors)).

### Rotate an API key

Rotating creates a new key with the same name and scopes and stops the old key at once. Rotate before a key expires (see **Expires**), after a possible leak, or to take over a suspended key.

1. In the key's row, choose **Rotate**. The dialog says: "A new key with the same name and scopes is created and shown once, with you as its creator. The current key (qcb_sk_...abcd) stops working immediately: update every client that uses it."
2. In **New key expires after**, choose 30, 60, 90, 180 or 365 days.
3. Choose **Rotate key** and copy the new key. It is shown once.
4. Put the new key in `QCB_API_KEY`, or in the secret store it is loaded from, everywhere the old key was used, then reconnect each client.

- The rotating admin becomes the new key's creator, and its scopes are limited to that admin's role.
- Rotating an active or suspended key works at the 25-key limit, because the new key takes the old key's place. Rotating an expired key needs a free place: at 25 active or suspended keys it is refused ("This organization already has 25 active API keys; revoke one first"). A revoked key cannot be rotated.
- There is no overlap. To switch clients without a gap, create a new key, move the clients, then revoke the old key.

### Revoke an API key

1. In the key's row, choose **Revoke**. The dialog says: "Requests with qcb_sk_...abcd are refused from now on. This cannot be undone."
2. Choose **Revoke key**.

Revoke a key when its client is retired or its user leaves. If a key may have leaked, rotate or revoke it at once; both stop it immediately. The **Last used** column shows keys nobody uses.

### Automatic suspension

A key is suspended while the admin who created it is deactivated or no longer belongs to the organization. A suspended key is refused, still counts toward the 25-key limit, and works again if that admin is reactivated. Another admin can rotate it to take it over.

## OAuth sign-in

OAuth sign-in lets Claude and ChatGPT connect to the Queue CallBack MCP server when a person signs in with their Queue CallBack account. No API key is needed. A signed-in connection is read-only: it acts as the person who signed in, in that person's own organization, limited by that person's role, and it can never change anything, place calls or show caller numbers unmasked. Every other client connects with an API key, and every task that changes something needs an API key.

This sign-in is not the portal's **RingCentral Connection**, which links Queue CallBack to RingCentral.

| Topic | Sign-in from Claude or ChatGPT |
|---|---|
| Clients | Claude (claude.ai, Claude Desktop, the Claude mobile apps and Cowork) and ChatGPT on the web. Setup: [Sign in from Claude](/docs/mcp/connect#sign-in-from-claude) and [Sign in from ChatGPT](/docs/mcp/connect#sign-in-from-chatgpt). Queue CallBack supports sign-in from these two clients only; every other client connects with an API key |
| Account | Your Queue CallBack portal account, the one you use at `https://dashboard.queuecallback.com` |
| Who can sign in | Any active portal user of an organization: Organization Admin or User. An Organization Admin gets the five read scopes below. A User gets them without `ivr:read`, so a User's sign-in cannot read IVR flows, and only an Organization Admin's sign-in reads the [IVR call reports](#ivr-call-reports) |
| Where it acts | In the signed-in user's own organization, with the user's current role, checked on every request. No tool takes an organization id, and a signed-in connection cannot pick another organization. An account that belongs to no organization is refused with 403 `no_organization` |
| Scopes | At most `ivr:read`, `reports:read`, `callbacks:read`, `queues:read` and `org:read`, whatever the client asks for. On every request they are narrowed again to the user's role and the organization's settings, so `ivr:read` takes effect only for an Organization Admin, with the Custom IVR add-on |
| Caller data | Always masked. Sign-in never grants `pii:read`: caller numbers keep only their last four digits, collected digits are hidden, and searches by number are refused ([Caller data](/docs/mcp/safety#caller-data)) |
| Changes and calls | None. Sign-in never grants a write scope, `ivr:publish` or `callbacks:dial`, so no tool that changes something, publishes a flow or places a call is listed |
| Request limits | Each signed-in person has the limits of one API key and shares the organization's limits with its keys ([Limits](/docs/mcp/errors#limits)) |
| API keys page | A sign-in is not an API key. It does not appear on the **API keys** page and does not count toward the 25-key limit |

### What you see when you sign in

1. Claude or ChatGPT opens the Queue CallBack sign-in page (`https://dashboard.queuecallback.com/sign-in`) in your browser.
2. Sign in with your Queue CallBack portal account. If you are already signed in to the portal in that browser, this step is skipped.
3. A consent page on `https://accounts.dashboard.queuecallback.com` asks you to allow the client to read your Queue CallBack data. ChatGPT also asks to see your name and email address (the standard `openid`, `profile` and `email` permissions); that gives it no further Queue CallBack access. Approve it.
4. You return to the client, which shows the Queue CallBack MCP server as connected and lists the read tools.

Checked with Claude and ChatGPT on 2026-11-06.

To check a signed-in connection, ask the client to call `get_me`. `actor_type` is `oauth`, `user_id` is your user id, `api_key` is `null`, `role` is your role, and `scopes` lists the read scopes in effect. [Check the connection](/docs/mcp/connect#check-the-connection) explains each field.

### Sign-in or API key

| You want to | Use |
|---|---|
| Ask Claude or ChatGPT about the callback reports, the callback queue, queues and voices, or (as an Organization Admin with the Custom IVR add-on) IVR flows and the IVR call reports | Sign-in |
| Complete, add or requeue callbacks, change a queue's callback settings, voice or language, edit, publish or restore IVR flows, or rename the organization | An API key with the scopes for that job ([Recommended key sets](#recommended-key-sets)) |
| See caller numbers and collected digits unmasked | An API key with an effective `pii:read` |
| Run automation, scripts or scheduled jobs that no person signs in to | An API key |
| Use Claude Code, Cursor, VS Code, Codex CLI, Gemini CLI or any client other than Claude and ChatGPT | An API key |

To make changes from a Claude app, connect with an API key instead of signing in: Claude Desktop through the `mcp-remote` bridge, or a custom connector with the Request headers beta ([Claude Desktop](/docs/mcp/connect#claude-desktop)). ChatGPT cannot send an API key, so a ChatGPT chat stays read-only; for changes, use the [Codex CLI](/docs/mcp/connect#codex-cli) or the [OpenAI Responses API](/docs/mcp/connect#model-apis) with an API key.

### Disconnect or revoke sign-in

- Claude: open **Customize** > **Connectors**, then choose **Remove**, or the three dots next to the connector. On Team and Enterprise plans, an Owner removes an organization's connector under **Organization settings** > **Connectors**.
- ChatGPT: remove the Queue CallBack plugin in ChatGPT's plugin settings (**Settings** > **Plugins**).
- Removing the connection ends it in that client. An access token the client already holds stays valid until it expires, up to a day by default, and cannot be withdrawn earlier.
- A signed-in connection stops working within about a minute when the person is deactivated or leaves the organization in Queue CallBack.
- A change of role between Organization Admin and User applies to the person's sign-in on the next request: a User's sign-in has no `ivr:read` and no IVR call reports.

### For client builders

The discovery document is `https://mcp.queuecallback.com/.well-known/oauth-protected-resource/mcp` (RFC 9728). It names the authorization server, accepts credentials only in the `Authorization` header, and lists all 12 scopes in `scopes_supported` because API keys can hold them. The 401 `WWW-Authenticate` challenge asks for the five read scopes, and a token that grants none of them gets 403 `insufficient_scope`. Access tokens must name `https://mcp.queuecallback.com/mcp` as their audience, so a token issued for another service is refused. Queue CallBack supports sign-in from Claude and ChatGPT only; other clients connect with an API key.

## Related pages

- [Connect a client](/docs/mcp/connect): set up each AI client with `QCB_API_KEY`, or sign in from Claude or ChatGPT.
- [Tools](/docs/mcp/tools): every tool with its scopes.
- [Safety](/docs/mcp/safety): approval prompts, confirm tokens and caller-data masking.
- [Errors and limits](/docs/mcp/errors): every error code and its fix.
- [Troubleshooting](/docs/mcp/troubleshooting): symptom-first fixes and how to contact Queue CallBack support.