Skip to main content
Two things worth knowing before you read the tables. Every token refusal is a 401 — read the code. A bad token, a disabled or expired one, the connector switched off, an uninstalled app and a plan without the connector all come back as 401. The code tells them apart, and reconnecting only helps when the fix is a new token. Not every non-200 is a fault. GET /mcp answers 405 on purpose. The connector answers each request and offers no streaming connection; 405 is how a client is told there is none to open.

What the connector returns

The connector checks in this order and stops at the first problem: token format, token exists, token active, expiry, the store’s Connector switch, app still installed, plan, rate limit.

Errors that arrive inside an answer

When the connection is fine but the tool can’t do what was asked, the answer itself says so, with an error and a hint:

Confirmation statuses

Tools that change something answer with one of these statuses:

On the connect page

These appear on the Connect to Notifylyst page in your browser: A few plain pages can also appear if the client’s request itself is wrong — “Missing client”, “Unknown application”, “Missing redirect” or “Redirect not allowed”. Each says “Nothing was shared and no access was granted. You can close this window.” Start the connection again from your client.

Client-side messages that are not our errors

Checking a refusal yourself

The health check answers the “is it the token or the client?” question in one command:
  • 200, status ready, with the store, allowed tools and expiry → the token is fine; the problem is client-side.
  • 401 → the token can’t be used. This covers every refusal, including the Connector switch being off and the plan not including the connector.
  • 429 → over the rate limit.
Each check uses one request from your rate limit. Symptom-first version of this page: Troubleshooting.