Bonnard errors and how to fix them

This page gives the errors that Bonnard sends to AI clients, scripts and the people who sign in. Each entry quotes the message exactly, where there is one, then gives the cause and the fix. Your database’s own errors are on its connector page.

Verified 15 Oct 2026.

At a glance

Request IDs

Each response from an app’s URL, except a 405, has a request ID in its x-bonnard-request-id header. An error from the app’s URL also gives it in the request_id field of the body:

{
  "error": "audience_forbidden",
  "error_description": "This MCP server is not available to you. Ask the server owner to add you to its audience.",
  "request_id": "bnreq_<21 characters>"
}

Quote the bnreq_ ID when you ask Bonnard for help. A script reads it from the header or the body. For a tool call, the ID is in the HTTP header only. Sign-in pages show no request ID, so give the app, the AI client and the time instead.

Observability, in the console at app.bonnard.ai, does not show the bnreq_ ID. Its Request id field is a different value: the AI client’s own ID for the call.

App URL errors

An app’s URL answers an error with an HTTP status and, except for a 405, a JSON body: error (the code), error_description (the message) and request_id. Each entry shows the error_description, or the whole body where it differs. <slug> in a message is the app’s name in its URL.

Method not allowed.

{"jsonrpc":"2.0","error":{"code":-32000,"message":"Method not allowed."},"id":null}

HTTP 405, with the header Allow: POST and no request ID. The app’s URL takes POST requests only, so a browser that opens the URL gets this answer. Install the app in an AI client with the URL instead. See Install in AI clients.

not_found

HTTP 404. No app has this URL: the URL is wrong, or someone deleted the app. Copy the URL again from the app’s Endpoints card.

HTTP 404, on the production URL of an app that is not published. Select Publish in the app’s header. See Publish the app. The staging URL answers before you publish.

unauthorized

{"error":"unauthorized","request_id":"bnreq_<21 characters>"}

HTTP 401, with a WWW-Authenticate header that points to the app’s sign-in details. The request has no Authorization: Bearer header. An AI client reads the header and opens Bonnard’s sign-in. A script sends its API key in the header: Authorization: Bearer <key>. See Connect a script with an API key.

invalid_token

HTTP 401. The error_description gives the cause.

forbidden

HTTP 403, on a staging URL. Only members of the workspace that owns the app can use it. Your customers’ users and their API keys use the production URL.

server_misconfigured

HTTP 500. Bonnard cannot load the app’s settings. Quote the request ID when you ask Bonnard for help.

batch_too_large

HTTP 400. A client sent more than 100 JSON-RPC requests in one batch, and Bonnard ran none of them. Send 100 or fewer in each batch.

audience_forbidden

HTTP 403, on the production and staging URLs. The person, or their customer, is not in the app’s audience. Add them to the app’s audience. Each refusal is a denied call on Observability.

no_test_context

HTTP 409, on the staging URL of an app on a database with tenancy. Staging acts as one customer. It selects that customer by itself only when the app’s audience has exactly one customer with a tenant. The app’s Overview tab has no control for this. See Which customer staging acts as.

no_tenant

HTTP 403. The app’s database has tenancy, and the caller has no tenant. The caller is one of these:

• A personal API key, from Settings, then API keys. Use a customer user’s key instead: on Customers, select the customer, then API keys in the user’s row menu.
• A user of a customer with no tenant. Set the customer’s Tenant binding on Customers.

The message’s staging suggestion does not work for an API key: on a staging URL, an API key acts as no customer.

not_serving

HTTP 402, for your customers’ users and their API keys. The workspace that owns the app must act before the app answers calls again. The AI client connects, but each request after that gets this error.

A user tells the company that gave them the app. An admin of that workspace finds the refused call on Observability: its Reason names the cause.

payment_failed

HTTP 402, for members of your workspace and their personal API keys. An Admin or Owner of your workspace updates the payment method on the Billing page under Settings.

allowance_exhausted

HTTP 402, for members of your workspace and their personal API keys. An Admin or Owner of your workspace selects Turn on extra usage on the Billing page under Settings, or changes the plan.

no_payment_method

HTTP 402, for members of your workspace and their personal API keys. Extra usage is on, but no payment method is on file. An Admin or Owner of your workspace selects Add a payment method on the Billing page under Settings.

spend_limit_reached

HTTP 402, for members of your workspace and their personal API keys. An Admin or Owner of your workspace selects Edit spend limit on the Billing page under Settings.

tenant_id_invalid

HTTP 403. On SQL Server with Multi-tenant (RLS), the customer’s tenant has more than 128 characters. Give the customer a shorter Tenant binding on Customers.

no_tenant_credential

HTTP 403. On BigQuery with a service account for each customer, this customer has none. Enter its service account in the app’s Audience card. See BigQuery with Dataset per tenant.

tenant_not_routable

HTTP 403. The customer’s tenant has no dataset, database or schema on this app’s database. On BigQuery with Dataset per tenant, map the customer in the app’s Audience card. On other engines, add the tenant to the database’s tenancy settings on the Data page.

Sign-in errors

These errors show in the browser that the AI client opens for sign-in, or in the AI client after it.

access_denied

Bonnard ends the sign-in and sends the AI client error=access_denied with one of these descriptions. The AI client decides what to show.

rate_limited

HTTP 429, with a Retry-After header: the number of seconds to wait. Bonnard counts sign-in requests for each IP address, and password sign-ins for each email address and company domain. Wait for the Retry-After time, then try again.

Your customers’ sign-in page shows Too many attempts. Wait a minute and try again. The numbers are on Limits and AI client access.

Expired authorization request

The browser shows this in place of the Authorize access page. The sign-in request is too old, or the page opened again after the sign-in ended. The same page shows Invalid authorization request. when it opens with no request, and Could not load the authorization request. when Bonnard cannot read it. In each case, start the connection again from the AI client.

That code is invalid or expired.

The sign-in page shows this after Verify & connect. The 6-digit email code is wrong, more than 10 minutes old, or used up by 3 wrong entries. For a new code, select Use a different email, enter the address again, then select Send code.

No code arrives

After Send code, the sign-in page says If that address can sign in, a 6-digit code will arrive shortly. Bonnard shows the same text when it sends no code. It sends none, for example, for an address that is not a user of a customer with access to the app. It also sends none after too many code requests for one address. The person asks the company that gave them the app to add their address. An admin of that workspace adds it as a user of the customer on Customers.

We could not continue this sign-in.

The sign-in page shows the message with one of two endings.

Single sign-on fails

The customer’s identity provider did not sign the person in. Select Try again, or Use a different email. If the sign-in fails again, the customer’s IT admin examines the identity provider.

Errors in tool results

A failed tool call returns text to the agent, marked as an error (isError), in place of a result. The messages are for the agent. A person acts only where an entry says so. Each failed call is a record on Observability, with the status denied or error.

invalid_arguments

A JSON block follows with "error": "invalid_arguments", the arguments at fault, and the required and optional arguments. The agent sent arguments that the tool does not take. A person has nothing to do.

Read-only refusals

The agent gets one of these messages when its SQL is not one SELECT or WITH statement, or when it can write or lock rows. On PostgreSQL and Amazon Redshift, Bonnard also refuses some functions, for example pg_sleep and dblink, with <function>() is not allowed.

ClickHouse and MySQL / MariaDB add refusals of their own that end in is not allowed. or are not allowed.

The agent rewrites the query. Bonnard refuses these queries on each engine except Microsoft SQL Server, where the login’s grants decide.

Table '<name>' is not exposed.

The agent asked explore_schema for a table that does not exist, or that the app hides. With the app setting Correct a wrong name on (the default), the message adds the nearest table names and a hint. If the table must be visible, show it on the app’s Data tab. See Table curation.

Database permission errors

On BigQuery, the first line is The BigQuery credential does not permit this operation. The result also names warehouse_credential_or_iam. The database refused the query for lack of permission. Bonnard does not pass on the database’s own message, because it can name projects, tables or users.

Grant the read-only user, or the service account, access to what the agent queried. The connector page for your database shows the grants, for example PostgreSQL.

PostHog needs reauthorization

The PostHog grant behind the connection lapsed. See Needs reauthorization.

Database errors

When sql_query fails for another cause, the agent gets the database’s own message, for example for a misspelt column. One of these hints follows, the first for a column and the second for each other cause:

Query time and row limits are on Limits.

The errors that your database sends when you connect it are on its connector page: PostgreSQL, BigQuery, Amazon Redshift, ClickHouse, MotherDuck, MySQL / MariaDB, Microsoft SQL Server and PostHog.

Other tool errors

Other tool errors start with the tool’s name, for example explore_dashboards: unknown dashboard "<id>". or render_chart failed: <message>. The message names what to change in the call.