Connecting an MCP server is a credential decision, not a networking one. The protocol grants a client nothing the server does not choose to expose, so the risk sits in three places: what the server's tools can reach, how you authenticated, and whether you can revoke one client without disturbing the rest.
The threat model, honestly
Revenue teams tend to worry about the wrong thing here. The common fear is that connecting a server lets a vendor read your conversations. That is not how it works. A server receives tool calls: a name and a set of arguments the model filled in. It does not receive the transcript.
The things actually worth attention, in order:
1. What the tools can do. A read-only search tool and a tool that can write to your CRM carry completely different risk. The protocol does not distinguish them for you. Read the tool list.
2. How you authenticated. A pasted API key is a long-lived bearer credential that lives in a config file, a settings pane, or occasionally a Slack message. Anyone holding it is you.
3. What arguments carry. Tool arguments are written by the model from your conversation. A tool with a free-text parameter can receive more context than you intended, because the model was being helpful. This is the least-discussed leak in agent tooling and the easiest to test: ask your agent to show you the exact arguments it sent.
4. Whether you can undo it. Revocation is the control that matters when something goes wrong, and it is the one nobody checks before connecting.
OAuth versus a pasted key
The practical difference is blast radius.
| OAuth | API key | |
|---|---|---|
| You handle a secret | No | Yes, and it persists wherever you pasted it |
| Per-client grants | Yes | Only if you issue one key per client |
| Revoke one client | Yes, without touching others | Only by rotating, which breaks everything using that key |
| Expiry and refresh | Built in | Whatever you remember to do |
| Works everywhere | No. Some clients have no OAuth flow | Yes |
Use OAuth wherever the client supports it. Use a key for CLIs, scripts and anything without a browser flow, and if you use keys, issue one per client so revocation stays surgical.
Signl runs its own OAuth server so Claude and ChatGPT connect without you touching a secret, and accepts an sk_signl_ key for everything else. Keys are shown once at creation and stored only as a SHA-256 hash, so a lost key is replaced rather than recovered. That is the property to look for: a vendor that can show you your key again is a vendor storing it in a form someone can steal.
Why auth spec versions break connectors
This is the most common reason a connector works for one colleague and fails for another, and it looks like a bug in the product rather than a version mismatch.
MCP has its own authorization specification, versioned separately from the protocol. As of 25 August 2026 Anthropic documents Claude as supporting the 2025-03-26, 2025-06-18 and 2025-11-25 auth specifications, with Dynamic Client Registration enabled. The current protocol revision is 2026-07-28, which is ahead of that list.
So a server built strictly against the newest specification may not authenticate against a client that has not implemented it. Nothing is broken; two things are on different versions. The symptom is a generic connector failure with no useful message.
Two things make this survivable, and both are server-side:
- Dynamic Client Registration. Without it, clients that cannot pre-register need manual handling, which reaches you as a support ticket.
- A proper 401. A well-behaved server returns a
WWW-Authenticateheader pointing at where to discover the authorization server, per RFC 9728. That header is how a connector UI finds the OAuth endpoints instead of failing with "server not found". Signl returns it on every unauthenticated request for exactly this reason.
Questions to ask a data vendor before connecting
Five, and they are answerable in a support chat. A vendor that cannot answer them quickly has told you something.
- Does the server support OAuth, or only API keys?
- Are keys stored hashed, and can you show me mine again? The correct answer to the second half is no.
- How do I revoke one client without breaking the others?
- What do you log from tool calls, and for how long? Arguments included, or only metadata.
- Which auth specification versions do you implement? If they do not know, the connector will work until a client updates.
The write-access question
Worth separating from everything above because it is where the real damage lives.
An agent with read access that gets something wrong wastes a minute. An agent with write access to a system of record that gets something wrong corrupts data other people depend on, silently, and the correction happens weeks later when someone notices a pipeline report is wrong.
Models do not fail loudly. They fail confidently. That asymmetry is the argument for keeping agents on read paths and putting writes behind a human or behind deterministic code, and it is why Signl exposes no tool that writes anywhere.
If you do grant write access, grant it to one system, scope it as narrowly as the vendor allows, and log it somewhere a person reads.
What to tell your security reviewer
If you are the one getting this approved, the short version that usually lands:
- The connection is outbound HTTPS to a named vendor endpoint. No inbound access, no VPN, no network changes.
- Authentication is OAuth 2.1 with per-client grants, revocable individually, or a hashed API key where the client cannot do OAuth.
- The server receives tool calls, not conversation transcripts.
- The tools are read-only. Nothing writes to an internal system.
- Data handling, retention and erasure are documented at privacy and fair use.
The point of writing it down is that most security objections to agent tooling are objections to an imagined version with write access and a shared credential. Naming what it actually is resolves most of them.
Related reading
- MCP for sales for the wider picture, including result limits and tool confusion.
- How to connect Claude to live B2B data for the setup itself.
- Security and data handling for Signl's specifics.
Sources
- Anthropic, Building custom connectors and its authentication reference. Verified 25 August 2026.
- Model Context Protocol, Versioning. Verified 25 August 2026.