Compatibility
Which AI assistants can reach it.
The assistant is yours and it stays yours. We run no model, hold no inference contract, and have no interest in which one you standardise on. The connector speaks the Model Context Protocol, an open specification that several assistant vendors now implement, so the useful question is not whether we support your assistant. It is whether we have verified it.
That distinction is the whole page. "Supported by the protocol" is a reasonable expectation. "Verified" means somebody attached that client to this server, listed the tools, called one for real, and read the row it wrote in the audit trail afterwards. We have done the second thing for one assistant, and we name it rather than letting it imply the rest.
The status, per client
One verified, and the honest word for the others.
Every client below can reach an MCP server over HTTP, which is what the protocol is for. What differs is how each one signs a person in, and whether we have run it against this server ourselves rather than assuming it from the specification.
| Assistant | How a person signs in | Status here | What we would watch |
|---|---|---|---|
| Claudedesktop, web and the CLI | A Microsoft work account through the sign-in broker, or a token issued to one named person. | verified | Nothing outstanding. This is the client the connector was proven against. |
| ChatGPTand OpenAI agent tooling | OAuth, the same round trip Claude makes. | unverified | Whether it comes back to the address our metadata advertises. A client that rewrites it lands on the wrong environment, which is the worst available symptom. |
| Microsoft Copilotand Copilot Studio | Likely a token from your own Entra application rather than from our broker. | unverified | That is a different sign-in shape, not a setting. Say early if this is your estate, because it changes the first week rather than the first hour. |
| Cursorand other IDE clients | Usually a pasted token, sometimes OAuth. | unverified | Per-developer credentials at scale. A token in a repository is the failure mode, and it is a custody problem before it is a protocol one. |
| Your own agent codeframeworks and in-house | Whatever bearer credential you hand it. | unverified | The same custody problem, with nobody to blame but the person who issued the token. Grants and the audit trail still apply, which is the point. |
"Unverified" is not "does not work". It means nobody has attached that client to this server and written down what happened, and we would rather publish that than imply a test we have not run. Where an entry has a specific risk we name it, because a client that behaves badly here fails in a way that reads like your misconfiguration rather than ours.
What the word means
Verified, in the only sense worth claiming.
A compatibility badge is worth nothing without the test behind it, so here is the test. It is deliberately unglamorous: a handshake, a tool list, one real call against the live deployment, and the record it left.
| client | Claude |
| transport | HTTP, against the live connector |
| handshake | completed |
| tool list | returned, narrowed to that person |
| a real call | yes, answered from live data |
| audit row | written, outcome allowed |
| attributed to | one named person, not a shared credential |
The reason this is a short list rather than a long one is that the interesting failures are not in the protocol. They are in the sign-in round trip, and they only appear when a real client makes it.
Why this is not a Claude product
Change assistants and nothing here changes.
The reason we can name one assistant without being tied to it is that none of the governance lives inside the assistant. It lives in the layer between the assistant and your systems, which is the layer you are buying.
Changes when you switch
- The client application your people open, which was always their choice and not ours.
- The sign-in registration, once, so the new client is recognised at the connector address.
- A verification pass, the same short test as above, run with you before anybody relies on it.
Does not change
- Every grant. Who may reach which environment with which tools is unaffected.
- The four narrowing checks. They run on the server, so no client can widen what they allow.
- Your written rules, approved by a named person, in your vocabulary.
- The audit trail, unbroken across the change, because the record is ours to write and not the assistant's.
The uncomfortable version of that argument. If your assistant vendor eventually ships per-person entitlements and an exportable audit trail over your own systems, the case for a separate layer narrows. It narrows to the part they have no reason to build: the same rules across systems from different vendors, and a record that survives you changing assistants. Decide whether that is worth paying for rather than taking our word that it is.
What we will not say
"Works with any AI" is a sentence we have deleted twice.
It is probably true. The protocol is open and the clients that implement it are supposed to behave the same way. We still do not write it, because the first client to find an incompatibility we asserted would be right to conclude we had never tried.
Verification is a named step
Which client, which sign-in flow, one successful tool list and one successful call, recorded. It sits in onboarding with everything else that has to be true before you rely on it.
It costs about half an hour
Per client type, not per person. The cost is the support commitment it creates afterwards, which is the correct thing to be paying for.
The result is written down
Including a failure. A client we could not make work is a row on this page rather than a conversation you have after signing.
Tell us which assistant your people already have.
It is the first question we ask, because it decides whether the first week is a configuration entry or a different sign-in topology. Either answer is fine. Finding out late is not.