No. Claude's help center states that custom connectors are not verified by Anthropic. OpenAI's MCP documentation says custom MCP servers are not developed or verified by OpenAI. Adding a connector to a chat app is not an endorsement, so the checking falls to you.
What that means in practice
When a connector sits in your chat app's menu, it can look as official as everything else there. The documentation says otherwise. Each provider describes custom servers as third party software subject to its own terms, and connecting one means trusting its developer with whatever the tools can reach.
Both providers also warn about consequences. Claude's help center says Claude can take actions in connected services, that malicious servers may use prompt injection, and that developers can change tool behavior without notice. OpenAI says servers may receive sensitive data in queries, may request more parameters than needed, and may mislabel write actions as read only.
A short verification list
| Check | How |
|---|---|
| Who runs the server | Vendor documentation, company details, contract |
| Does it use OAuth | Try the sign in, read the consent page |
| What tools exist | Get the complete list with descriptions |
| Which can write | Test with a read only token |
| What is logged | Ask for sample audit entries |
| How are changes announced | Ask for the release process |
| Where does data go | Ask where the server is hosted and what it stores |
What the MCP spec leaves to you
The specification states that authorization is optional and that annotations are untrusted unless the server is trusted. It also says clients should show tool inputs and log usage. None of this certifies a server. The protocol describes how to talk, not who deserves trust.
Decision rules
- Prefer connectors from a vendor you already have a contract with.
- Do not connect a server whose operator you cannot name.
- Do not enable write tools until you have tested them in a sandbox.
- Revisit the decision whenever the vendor changes the tool list.
- Keep a register of approved connectors with an owner.
If a connector looks malicious
Disconnect it, revoke tokens at the vendor, and check what it could reach. OpenAI asks users to report malicious servers to its security address, listed in its documentation.
What a buyer should expect from a vendor
A vendor selling a security connector should volunteer its hosting details, its scope list, its logging and its change process. If you have to ask three times, that is information too.
A worked example: two connectors, two verdicts
This is a made up comparison. Two vendors each offer a connector for vulnerability data.
Connector one. The vendor is under contract with your company. The connector uses OAuth, the vendor provides a scope table and a full tool list, and it lets administrators disable write tools. Logs show user, tool and time. The vendor sends release notes that call out tool changes. You approve it for a pilot with read tools.
Connector two. It was found through a community list. The repository has one maintainer, no release notes, and a configuration that asks for a broad API key. The tool descriptions are brief, and one of them says read only for a tool that takes a write sounding argument. You cannot find any statement of where it is hosted. You decline.
Both appear in the chat app's connector menu in the same way. The chat provider verified neither. The difference in outcome comes from your checks.
Step by step: a connector vetting file
- Identity. Operator name, address, contact, contract status.
- Hosting. Region, provider, what is stored.
- Authentication. Method, scopes, token lifetime, revocation.
- Tools. Full list, read or write, test results.
- Logging. Sample entries, retention, access for you.
- Change process. Release notes, notice period, rollback.
- Incident process. Contact for a security issue, response commitment.
- Decision. Approved, limited or declined, signed and dated.
Table: sources of assurance and what they cover
| Source | Covers | Does not cover |
|---|---|---|
| Chat provider menu listing | That the connector can be added | Whether it is safe |
| Vendor documentation | Intended behavior | Actual behavior |
| Your sandbox test | Observed behavior today | Future changes |
| Contract terms | Obligations and remedies | Technical fit |
| Independent reports | Whatever they scope | Your configuration |
Use several rows together. None is enough alone.
What the providers say users should do
OpenAI's documentation advises connecting only to servers you know and trust, preferably official ones, and reviewing what each action asks for. Claude's help center advises monitoring tool inputs and outputs, disabling unneeded tools, and choosing Allow always only for trusted tools. Both points reduce to the same thing: the user, or the organization, carries the decision.
Words to avoid in your own documents
Do not write that a connector has been approved by the chat provider, unless you hold a statement from the provider that says so. Say that it was reviewed by your team and describe the review. This avoids implying an endorsement that does not exist, and it keeps your questionnaire answers accurate.
Renewal
Review annually or at any significant vendor change. Retire connectors nobody uses, since an unused connector with live tokens is pure exposure.
Where Safeguard fits
Safeguard offers an MCP Guardrail and agent identity for teams that want policy and accountability around the tools agents call. Judge any vendor, including us, by the checks above, and try the free scan to see real output.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at what a connector exposes and how it is configured, and map each item to a row of the vetting file.
Quick check
Does a connector appearing in my chat app mean it was reviewed?
No. Both providers say custom connectors are not verified by them.
What is the first check?
Name the operator of the server and confirm a contract or terms with them.
Can a provider's directory listing replace my own review?
No. Treat any listing as discovery, not verification, unless the provider states otherwise in writing.
Sources
- MCP security best practices
- MCP specification, tools
- Claude Help Center, custom connectors using remote MCP
- OpenAI developer docs, MCP
Last reviewed: 19 October 2026.
