For Support

First: is this even reachable yet?

As of this PR, no — the MCP server isn't wired into any deployed environment (see the Overview). If a ticket comes in about "connecting Claude" before this ships, the honest answer is that the feature doesn't exist for customers yet. Once it does ship, the questions below are the ones to expect.

"I clicked Connect in Claude and nothing happened"

Most likely a CSP or cookie issue, both of which are silent by design — the browser blocks the action without an error the user can see. Ask:

• **Which browser, and is it in a private/incognito window with third-party

cookies blocked?** The flow relies on a SameSite=Lax cookie surviving a cross-site redirect. If cookies are aggressively blocked, the callback finds no flow and reports "Your sign-in took too long" — a generic message, not a cookie-specific one, so don't expect the user to self-diagnose this.

• **Did they open the authorize link in a second tab while the first was

still in progress?** Each attempt is single-tab by design; starting a second overwrites the first's binding cookie, and the first tab's flow cannot be resumed as a result.

"It logged me in but never asked me to connect anything"

Ask what happened right after entering credentials. If they landed on the normal Dentolize dashboard instead of a consent screen, the most likely cause (the actual root cause of a real bug during development) is that the oauth_return parameter was lost somewhere in the browser's history before login completed — for example, if they bookmarked or manually retyped the login URL without the parameter. There's no user-facing recovery here other than starting the "Connect" flow again from Claude, since that's what regenerates the link with the parameter intact.

"It says 'Your sign-in took too long'"

This is the generic error for an authorization attempt that can no longer be found — either it genuinely expired (these flows are short-lived, on the order of minutes), or the browser lost the flow cookie somewhere along the way (see the cookie question above). The fix is always the same: start over from "Connect" in Claude. There's no way to resume a stale attempt by design — that's intentional, not a missing feature.

"This login is not attached to a clinic" / "That clinic is not available

on this login"

These mean the doctor's login genuinely isn't associated with any clinic (the first), or they somehow submitted a clinic ID their login doesn't actually hold (the second — this should never happen through the normal UI; if a customer hits it, that's worth escalating rather than working around, since it may indicate someone tampering with the request). This is one authorization per clinic by design: if a doctor works across two clinics, each needs its own separate "Connect."

"Claude says it can't see my patients / appointments / billing"

That's correct, not a bug, in this phase. Only inventory reporting exists today — see The inventory tools. Don't route this to engineering as a defect; it's a known, current scope boundary.

"Claude's numbers don't match what I see in Dentolize"

This should not happen — every tool is built and tested specifically to agree with the same figures clinic-web shows, including matching the exact same reorder-point boundary condition and the same permission-based narrowing. If a real mismatch is reported once this ships, treat it as a priority bug: the entire design point of this feature is that it never disagrees with the product about a number. Get the exact question asked, the clinic, and the date range — the tools echo back the exact filters and date window they used in every response, so ask the customer to share that part of Claude's answer, since it will usually explain an apparent mismatch (a different date range or timezone interpretation than expected).

"Someone left the clinic — can they still ask Claude things?"

No: the connection stops working the moment their Dentolize login stops working, because the tools check live permissions on every single call, not a snapshot taken when they connected. There's no separate step needed to shut off their Claude access when disabling their account.

What Support cannot yet do for a customer

There's no self-service or admin screen (yet) for a doctor or owner to see or revoke their own Claude connections — that's explicitly listed as future work, not an oversight. If a customer wants a connection killed before that screen exists, this needs an internal/engineering action, not a self-service one — flag this expectation before it ships.