MCP Server Cards Help Agents Reach Your Service
A customer finds your agent, likes what it offers, and wants to put it to work. Then comes the least impressive part of the exchange: asking someone for the connection address.
For all the ambition around agents working together, a missing MCP endpoint can still send a person back to a setup page or a support conversation. The agent may handle the work perfectly well once it reaches the service. First, someone gets to play receptionist.
MCP Server Cards address the gap between finding a service and connecting to it. On October 6, 2026, the MCP project merged SEP-2127, establishing an optional extension for publishing connection information before a client connects. For a customer choosing an agent service, the promise is straightforward: spend less time arranging the introduction and more time using the service.
MCP Server Cards tackle the missing connection
An MCP server already has ways to tell a connected client about its tools. The awkward part comes earlier. A client cannot ask a server for much of anything while it is still looking for the server.
A Server Card puts the address, supported transports, and protocol versions into a document software can read before connecting. A client implementing the extension can use the information to work out where and how to connect, instead of leaving someone to interpret a setup paragraph and copy the address into a settings screen.
The extension remains optional, and the implementation repository still labels its schema experimental. Clients supporting Server Cards gain the discovery route; other clients continue using configured endpoints. As clients adopt the extension, more of the connection work can move out of the customer’s hands.
AI Catalogs bring separate MCP services together
A business can offer several services without running all of them itself. Booking software may come from one provider, hiring software from another. Customers still recognize one business, even when the software behind it comes from several companies.
The Server Card charter’s restaurant example addresses exactly such an arrangement. The restaurant advertises reservation and job-listing services through an AI Catalog, while separate providers host the corresponding Server Cards. The catalog introduces the collection; each card carries the connection details for a particular service.
For the customer’s agent, the catalog offers a starting point. It can discover the services a business advertises and, with Server Card support, obtain the relevant connection information. The restaurant’s choice of software suppliers can stay backstage. The customer came to book a table.
Keeping the cards with their providers also gives the connection information an obvious owner. The reservations provider maintains the card for its service; the hiring provider maintains its own. The discovery design permits cards on separate hosts, so the business can bring the services together without moving them all into one system.
A catalog entry points toward a service. The live connection still determines what the caller can do there, which explains one of the more deliberate omissions in the Server Card format.
Why MCP Server Cards leave out the tools
Server Cards leave tool, resource, and prompt lists out of the public document. A longer card might look more informative, but a fixed list cannot reliably describe a server whose available operations change with the caller, account permissions, or deployment.
A provider may enable a feature for some accounts before offering it to everyone. A release may add an operation or remove an older one. Publishing every variation in a static card turns discovery into a second inventory of the service, with another opportunity to fall behind.
The extension leaves those answers to live MCP discovery. The card supplies enough information to attempt a connection; the connected server supplies the current operations for the caller. Authentication and service-side permissions still govern access. The card can give directions without pretending to know everyone’s business.
The result is a shorter first introduction. The card helps the agent reach the service; the service supplies the account-specific answers once the caller connects. Packing every possible operation into the introduction makes the card longer without making the answer more dependable.
For a service with a HeadlessDomains.com identity, agent.json connects its public name with published service information. Server Cards add a separate MCP discovery route for clients implementing the extension. The guide to publishing MCP endpoints in agent.json covers connecting a working endpoint to the public identity.
Server Cards move the conversation forward from there: a discoverable service can also tell supporting clients how to reach it. The customer came for the service. Finding the address can take up less of the conversation.