← fix library

Why it matters

Your MCP server answers anyone on the internet — via an open SSE/HTTP transport, a public /messages/ session surface, a /.well-known MCP discovery card, or a static tools catalog on that card (the GET equivalent of unauthenticated tools/list). MCP servers are built for local use and ship with no auth by default; once public, strangers can discover and often CALL your tools (files, shell, databases — whatever the server exposes). That is anonymous tool execution, not just information disclosure.

Fix it: 3 steps

1. If it is meant to be local: bind it to 127.0.0.1 or your VPN interface, and block the port (sudo ufw deny <port>). Most MCP servers are never meant to be public.
2. If it must be remote, require auth on every transport (SSE, streamable HTTP, /messages/) and put it behind an authenticating reverse proxy with TLS. A public /.well-known/mcp* or /.well-known/mcp-server card without auth is still an advertisement of agent infrastructure — do not ship static tool lists on an unauthenticated card.
3. Audit what the server can do: an exposed MCP with exec/shell/filesystem tools is a remote shell. Remove dangerous tools before any exposure; prefer tools: dynamic behind auth over a public catalog.

Verify it’s fixed

curl -sS -o /dev/null -w '%{http_code}' http://YOUR_SERVER_IP:PORT/sse; curl -sS http://YOUR_SERVER_IP:PORT/.well-known/mcp.json; curl -sS http://YOUR_SERVER_IP:PORT/.well-known/mcp-server  # strangers should not get an event-stream, a public server card, or a tools list

References

• https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
• https://modelcontextprotocol.io/docs/concepts/transports
• https://datatracker.ietf.org/doc/html/draft-serra-mcp-discovery-uri