When something goes wrong, the connector tells your AI assistant what happened and what to do next. This page lists each message, with its error code in code style.
"Which firm do you mean?"#
What you see: the assistant asks which firm you mean, or lists firm names.
Why: your connection covers more than one firm and the request did not say which (org_required). If you named a firm that is not on this connection, the answer is org_not_granted and lists the firms it does cover.
What to do: name the firm, for example "for smith-law". If the firm you want is missing, reconnect and tick it on the consent screen.
"No firm is connected"#
What you see: the assistant says there is no firm on your Receptiva account or connection (no_org).
Why: your account had no firm when you connected, or you have since lost access to it.
What to do: finish setting up your firm, or reconnect and select your firm on the consent screen.
"This action isn't available" or "read-only access"#
What you see: a request to change a lead's status or your receptionist's settings is refused.
Why: you are a view-only member of that firm, so your connection is read-only there (insufficient_scope or forbidden). Only the firm's owner can change a lead's status or the receptionist's settings.
What to do: ask the firm's owner to make the change, from their own connection or from the Receptiva dashboard.
"Connection invalidated" or a 401 after disconnecting#
What you see: the assistant reports something like "connection invalidated, reconnect", or a 401 response.
Why: the connection was disconnected from the Receptiva dashboard. Receptiva refuses the app from its next request on.
What to do: add the connector again and approve it on the consent screen, which appears on every reconnect.
"Full caller data" is not turned on#
What you see: the assistant says transcripts or a lead's full intake are off for your firm.
Why: call transcripts and full lead intake are off until your firm's owner turns them on. They are also returned only on a firm owner's connection, never a view-only member's.
What to do: the firm's owner opens the Receptiva dashboard, goes to Integrations, and turns on Full caller data for AI assistants. It takes effect on the assistant's next request. See Data and privacy.
New tools don't show up#
What you see: the assistant lacks a tool these docs describe.
Why: Claude caches a connector's tool list.
What to do: in claude.ai, refresh the connector under Settings, then Connectors. No new approval is needed. In Claude Code, detach the connector and attach it again.
Refreshing the connector's tools in Settings picks up new tools. If the assistant still seems to be working from older tool descriptions (for example, it doesn't know about house rules), disconnect the connector and connect it again; you will see the consent screen again.
"That connection request has expired or was already used"#
What you see: this message on the Receptiva consent page.
Why: the sign-in link from your AI app was already used or has timed out.
What to do: start again from your AI app. Do not reuse an old consent page link.
Google sign-in says there's no account#
What you see: "There's no Receptiva account for that Google address."
Why: that Google address has no Receptiva account.
What to do: sign in with the one-time email code, using the email your firm uses with Receptiva. If your firm is not on Receptiva yet, start setup first.
"That cursor isn't valid"#
What you see: an invalid cursor error (invalid_cursor) while paging through calls or leads.
Why: the page marker was changed or came from somewhere else. A cursor from the calls list does not work on the leads list, and the other way round.
What to do: ask again from the start; the assistant repeats the request without a cursor. A date range that ends before it starts is refused similarly (invalid_range).
"No call (or lead) with that id"#
What you see: the assistant cannot find a call or lead (not_found).
Why: the id belongs to a different firm, or was not copied exactly from a list.
What to do: check you are asking about the right firm, then list calls or leads again and pick from that list.
"The receptionist isn't set up yet"#
What you see: receptionist settings are unavailable (not_configured).
Why: your firm has not finished setting up its receptionist.
What to do: ask "What's my next step with Receptiva?". The answer links to the right place in your dashboard.
"The firm's live settings changed since this draft was started"#
What you see: the assistant cannot apply or add to a draft of receptionist changes (draft_conflict).
Why: someone changed the receptionist's settings, for example in the dashboard, after the draft was started. Receptiva will not apply a draft over changes it has not seen.
What to do: ask the assistant to show the current settings and start the changes again. Nothing from the old draft went live.
If you would rather drop a draft without starting a new one, ask the assistant to discard it. It confirms with you first, and the discard is recorded in the audit log.
"A firm fact or house rule was refused"#
What you see: the assistant cannot add or change a firm fact or a house rule, and gives a reason (invalid_edit).
Why: every new or changed fact and house rule is checked before it is saved, because the receptionist uses it on calls. One is refused when it would have the receptionist give legal advice or promise an outcome, share case details, give out a staff member's direct number or explain call routing, promise a callback within a set time, skip the AI and recording disclosure, the callback number or crisis handling, or stop taking messages. A fact is also refused when it is an instruction about how to behave (save it as a house rule instead). A house rule is also refused when it tries to change who gets transferred or when: that is your routing or office hours setting. A house rule can also be refused for its shape: it must be one line of up to 160 characters, and a firm can have at most 10.
What to do: reword it as the message suggests, or make the change with the setting it names. If you see check_unavailable instead, the check could not run just then: nothing was saved, so try again in a moment.
"Couldn't read ... just now"#
What you see: "Receptiva couldn't read calls just now" or a similar message (unavailable).
Why: a temporary problem on Receptiva's side, including an audit entry that could not be saved (no entry, no data). A failed lead status change or settings change changes nothing.
What to do: wait a moment and try again.
Calling the endpoint directly#
If you call https://mcp.receptiva.ai/mcp yourself, these are the HTTP responses you may see:
| Status | When | What to do |
|---|---|---|
| 401 | Missing, invalid or disconnected bearer token. The response carries a WWW-Authenticate header (shown below). |
Get a token through the OAuth flow. |
| 403 | The request came from a web page on another site (checked with the Origin header). |
Call the endpoint from a server, not a browser page. |
| 404 | The connector is switched off. Every request gets a bare 404. | Try again later. |
| 405 | GET or DELETE. The response carries Allow: POST. |
Use POST. The server is stateless and has no event stream. |
| 406 | The Accept header does not list both application/json and text/event-stream. |
Send both. |
| 413 | A JSON-RPC batch of more than 20 messages. | Send smaller batches. |
| 429 | More than 120 requests in 60 seconds from one IP address, counted across /mcp and /api/v1 together. |
Slow down and retry after the window. |
| 503 | A problem on Receptiva's side. There is no WWW-Authenticate header, so your client should not start sign-in again. |
Retry later. |
Tokens for the connector come only from the OAuth 2.1 sign-in flow. API keys work on the REST API, not on the MCP endpoint. A request that sends both Accept types looks like this:
curl -i https://mcp.receptiva.ai/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "Authorization: Bearer $RECEPTIVA_TOKEN" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'Without a valid token this returns the 401. Its header is how MCP clients find where to sign in:
WWW-Authenticate: Bearer resource_metadata="https://mcp.receptiva.ai/.well-known/oauth-protected-resource/mcp"