Service discovery for MCPs

[positiveblue]

First of all thank you very much for developing and open sourcing this protocol. I think this is a significant step forward for creating interoperable systems, particularly for AI agents interacting with/consuming external tools.

Current state and limitations

In the current state MCP provides:

• A standardized framework for integrating external tools and data sources with LLMs.
• Robust features for managing context, resources, tools, and prompts.

However, there is no built-in mechanism for service discovery which means that agents are limited to interacting only with services they are already aware of.

We have been working for a while on a protocol that overlaps with MCP and we solved that limitation using a custom URI that the agent can use to identify compatible services, retrieve their metadata, and seamlessly integrate with them.

That would allow flows like pasting a URI in a chat and having the LLM decide if it needs to integrate with that tool, when to use it etc... (ofc, security is important here so things like SSL may be critical here). You can see an example of it working here.

Proposed Enhancement

Introduce a custom URI scheme, such as mcp://, to enable:

1. Service Identification: AI agents can distinguish MCP-compatible services from others.
2. Metadata Access: Agents can retrieve metadata (e.g., service type, documentation, endpoints) about the service.
3. Dynamic Integration: Use metadata to dynamically connect to and interact with services.

Example Workflow:

1. Discovery: An AI agent encounters a custom URI, e.g., mcp://api.myservice.com.

2. Metadata Retrieval: The agent resolves the URI and fetches detailed information about the service. For example, it performs an HTTP GET request to a predefined endpoint such as: https://api.myservice.com/llms.txt.

3. Metadata Structure: The service responds with a JSON or text file containing all relevant metadata, including:
   • Authentication: Supported methods for authenticating requests (e.g., API keys, OAuth).
   • Description: Overview of the service and its capabilities.
   • Supported Features: List of features/tools/resources offered by the service.
   • API Documentation: Link to full API documentation for deeper integrations.
   • Payment Information: Details about pricing, payment methods, or supported payment protocols.

4. Integration: Using the retrieved metadata, the agent:
   • Configures the necessary authentication and permissions.
   • Maps supported features to its workflow or capabilities.
   • Initiates interaction with the service, such as executing tools or subscribing to resources.

I would love to hear your thoughts on this and am happy to contribute further to its development if people find it useful.