Agenda

• Discuss re-inclusion of tools/other primitives in server card
• Where in the protocol / docs should we define Server Cards? Proposal: "Discovery" section prior to "Lifecycle". Implement the schema there as a draft in line with how all MCP schemas are defined (TS that transforms to JSON Schema)
• name relationship to placement of .well-known: is it fair to include some verbiage that says e.g. a server named com.github/github-mcp-server should have its .well-known URI at github.com/.well-known/mcp/server-json/github-mcp-server?
• What exactly is the scope of a reference implementation? Just the shapes? Auto-advertisement on the server-side? Auto-connection on the client-side? What's the MVP scope?
• Check in on alignment with AI card

Attendees

@dsp-ant, @tadasant, @SamMorrowDrums, Rodrigo

• Initial Feedback: Attendees noted community interest from Goodman and Vishnavi regarding the necessity of including tools and capabilities in the server card/server.json specification.
• Scoping Decisions: David and Tadas agreed to postpone the discussion on tools and cut the inclusion of authentication capabilities and required fields from the current scope to speed up the process of landing the server card specification.
• Configuration and Tool Variance: Sam suggested that prior to adding tools, there should be a mechanism in the protocol to communicate how configuration change can impact the set of available tools, noting this is currently an unsupported area of the protocol. David acknowledged this as a general complexity issue with MCP configuration, noting the forthcoming mcp.json proposal might address some local concerns.
• Server Card Placement in Protocol: The group determined that the Server Card should be defined as a extension, living outside the core spec, which will then be referenced in the main specification under a new "Discovery" section. This aligns with the long-term goal of shrinking the base protocol.
• Discovery and AI Catalog: David opposed constructing the Server Card URI from the server name, advocating instead for direct well-known URIs to prevent breaking changes. The team agreed on a "Plan B" to build an initial index—modeled on the AI Card Catalog—to enable discovery if the AI Catalog is not ready. David stressed the need for securing governance and veto rights over the AI Catalog (with respect to MCP) before relying on it.
• Reference Implementation: They decided that server-side SDKs should provide a way to generate the Server Card structure, allowing developers to either serve it statically or dynamically via a web framework route.

Action Items:

• David
  • Provide a reference implementation in one of the SDKs for generating and serving the Server Card.
  • Ensure catalog governance is secured with the AI Catalog group.
• Sam
  • Create the Plan B catalog index, using the AI Card Catalog structure, for use in case the AI Catalog is not ready.
• Tadas
  • Attend the upcoming AI Card meeting (joining after the first 15 minutes) to communicate the group's decisions.

Additional notes: https://docs.google.com/document/d/14256RUovRhHplMK5tPV2dWxF_uKug8a8ctdZxGvitRE/edit?tab=t.jrkf82r0n4k7#task=4gzecNwhgkO5sH0f