Hello,
I'm GT (Edge), a developer from Korea working on building the ecosystem around remote MCP servers and clients.
While working with remote MCP servers that involve authentication, I’ve been thinking through a few challenges and would like to share a suggestion that might help improve the developer experience.
Summary
It might be helpful for an MCP server to expose a self-describing list of available resources even before authentication, to support discoverability and integration.
Background
The MCP server specification is evolving rapidly, now supporting secure remote access using OAuth 2.1.
While this strengthens security, it also introduces limitations: currently, an MCP server does not expose its capabilities until the client authenticates.
This presents friction for developers who want to integrate or test a new server. Without prior authentication, there is no way to know what the server offers, which goes against the idea of self-describing and discoverable services.
Problem
- Clients cannot explore what an MCP server offers without authenticating first
- This breaks the principle of self-describing servers
- Pre-auth discovery is not possible, making integration harder and slower
- Developers must rely on out-of-band knowledge or documentation to use a server
Proposal
MCP servers could support an optional, unauthenticated endpoint that exposes a limited, read-only list of available resources. This would allow host applications to understand the server’s capabilities before authentication and registration.
Suggested Endpoint Example
Benefits
- Improves discoverability for host applications
- Enables easier integration and auto-UI generation
- Maintains security, as sensitive resources can still require auth
Security Considerations
- This endpoint must never expose sensitive resource names, parameters, or logic
- Each resource should clearly indicate whether authentication is required
- The endpoint should be optional and configurable by the server owner
- Server administrators can limit or disable it entirely if desired
I'm sharing this with the hope that it sparks discussion.
There may be deeper principles or design goals behind the current approach that I'm not aware of, and I'd love to learn more. I’d really appreciate hearing your thoughts.
Hello,
I'm GT (Edge), a developer from Korea working on building the ecosystem around remote MCP servers and clients.
While working with remote MCP servers that involve authentication, I’ve been thinking through a few challenges and would like to share a suggestion that might help improve the developer experience.
Summary
It might be helpful for an MCP server to expose a self-describing list of available resources even before authentication, to support discoverability and integration.
Background
The MCP server specification is evolving rapidly, now supporting secure remote access using OAuth 2.1.
While this strengthens security, it also introduces limitations: currently, an MCP server does not expose its capabilities until the client authenticates.
This presents friction for developers who want to integrate or test a new server. Without prior authentication, there is no way to know what the server offers, which goes against the idea of self-describing and discoverable services.
Problem
Proposal
MCP servers could support an optional, unauthenticated endpoint that exposes a limited, read-only list of available resources. This would allow host applications to understand the server’s capabilities before authentication and registration.
Suggested Endpoint Example
Benefits
Security Considerations
I'm sharing this with the hope that it sparks discussion.
There may be deeper principles or design goals behind the current approach that I'm not aware of, and I'd love to learn more. I’d really appreciate hearing your thoughts.