Should an MCP server hide its tool list until the user is authenticated?

For anything that is not a public integration, yes. Tool names and descriptions are a map of your backend, and there is no reason to hand that map to someone who has not proved who they are. For a public, read-only server it matters much less.

The simplest way is not to answer at all before sign-in. A remote server can require authorization on the whole endpoint, so an unauthenticated client gets a 401 and is sent through the OAuth flow the MCP authorization spec describes before it ever sees a tool. That works with clients that already support remote auth, which is most of the current ones.

If some tools are public and some are not, return the tool list based on who is asking: a small set before sign-in, the full set after. Clients are told the list changed through the tools list changed notification. Whatever you show, check permission again when a tool is actually called, because hiding a tool is not the same as protecting it.

Keep descriptions honest but plain. A tool can explain what it does for the user without naming internal systems, vendors or table names. Writing a short threat model for the server first makes these choices quicker, because you can see which names actually leak something.

Listings mentioned

• Authentication & Authorization Implementation Patterns · skill by wshobson
  Covers OAuth2, sessions and role-based access, the pieces you need to gate tools by who is signed in.
• Security Threat Model Skill · skill by mohitagw15856
  Writes a STRIDE threat model with trust boundaries, which shows what an exposed tool list actually reveals.
• MCP builder · skill by anthropics
  Guide to designing MCP servers and their tools, including how to name and describe tools clearly.

Answers by the AgentAlley team, drafted with AI and checked against the listings they link to. Not a real-person reply from the original thread.