Before you connect that MCP server, run these three commands

MCP servers are appearing faster than anyone can vet them. Your editor offers connectors. Claude and ChatGPT have directories. Someone on your team will wire one into a work account this week, and the flow is designed to take about four seconds: click Connect, approve, done.

Here's what those four seconds actually decide — and three commands you can run first.

What you're granting, stated plainly

When you connect an MCP server, you are letting a language model call functions on your behalf, in your account, with your permissions, based on its interpretation of sentences typed in a chat box.

That's not an argument against doing it. It's an argument for knowing three things before you do:

1. What can it do? Not "what will it do" — models are probabilistic and prompts get injected. What is the worst thing the exposed tools make possible?
2. How is it authenticating? A pasted API key that never expires is a very different risk from a one-hour OAuth token you can revoke.
3. What happens when you disconnect? If a key still works afterwards, you didn't disconnect anything.

Most connector UIs answer none of these. But a well-built MCP server publishes enough to answer #2 yourself, before you click anything.

Check 1: what is this server asking for?

Servers that implement the spec properly expose OAuth metadata at a well-known path, and it's readable without any credentials:

curl -s https://example.com/.well-known/oauth-protected-resource/mcp | jq

Real output from a server that does this correctly:

{
  "resource": "https://webcuris.com/mcp",
  "authorization_servers": ["https://webcuris.com"],
  "scopes_supported": ["mcp"],
  "bearer_methods_supported": ["header"],
  "resource_documentation": "https://webcuris.com/docs/mcp"
}

What you're reading for:

• authorization_servers — where you'll actually be typing your password. If it isn't the vendor's own domain, stop.
• scopes_supported — a short, specific list is a good sign. A scope like full_access tells you the model has no scoping.
• resource_documentation — a server that links its own docs has usually thought about being audited.

Nothing at that path? Not automatically damning, but it means the server isn't following the discovery spec, and you're now trusting a UI's summary instead of the server's own declaration.

Check 2: does it actually require authentication?

This one is quick and occasionally alarming:

curl -s -o /dev/null -w '%{http_code}\n' -X POST https://example.com/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

You want 401.

If an unauthenticated tools/list returns the tool list, the server is happy to talk to strangers. That may be intentional for a public read-only server — but if it's a server that touches your data, it means authentication was bolted on somewhere other than the front door, and you should want to know where.

Check 3: does it point you at the right place?

A correct 401 doesn't just refuse — it tells the client where to authenticate:

curl -sD - -o /dev/null -X POST https://example.com/mcp \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}' \
  | grep -i www-authenticate

www-authenticate: Bearer realm="Webcuris MCP",
  resource_metadata="https://webcuris.com/.well-known/oauth-protected-resource/mcp"

That header is how a client discovers where to get a token without you pasting anything. Its presence means the server implements the flow rather than improvising it — and improvised auth is where the interesting bugs live.

The one thing to read on the consent screen

When the approval page appears, most people read the app name and click. Read one more thing: the redirect address your browser will be sent back to.

That's the field that decides where your authorization code lands. A consent screen that doesn't show it is asking you to approve something you can't see, and a mismatched one is the classic way codes get stolen.

After you connect: ask it what it can do

Once connected, before you use it for anything real, ask the assistant directly:

"List every tool you have available from this connector, and what each one does."

Then read the list as an attacker would. For each tool, finish this sentence: "the worst plausible outcome of the model calling this at the wrong moment is…"

If any answer is worse than "a wasted API call", you've found the thing to think about. Tools that create, delete, send, pay, or invite deserve more scrutiny than tools that read.

If you're building one

Same list, from the other side:

• Publish the metadata. Let people audit you before they trust you.
• Return 401 with WWW-Authenticate. It's the spec, and it's how clients find your auth without a human pasting secrets.
• Keep the tool surface small and boring. Every administrative endpoint you expose is a sentence away from being called.
• Call the same code your UI calls. A parallel API written for assistants will reimplement 90% of your authorization checks. The missing 10% is the incident.
• Make Disconnect mean something. Short tokens, rotation, and revocation that takes effect on the next request rather than the next cache expiry.

The short version

The MCP ecosystem is about a year old and the conventions are being set right now by whoever ships first. That's exciting, and it means the usual safety rails — app store review, years of hardening, well-known bad actors — mostly don't exist yet.

Three curl commands is a low bar. But it's a much higher bar than clicking Connect, which is what most people are doing.

---

Disclosure: I work on Webcuris, which has an MCP server — the real output above is from ours, because it's the one I can show you without picking on somebody. The checks work on any server.