Is the MCP endpoint URL really a secret if the database password isn't in it?

Yes. On a managed gateway like Synra, the URL's token is the authorization. Cursor and Claude never see your database password — they only see the endpoint. Anyone who has that URL can call the same tools and read whatever that connection can read.

I committed mcp.json to a public repo. What do I do?

Rotate the endpoint immediately in your gateway dashboard so the old URL stops working. Update every client that used it (Cursor mcp.json, Claude connector, ChatGPT custom connector). Then scrub the token from git history if the repo is public — rotating alone is the urgent step; history cleanup is next.

Can my whole team share one Synra endpoint?

They can, but then everyone shares one audit trail and one blast radius. Prefer one endpoint per environment (staging vs prod replica) and avoid handing production URLs to people who only need staging. If someone leaves the company, rotate anything they had.

Does rotating the endpoint change my database password?

No. On Synra, rotating regenerates the gateway URL token. Your encrypted database credentials stay put. You only need to paste the new URL into each AI client.

Is opening the endpoint URL in a browser a leak?

Opening it yourself for a connectivity check is fine — you'll usually see a JSON-RPC error without MCP headers, which just proves the host is reachable. Don't screenshot that URL into a public issue or Slack channel. The leak is publishing the token, not the GET itself.

MCP Endpoint Security | Treat URL Like a Password

Setup guides say it once — treat the MCP endpoint like a password — then jump to mcp.json and restarting Cursor.

On a managed gateway, that URL is the credential the AI client uses. Your Postgres password stays in the vault. The long token at the end of https://app.mcpserver.design/api/mcp/... is what authorizes reads.

Nobody needs to steal DATABASE_URL from Cursor. They paste the gateway URL into a gist, a PR, or Slack — and get the same access your agent has.

Below: what the URL is, how it leaks, what to do when it does, and how to share access without spraying the token. Mutation risk: Why Read-Only AI Database Access Matters. Where to point the connector first: Staging First. After a scare, use the query audit log to see whether the URL was used.

What the endpoint is (and isn't)

Is: Whoever has it can call the MCP tools behind it — list tables, run SELECTs, whatever that connection allows.

Isn't: Your database password. On Synra that stays encrypted server-side. A stolen laptop with mcp.json is a gateway token problem; it shouldn't dump your Neon or RDS password onto disk.

Also isn't: Safe to share because it's HTTPS. TLS stops wire snooping. It does nothing about a screenshot in #engineering.

If the gateway is read-only, a leak is still a read incident — schema, row samples, whatever that DB user can see. Better than a drop-table. Not harmless.

How these URLs actually leak

Same places API keys leak, just dressed as a path:

Committed mcp.json. Project-level .cursor/mcp.json in a public or widely cloned repo. Full token in git history.
Slack / Discord / Linear. "Here's the connector so you can try it" — then it's searchable forever.
Screenshots and Loom videos. Setup demos that zoom the Endpoints tab or a Claude connector dialog.
Support tickets and GitHub issues. Pasting "full config" to debug a red status.
Shared staging that became production. One URL for the company, never rotated, still pointed at a replica with real customer rows.

The token looks like a path segment, not sk_live_..., so it gets treated like a boring link.

Rules that prevent most of the damage

1. Don't put real tokens in git.
Global ~/.cursor/mcp.json for personal machines. If you need per-project config in the repo, use a local override or a secret manager — not the live URL in a tracked file. Same idea as .env.

2. One environment, one clear name.
staging-app and prod-replica as separate Synra connections (and separate endpoint URLs). Naming won't stop a leak, but it stops "I thought this was staging" after the leak.

3. Share access, not the token, when you can.
Have teammates create their own endpoint for the same staging DB (or join the Synra org) instead of DMing one URL to five people. When someone leaves, you know which URL to kill — or you have less surface area to rotate.

4. Prefer staging endpoints for demos.
Workshop, blog screenshot, onboarding buddy: throwaway branch or thin staging data. Don't teach the habit on production.

5. Rotate if the URL is widely held.
Solo staging toy? Skip the calendar invite. Ten contractors with the prod-replica URL in three clients? Rotate when people leave, and periodically if you can't keep a list.

If it leaked — do this in order

Rotate in the dashboard. On Synra: Endpoints → regenerate. Old URL should stop working immediately.
Update every client. Cursor (mcp.json), Claude connector, ChatGPT connector, CI if somehow it lived there. Miss one and rotation was theater.
Check audit logs. Queries you don't recognize — time, tool, SQL shape. Tells you whether the leak was used.
Scrub the paste. Delete the Slack message, close the gist, purge the issue. For git: rotate first, then history cleanup / secret scanning if the repo was public.
Decide if the DB user needs rotation too. Gateway token ≠ DB password. If you also pasted a connection string, rotate that separately.

Write the postmortem after the old URL is dead.

Browser checks aren't the enemy

Troubleshooting guides (including ours) say: open the endpoint in a browser; a JSON-RPC error means the host is up. That's a reachability check — not permission to publish the URL.

Do it on your machine. Don't drop the same link on a public status page "so others can verify."

How this fits with read-only and staging-first

Three different jobs:

| Control | Stops | |--------|--------| | Staging-first | Hitting the wrong environment | | Gateway + SELECT-only | Mutations | | Endpoint hygiene | The wrong people getting a working URL |

You want all three. Read-only staging URL in Slack: annoying. Read-only production URL in a public repo: disclosure. Write-capable URL anywhere: incident.

Client-specific notes

Cursor. Tokens often live in mcp.json. Treat that file like .env. Per-project copies are handy and easy to commit by mistake — prefer global or a gitignored local file.

Claude. Custom connector stores the URL in Claude's settings. After you rotate Synra, edit or recreate the connector. The old connector still holds the old token.

ChatGPT. Same under Developer mode custom connectors. Update or recreate after rotation; it won't pick up a new URL on its own.

Paste-the-URL walkthroughs: Cursor + Postgres, Claude + Postgres, ChatGPT.

Keeping the database password out of the IDE is a real win. Don't undo it by treating the gateway URL as setup fluff. It's a secret that looks like a link.

First-time Synra setup: make a staging connection, paste the endpoint into your client once, keep it out of git. Free trial at mcpserver.design — then run the read-only verification test before you share anything with the team.

Related reading:

Why Read-Only AI Database Access Matters — mutation risk and how to verify blocks
What Your AI Query Audit Log Is For — Usage logs after a leak or weird answer
Staging First: AI Database Access Without Production — environment ladder
When Not to Connect AI to Your Database — when you shouldn't share an endpoint at all
MCP Troubleshooting — when the client can't see tools (without pasting secrets into issues)
Self-Hosted vs Managed MCP Server — where credentials live
What is an MCP Server? — protocol basics
Can AI Actually See Your Data? — live access overview