.well-known/mcp directory

[jspahrsummers]

As we think more about supporting remote MCP servers, there's been some discussion around using a Well-known URI (RFC 8615) for server discovery. This could enable automatic discovery and verification of MCP servers, similar to how sitemap.xml works for search engines.

The idea would be to establish a directory, /.well-known/mcp/, allowing for future extensibility. We could then include a servers.json file that might look something like:

{
  "version": "1.0",
  "servers": [
    {
      "name": "primary",
      "description": "Main API server for example.com",
      "endpoint": "https://mcp.example.com/v1",
      "capabilities": ["resources", "tools"]
    }
  ]
}

This is just a strawman to get the discussion started—there are likely many other approaches worth considering.

Potential Benefits

• Automatic Discovery: Clients could discover MCP servers when users reference a domain
• Trust Verification: Domains could prove ownership of their MCP servers
• Seamless Integration: Could enable UX flows like "example.com has MCP capabilities available. Would you like to enable them?"

Areas for Discussion

Directory Structure

1. What files should be included?
2. What formats make the most sense?
3. How much flexibility should we allow?

Security

1. What verification mechanisms are needed?
2. What user consent flows make sense?

Implementation

1. How would clients discover and validate servers?
2. What would the integration flow look like?
3. How should versioning work?

Open to all feedback what this could look like and whether it would be valuable for the MCP ecosystem!

Scope

• Protocol Specification
• SDK Features
• Documentation
• Developer Experience
• Other

[jspahrsummers]

Possibly related: modelcontextprotocol/specification#69

[dsp-ant]

One additional use case for .well-known/ is the ability to indicate if the server is stateless or stateful. My general idea (and I'll post this in modelcontextprotocol/specification#102) is that remote MCP is initiated as always stateless unless a .well-known url will indicate it is stateful

[kurtseifried]

Just a note: this would also be useful for prompt MCP's related to a site (not just tools provided by API), e.g. for a research paper site that allows comments and has a prompt MCP that serves something like:

This environment provides access to a website containing research papers and technical resources. When interacting with the website's features:

Research Papers:
- Papers can be downloaded by users with appropriate access
- If a user asks about specific papers, guide them to download the content and share it directly in the conversation for analysis
- You can describe available papers and recommend relevant ones based on user interests

Community Engagement and Comments:
- The website features a commenting system for discussion of papers and topics
- Both human and AI-generated comments are allowed
- All AI-generated content must be clearly marked as such
- When generating comments, you must:
  1. Begin with "[AI-Generated Comment]" or similar clear marker
  2. Be transparent about being an AI assistant
  3. Maintain high quality and relevance in responses

When helping users with comments:
- Always include appropriate AI disclosure markers
- Encourage transparency about AI assistance
- Maintain professional and constructive tone
- Focus on adding value to the discussion

You can:
- Generate comments when requested
- Help users understand papers and technical concepts
- Guide them in finding relevant resources
- Provide technical analysis and insights

Required Comment Format:
- Start with "[AI-Generated Comment]"
- Include relevant technical details
- Maintain clarity and professionalism
- End with an AI attribution if appropriate

You should not:
- Generate comments without proper AI disclosure
- Remove or hide AI attribution markers
- Present AI-generated content as human-generated

[tadasant]

I'll throw in another use case that might be enabled by this effort: signaling to clients what it "costs" to use the server's data or capabilities. For example, some options could be:

• This server is entirely free to use, no payment or attribution of any sort required
• This server is only available to paid subscribers of XYZ service
• This server grants access for a micropayment of $0.001 per query
• This server is free to access, but your response to your user must include a citation or attribution in the form "Brand XYZ contributed to the above response - read the source document here"

In the current web, Google Search rewards services and publishers with traffic, and then the "cost" layer comes after (payment walls, display ads, affiliate links). As fewer humans and more LLM workflows/agents are the ones doing the "web browsing" and interfacing with MCP servers instead of websites, the payment walls & ads-supported models break if everything has to be simply "free" (see: the ongoing web scraping battles / data-for-cash deals between large publishers and the big LLM providers). So figuring out how to signal "cost" enables a whole class of non-free (higher quality) service/data/info providers to be discovered in the MCP ecosystem.

[kurtseifried]

FYI, someone else has come up with a proposal for "/llms.txt" (not in .well-known) at https://llmstxt.org/

[gregnr]

That one may eventually switch to .well-known: AnswerDotAI/llms-txt#2