Guide
Claude connector not working? How to diagnose it
When a connector fails, it is almost always one of five causes, and they are worth checking in order. Here is the calm version of the debugging session you were about to have.
When a Claude connector is not working, check five things in order: whether the connector is actually connected and enabled, whether its auth token has expired, whether it exposes a tool for what you asked, whether its generic tool set misses your customized setup, and whether the underlying API changed. Most failures are the first two.
Key takeaways
- Start with the boring causes: a disabled connection and expired auth explain most failures.
- Claude can only do what the connector's tools allow; many connectors are read-only or shallow.
- Generic tool sets miss custom fields and workflows, which looks like failure but is a design limit.
- If the underlying API changed and no one maintains the connector, the fix is a maintained one.
What should I check first when a Claude connector fails?
Check the connection itself before anything else. Confirm the connector is added to your account, enabled for the conversation you are in, and shows as connected. A surprising share of connector failures are simply a connection that was never finished, was disabled, or is not available where you are asking.
Resist the urge to jump to exotic causes. Work through these in order and stop at the first one that fixes it:
- 1Confirm the connector is installed, enabled, and showing as connected for the conversation you are in.
- 2Reconnect it. Expired or revoked auth is the single most common cause of a connector that used to work.
- 3Ask yourself whether the connector actually has a tool for what you asked. Read-only connectors cannot write.
- 4Check whether your request depends on custom fields or workflows a generic tool set does not know about.
- 5Consider whether the tool's API changed underneath the connector, especially if it broke without you changing anything.
The rest of this post takes each step in turn.
Has the connector's authentication expired?
If the connector worked before and fails now, expired auth is the most likely cause. Connectors hold tokens that lapse, get revoked, or lose scopes when passwords change or admins tighten policies. Disconnecting and reconnecting the integration refreshes the token and resolves the majority of these failures.
Auth failures have a recognizable shape: everything the connector does starts failing at once, not just one action. If Claude can still read data but cannot act, that points to missing tools or scopes instead, which is the next check.
When you reconnect, pay attention to what you are granting. A connection authorized with narrow, read-only scopes will reconnect cleanly and still fail on writes. The connection being green does not mean the permissions are complete.
Does the connector even have a tool for what I asked?
Often it does not. Claude can only perform actions its connector exposes as tools, and many connectors are read-only or cover a shallow slice of the underlying product. If Claude can describe a change but not make it, the connector is missing the write tool, and no reconnecting will add it.
This is the point where diagnosis shifts from fixing to evaluating. A connector that fetches records but cannot create, update, send, or advance anything is not broken. It was built that way.
The test is simple: ask Claude to make a small, harmless change, like logging a note or updating a field. If it completes the change, the write tools exist. If it can only tell you what to do by hand, you have found the ceiling of the connector, not a bug in it.
Failure or ceiling?
A broken connector fails at things it used to do. A limited connector fails at things it was never given tools for. The first is fixed by reconnecting; the second is fixed by a better connector.
Why does the connector miss my custom fields and setup?
Because off-the-shelf connectors are built against a generic version of the tool, not your account. If your team relies on custom fields, renamed stages, or your own workflow conventions, a generic tool set cannot see them, so Claude gives incomplete answers or writes to the wrong places.
This failure mode is sneaky because nothing errors. Claude answers confidently from the standard objects it can see, while the custom field that actually drives your process is invisible to it.
If your diagnosis keeps landing here, the problem is not connectivity, it is fit. A custom connector is mapped to your real schema, so the fields and pipelines your team actually uses are first-class instead of missing.
What if the underlying API changed?
APIs evolve, and a connector that nobody maintains eventually breaks against them. If the connector fails on actions that used to work, your auth is fresh, and nothing changed on your side, the tool's API may have shifted underneath it. Your options are to wait for a fix or move to a maintained connector.
This is the least common cause but the most frustrating one, because there is nothing you can do inside your own settings to fix it. With a community or unmaintained connector, there may also be no one responsible for fixing it at all.
It is also the strongest argument for having a connector someone is accountable for. A custom connector built for your team comes with a person to call, and when the API underneath it changes, updating the connector is their job rather than your open question.
If you have walked all five steps and landed on a limited, generic, or unmaintained connector, the durable fix is the same: a connector built for your actual tools, schema, and workflows, with write actions gated behind your confirmation.