Version-Aware Discovery For MCP APIs In Python SDK

Nov 25, 2025 by Alex Johnson 51 views

Introduction

In this article, we will delve into the concept of version-aware discovery for list_tools and related MCP (Model Context Protocol) APIs within the Python SDK. This discussion revolves around enhancing the MCP Python SDK, and where applicable, the underlying MCP protocol and server behavior, to support a more robust and stable interaction between clients and servers. The primary goal is to empower clients to request discovery results for a specific server or tool manifest version, ensuring a consistent and predictable experience. Version-aware discovery is a crucial feature for maintaining stability and reliability in systems that dynamically query and utilize available tools and resources. This article will explore the motivations, proposed behaviors, potential API shapes, and open questions surrounding the implementation of this feature. By addressing these aspects, we aim to provide a comprehensive understanding of how version-aware discovery can benefit both clients and servers in the MCP ecosystem. This includes detailed insights into how clients can leverage this feature to ensure compatibility, and how servers can evolve more confidently without disrupting existing consumers.

The Need for Version-Aware Discovery

Many MCP clients utilize dynamic queries to list_tools and similar APIs to enumerate available tools, inspect parameter schemas, and infer capabilities from descriptions or metadata. While this approach works well initially, the current unversioned behavior poses challenges in maintaining stability over time. To understand the version-aware discovery's importance, imagine a scenario where a client relies on the presence or absence of specific tools in the list_tools response. If a new tool is introduced, it can subtly alter the client's behavior, leading to unexpected outcomes. Similarly, breaking changes in tool schemas or descriptions, such as renaming fields or removing parameters, can disrupt existing clients built against the previous schema. Without a mechanism to specify a target version, clients lack a clean way to express, "I support server/tool manifest version X" and expect discovery to reflect that contract. These challenges often result in clients implementing ad-hoc version-pinning workarounds, while servers become more conservative in evolving tools for fear of breaking unknown consumers. This conservative approach can stifle innovation and delay the adoption of new features. The risk of silent breakages also increases with each change to discovery, making it difficult to maintain a stable ecosystem. Therefore, a version-aware discovery model is essential to provide clients with the ability to pin themselves to a known stable tool surface, allowing servers to evolve tools and descriptions more confidently, and enabling the ecosystem to adopt a more explicit, opt-in model for new capabilities.

Motivation and Problem

The core motivation behind implementing version-aware discovery stems from the inherent limitations of the current unversioned system. Consider the impact of new tools appearing in list_tools. If clients select tools based on presence/absence or ranking logic, the addition of a new tool can inadvertently change their behavior. For instance, a client might prioritize a newly added tool over an existing one, even if the existing tool is better suited for the task. This can lead to unpredictable outcomes and make it challenging to maintain consistent behavior across different deployments. Furthermore, breaking changes in tool schemas or descriptions can have severe consequences for existing clients. Imagine a client that relies on a specific parameter shape or field name. If the server changes the schema without providing a mechanism for versioning, the client will likely encounter errors or unexpected behavior. This can result in significant downtime and require extensive debugging efforts. The lack of a clean way for clients to specify their supported server/tool manifest version exacerbates these issues. Without versioning, clients have no way to ensure that they are interacting with a compatible version of the server. This forces them to implement ad-hoc version-pinning workarounds, which can be complex and error-prone. Servers, on the other hand, are forced to be more conservative in evolving tools, as they fear breaking unknown consumers. This can hinder innovation and prevent the ecosystem from adopting new capabilities. The risk of silent breakages also increases whenever discovery changes. Because clients have no way to specify their version requirements, they may unknowingly interact with incompatible versions of the server, leading to unexpected errors or data corruption. Version-aware discovery addresses these issues by providing a stable, versioned contract for discovery-based behavior. This allows clients to pin themselves to a known stable tool surface, while also enabling servers to evolve tools and descriptions more confidently. By adopting a more explicit, opt-in model for new capabilities, the ecosystem can benefit from increased stability and innovation.

Consequences of the Current Unversioned Behavior

The current unversioned behavior in MCP can lead to several undesirable consequences. Clients may resort to implementing their own ad-hoc version pinning workarounds, which can be complex, inconsistent, and difficult to maintain. These workarounds often involve hardcoding tool names, schemas, or descriptions, making the client less adaptable to changes in the server. Moreover, servers tend to be more conservative in evolving tools, fearing the potential of breaking unknown consumers. This conservatism can stifle innovation and prevent the ecosystem from adopting new capabilities. For example, if a server wants to introduce a new feature or improve an existing tool, it must carefully consider the impact on existing clients. If the server cannot guarantee compatibility with older clients, it may be forced to delay or abandon the change. The risk of silent breakages is another significant concern. When discovery changes, clients that are not aware of the changes may unknowingly interact with incompatible versions of the server. This can lead to unexpected errors, data corruption, or even security vulnerabilities. Silent breakages are particularly problematic because they can be difficult to detect and diagnose. They may not manifest immediately, and they may only occur under certain conditions. This makes it challenging to identify the root cause and implement a fix. A version-aware discovery model mitigates these issues by providing a clear contract between clients and servers. Clients can specify the version of the server or tool manifest that they support, and the server can ensure that it returns only compatible tools and schemas. This reduces the risk of breakages and allows servers to evolve more confidently.

Proposed Behavior for Version-Aware Discovery

At a conceptual level, the proposed behavior for version-aware discovery involves several key components. The first component is the separation of version domains. The MCP server exposes a server/manifest version (e.g., semver), while individual tools and/or tool manifests can also have their own semantic versions. The server tracks, for each server/manifest version, which tool versions were part of that snapshot. This allows for fine-grained versioning and ensures that clients can request specific versions of tools and their associated schemas. The second component is the introduction of version-aware discovery APIs. The list_tools API, along with potentially list_prompts and list_resources, accepts an optional version parameter. This parameter can be generic (version) or more explicit (server_version / manifest_version). If no version is provided, the behavior is identical to the current system, where the server returns the latest set of tools and schemas. However, if a version is provided, the server only returns tools that existed for that version, with each tool's schema and description matching what was valid for that version. Tools introduced after the specified version are not listed, while tools removed after that version but present at that time are still listed. This ensures that clients receive a consistent snapshot of the tools and schemas as they existed at the requested version. The third component is backward compatibility. Servers that do not yet support version-aware discovery can safely ignore the version parameter, and clients should treat this as equivalent to requesting the latest version. This allows for a smooth transition to version-aware discovery without breaking existing clients. Once protocol support exists, servers can start honoring the parameter without disrupting older clients. This approach ensures that the system remains functional and reliable during the migration process. Overall, the proposed behavior for version-aware discovery provides a flexible and robust mechanism for clients and servers to interact in a versioned environment. This enhances stability, facilitates innovation, and promotes a more explicit and opt-in model for new capabilities.

Key Components of the Proposed Behavior

The proposed behavior for version-aware discovery comprises three essential components that work together to ensure a stable and predictable interaction between clients and servers. Let's examine these components in detail:

Separate Version Domains: This component establishes a clear distinction between the versions of the MCP server and the individual tools or tool manifests. The MCP server exposes a server/manifest version, typically following semantic versioning (semver) principles. This version represents the overall compatibility and functionality of the server itself. Simultaneously, individual tools and tool manifests can have their own semantic versions. This allows for independent evolution of tools without necessarily requiring a change in the server version. The server maintains a mapping between server/manifest versions and the corresponding tool versions that were part of that snapshot. This mapping is crucial for ensuring that clients can request a specific server version and receive the correct set of tools and schemas that were available at that time. By separating version domains, the system gains flexibility and granularity in managing compatibility and evolution. It allows for incremental updates to tools without requiring a full server upgrade, and it provides clients with the ability to target specific versions of tools based on their needs.
Version-Aware Discovery APIs: This component introduces the necessary modifications to the discovery APIs to support versioning. The list_tools API, along with potentially list_prompts and list_resources, is extended to accept an optional version parameter. This parameter can be generic, such as version, or more specific, such as server_version or manifest_version. The choice of parameter name depends on the desired level of explicitness and the specific use case. When no version is provided, the behavior remains identical to the current unversioned system. The server returns the latest set of tools and schemas, ensuring backward compatibility. However, when a version is provided, the server's behavior changes significantly. It filters the list of tools to include only those that existed for the specified version. Furthermore, it ensures that each tool's schema and description match what was valid for that version. This is crucial for maintaining consistency and preventing breakages. Tools introduced after the specified version are excluded from the response, and tools removed after that version but present at that time are still listed. This ensures that clients receive a complete and accurate snapshot of the tools and schemas as they existed at the requested version. The version-aware discovery APIs provide a powerful mechanism for clients to target specific versions of the server and its tools, enabling them to maintain compatibility and avoid unexpected behavior.
Backward Compatibility: This component ensures a smooth transition to version-aware discovery without disrupting existing clients or servers. Servers that do not yet support version-aware discovery can safely ignore the version parameter. This is a key aspect of the design, as it allows for incremental adoption of the feature without requiring a simultaneous upgrade of all components. Clients, on the other hand, should treat the case where the version parameter is ignored as equivalent to requesting the latest version. This ensures that older clients continue to function correctly even when interacting with newer servers that support versioning. Once protocol support for versioning is in place, servers can start honoring the version parameter without breaking older clients. This gradual rollout strategy minimizes the risk of disruption and allows for a controlled migration to the new system. Backward compatibility is essential for the success of any new feature, and it is particularly important in a distributed system like MCP, where clients and servers may be deployed and upgraded independently. By ensuring backward compatibility, the version-aware discovery model can be adopted incrementally and without causing widespread disruptions.

Implications for Tool and Schema Management

The introduction of version-aware discovery has significant implications for how tools and schemas are managed within the MCP ecosystem. It necessitates a more structured approach to versioning and maintaining historical snapshots of tool definitions. Servers need a mechanism to track which tools and schemas belong to a given version. This could involve using Git tags to map to manifest versions, maintaining explicit versioned manifest files, or implementing a server-managed registry of tool versions. Each of these approaches has its own trade-offs in terms of complexity, performance, and scalability. The choice of mechanism will depend on the specific requirements and constraints of the server implementation. Regardless of the mechanism used, it is crucial that the server can accurately reconstruct the state of the system at any given version. This ensures that clients can reliably request specific versions and receive the correct set of tools and schemas. Furthermore, version-aware discovery encourages developers to adopt a more disciplined approach to schema evolution. When making changes to a tool's schema, developers should consider the potential impact on existing clients. If a change is breaking, it may be necessary to introduce a new version of the tool or provide a migration path for clients to upgrade. This requires careful planning and communication to ensure a smooth transition. Versioning also enables servers to deprecate older tools or schemas. By providing a clear deprecation policy and communicating it to clients, servers can eventually remove outdated functionality without causing disruption. Clients can then migrate to newer versions of the tools or schemas at their own pace. Overall, version-aware discovery promotes a more mature and sustainable approach to tool and schema management. It provides the necessary infrastructure for clients and servers to evolve independently while maintaining compatibility and stability. This ultimately leads to a more robust and resilient ecosystem.

Potential API Shape in Python SDK

Assuming a Python SDK client similar to a hypothetical MCPClient, the API for version-aware discovery could be designed to be both intuitive and flexible. The existing discovery methods, such as client.list_tools(), client.list_prompts(), and client.list_resources(), could be extended to accept an optional version parameter. This parameter would allow clients to specify the desired server/manifest version for the discovery results. The default behavior, when no version is provided, would remain the same: the server returns the latest set of tools and schemas. This ensures backward compatibility and simplifies the transition to version-aware discovery. To provide additional flexibility, the version parameter could accept both string representations of versions (e.g., "1.2.0") and more structured version types. A dedicated Version helper class, potentially within the mcp.versioning module, could be used to parse, validate, and compare versions. This would allow clients to express version requirements in a more type-safe and expressive manner. For example, a client could use the Version class to specify a version range or to compare versions for compatibility. In addition to the version parameter, discovery responses could optionally include metadata about the resolved version used by the server. This would allow clients to verify that the server is using the expected version and to log or enforce version constraints. For example, if a client requests version "1.2" and the server resolves to "1.2.3", the response could include this information in a metadata field. This metadata can be invaluable for debugging and troubleshooting, as it provides a clear indication of the actual version used by the server. The Python SDK could also provide additional helpers for tasks such as fetching server capabilities, negotiating a compatible version, and caching the chosen version for subsequent discovery calls. These helpers would simplify the process of interacting with versioned servers and make it easier for clients to implement version-aware discovery. Overall, the potential API shape in the Python SDK aims to provide a balance between simplicity, flexibility, and type safety. It builds upon the existing discovery methods, extends them with a version parameter, and provides additional helpers for advanced use cases. This design allows clients to easily adopt version-aware discovery while maintaining backward compatibility and a consistent API experience.

Code Examples and Explanation

To illustrate the potential API shape in the Python SDK, let's consider some code examples that demonstrate how clients could use the version-aware discovery features. First, let's look at how a client might retrieve the latest tools, which is the default behavior:

from mcp import MCPClient

client = MCPClient(...)

# Current behavior: latest tools
tools_latest = client.list_tools()

In this example, the client simply calls the list_tools() method without any arguments. This will return the latest set of tools and schemas available on the server, just as it does in the current unversioned system. Next, let's see how a client can explicitly pin to a known server/manifest version:

# Explicitly pin to a known server/manifest version
tools_v1 = client.list_tools(version="1.2.0")

Here, the client passes a version string ("1.2.0") to the version parameter of the list_tools() method. This instructs the server to return only the tools and schemas that were available in version 1.2.0. This allows the client to ensure compatibility with a specific version of the server and avoid unexpected behavior due to changes in later versions. For more structured typing and version management, the Python SDK could provide a Version helper class:

from mcp.versioning import Version

target_version = Version.parse("1.2.0")
tools_v2 = client.list_tools(version=target_version)

In this example, the client uses the Version.parse() method to create a Version object from a version string. This Version object can then be passed to the version parameter of the list_tools() method. Using a dedicated Version class provides several benefits, including type safety, version validation, and the ability to perform version comparisons. The Version class could also provide methods for parsing version ranges, comparing versions, and performing other version-related operations. These examples demonstrate how the Python SDK could provide a flexible and intuitive API for version-aware discovery. The version parameter allows clients to easily specify the desired server/manifest version, while the Version helper class provides additional functionality for advanced version management.

Potential Changes and Helpers in the SDK

To fully support version-aware discovery, the Python SDK may require several changes and additions. These can be broadly categorized into client methods, version types/utilities, and metadata on responses. Client methods would need to be extended to accept an optional version parameter. This would involve modifying the existing discovery methods, such as client.list_tools(), client.list_prompts(), and client.list_resources(), to include a version parameter with a default value of None. The type of the version parameter could be Optional[str | Version], allowing clients to pass either a string representation of a version or a Version object. Version types/utilities would provide a way to parse, validate, and compare versions. A small Version helper class, or a re-export of a standard semver type, could be introduced for this purpose. The Version class would provide methods for parsing version strings, validating version syntax, comparing versions using operators such as <, <=, >, and >=, and potentially representing version ranges. This would make it easier for clients to express version requirements and ensure compatibility with specific server versions. Metadata on responses could be used to include information about the resolved version used by the server. Discovery responses could optionally include a field indicating the version that the server actually used to generate the response. This would be particularly useful in cases where the client requests a version range or a wildcard version. For example, if a client requests version "1.2" and the server resolves to version "1.2.3", the response metadata could include the string "1.2.3". This would allow the client to verify that the server used the expected version and to log or enforce version constraints. In addition to these core changes, the SDK could also provide other helpers to simplify the process of version-aware discovery. These helpers could include functions for fetching server capabilities, negotiating a compatible version, and caching the chosen version for subsequent discovery calls. Overall, the potential changes and helpers in the SDK aim to provide a comprehensive and user-friendly API for version-aware discovery. By extending the existing discovery methods, providing version types/utilities, and including metadata on responses, the SDK can empower clients to effectively manage version compatibility and ensure a stable interaction with MCP servers.

Open Questions and Considerations

Implementing version-aware discovery raises several open questions and considerations that need to be addressed to ensure a robust and effective solution. These questions span various aspects, from the specification of the protocol to the rollout strategy and the consistency across different discovery endpoints. Addressing these questions thoughtfully is crucial for designing a system that is not only functional but also maintainable, scalable, and easy to use. Let's delve into some of the key areas of consideration:

Spec vs. SDK Boundaries

One of the fundamental questions is how to divide the responsibilities between the MCP protocol specification and the Python SDK. Specifically, how should the version parameter be represented in the MCP protocol itself? Should it be a transport-level field, included in the header or metadata of the request, or a higher-level option within the request payload? Each approach has its trade-offs. A transport-level field might be more efficient and easier to handle at the protocol level, but it could also be less flexible and harder to evolve. A higher-level option, on the other hand, might provide more flexibility but could add complexity to the parsing and processing of requests. Another critical aspect is determining what the version is attached to. Is the version associated with the server as a whole, with a specific manifest, or with something else entirely? The answer to this question will influence how the server tracks and manages versions, and how clients specify their version requirements. If the version is attached to the server, it simplifies the versioning model but might limit the ability to evolve tools and schemas independently. If the version is attached to a manifest or individual tools, it provides more granularity but could also increase the complexity of the system. The protocol also needs to define how versions are represented. Should it define a strongly-typed semver structure, ensuring consistency and comparability of versions, or leave it as a string with recommended semantics, providing more flexibility but potentially leading to inconsistencies? A strongly-typed structure would make it easier to perform version comparisons and range checks, but it might also be more rigid and less adaptable to different versioning schemes. Leaving it as a string would allow for more flexibility but would require clients and servers to agree on a common interpretation of the version string. These decisions regarding the spec vs. SDK boundaries will have a significant impact on the overall design and implementation of version-aware discovery.

Source of Truth for Version Snapshots

How does the server determine which tools and schemas belong to a given version? This is a critical question that directly impacts the accuracy and reliability of version-aware discovery. The server needs a mechanism to track the state of the system at different points in time and to reconstruct that state when a client requests a specific version. Several approaches can be used, each with its own advantages and disadvantages. One option is to use Git tags to map to manifest versions. This approach leverages the version control system to track changes to the tool manifests and to create snapshots of the system at specific points in time. When a client requests a version, the server can simply check out the corresponding Git tag and use the manifests in that tag to generate the discovery response. This approach is relatively simple to implement and provides a clear audit trail of changes. However, it might not be suitable for large systems with frequent changes, as checking out Git tags can be time-consuming. Another option is to maintain explicit versioned manifest files. This approach involves creating a separate manifest file for each version of the system. These manifest files would contain the definitions of the tools and schemas available in that version. When a client requests a version, the server can simply load the corresponding manifest file and use it to generate the discovery response. This approach is more efficient than using Git tags, but it requires more effort to maintain the manifest files. A third option is to implement a server-managed registry of tool versions. This approach involves storing the tool and schema definitions in a database or other persistent storage, along with their associated versions. The server can then query the registry to retrieve the tools and schemas that belong to a specific version. This approach provides the most flexibility and scalability, but it also requires the most effort to implement and maintain. The SDK should not need to know the internal mechanism used by the server to track version snapshots. However, the spec likely needs to define expectations about how the server should handle versioning and how it should ensure the consistency and accuracy of versioned discovery responses. The choice of the source of truth for version snapshots is a critical decision that will impact the performance, scalability, and maintainability of the version-aware discovery system.

Defaulting and Negotiation

In a versioned system, it's essential to consider how clients discover the latest supported version and their own minimum/maximum supported versions. This is particularly important for ensuring compatibility and preventing clients from interacting with servers that are too old or too new for them. One approach is to extend a handshake or capabilities mechanism to include version ranges. Clients and servers could exchange information about their supported versions during the initial connection, allowing them to negotiate a compatible version to use for subsequent interactions. This would provide a robust and automated way to ensure compatibility. Another question is whether the Python SDK should expose a helper to fetch server capabilities, negotiate a compatible version, and cache the chosen version for subsequent discovery calls. Such a helper would simplify the process of version negotiation and make it easier for clients to implement version-aware discovery. The helper could encapsulate the logic for fetching server capabilities, comparing version ranges, and selecting a compatible version. It could also provide caching mechanisms to avoid repeated version negotiation calls. Defaulting behavior is another important consideration. What should happen if a client requests a version that is not supported by the server? Should the server return an error, or should it default to the latest supported version? The choice of defaulting behavior will depend on the specific requirements of the system. Returning an error would provide a clear indication that the requested version is not supported, but it might also break existing clients that do not expect this behavior. Defaulting to the latest supported version would ensure backward compatibility, but it might also lead to unexpected behavior if the client is not compatible with the latest version. A hybrid approach could be used, where the server returns a warning indicating that the requested version is not supported but still defaults to the latest version. This would provide a balance between backward compatibility and clear error reporting. The design of the defaulting and negotiation mechanisms is crucial for ensuring a smooth and reliable experience for clients using version-aware discovery.

Migration and Rollout Strategy

Introducing version-aware discovery requires a careful migration and rollout strategy to avoid disrupting existing servers and clients. A key principle is to ensure that if the version parameter is omitted or unsupported, the system behaves exactly as it does today. This backward compatibility is essential for allowing clients and servers to upgrade incrementally without breaking existing functionality. Servers that do not yet support version-aware discovery should simply ignore the version parameter, and clients should treat this as a request for the latest version. This allows servers to be upgraded at their own pace, without requiring a simultaneous upgrade of all clients. Another important consideration is whether servers should be encouraged to start tagging versions even before they fully implement historical snapshots. This would allow clients to start using the version parameter in their requests, even if the server is not yet able to provide versioned responses. The server could simply return the latest version of the tools and schemas, but it would also include metadata indicating that the request was processed using the latest version. This would allow clients to verify that the server is behaving as expected and to prepare for the eventual implementation of full version-aware discovery. A gradual rollout strategy is also crucial. Version-aware discovery could be introduced in phases, starting with a small subset of tools or schemas and gradually expanding to the entire system. This would allow the team to identify and address any issues before they affect a large number of clients. Monitoring and logging are also essential during the rollout process. The server should log all requests that include the version parameter, and it should track the versions requested and the versions actually used to generate the responses. This data can be used to identify potential compatibility issues and to measure the adoption of version-aware discovery. A well-planned migration and rollout strategy is crucial for the successful adoption of version-aware discovery. By ensuring backward compatibility, encouraging early adoption of version tagging, and implementing a gradual rollout strategy, the team can minimize the risk of disruption and maximize the benefits of this new feature.

Consistency Across Discovery Endpoints

Consistency across different discovery endpoints is crucial for ensuring a cohesive and predictable experience for clients using version-aware discovery. A fundamental question is whether list_tools, list_prompts, and list_resources should all share the same version parameter and semantics. Using a consistent versioning scheme across all discovery endpoints simplifies the API and makes it easier for clients to understand and use. It also reduces the risk of inconsistencies and unexpected behavior. If each endpoint had its own version parameter and semantics, clients would need to learn and manage multiple versioning schemes, which would add complexity and increase the likelihood of errors. Furthermore, it's essential to consider whether there are other discovery-like APIs where version-awareness would be valuable. Any API that returns a list of resources or capabilities that can change over time is a candidate for versioning. This could include APIs for listing available models, data sources, or other types of assets. Applying version-awareness consistently across all such APIs would provide a unified and predictable versioning experience for clients. Maintaining consistency across discovery endpoints also simplifies the implementation and maintenance of the server. A single versioning mechanism can be used for all endpoints, reducing the amount of code that needs to be written and tested. It also makes it easier to reason about the behavior of the system and to troubleshoot issues. However, there might be cases where different discovery endpoints have different versioning requirements. For example, one endpoint might need to support more granular versioning than another. In such cases, it might be necessary to deviate from the consistent versioning scheme. However, any such deviations should be carefully considered and documented to avoid confusion and ensure that clients understand the versioning behavior of each endpoint. The goal should be to maintain consistency across discovery endpoints whenever possible, while also allowing for flexibility when necessary. This will provide a balance between simplicity, predictability, and adaptability. Consistency across discovery endpoints is a key factor in the usability and maintainability of the version-aware discovery system.

Conclusion

In conclusion, version-aware discovery is a critical enhancement for the MCP Python SDK and its underlying protocol. By enabling clients to specify the server or tool manifest version they are targeting, it provides a stable and predictable environment for interacting with MCP APIs. This capability addresses the challenges posed by unversioned discovery, such as silent breakages and the need for ad-hoc version pinning workarounds. The proposed behavior, potential API shape, and open questions discussed in this article lay a solid foundation for implementing version-aware discovery in a robust and scalable manner. By carefully considering the spec vs. SDK boundaries, the source of truth for version snapshots, the defaulting and negotiation mechanisms, the migration and rollout strategy, and the consistency across discovery endpoints, we can create a system that benefits both clients and servers. This will empower clients to confidently adopt new features and servers to evolve their tools and schemas without fear of breaking existing integrations. As the MCP ecosystem continues to grow and evolve, version-aware discovery will play a vital role in ensuring its stability, reliability, and long-term success. Further research and collaboration are essential to refine the design and implementation of this feature. The goal is to create a version-aware discovery system that is not only functional but also easy to use, easy to maintain, and adaptable to the evolving needs of the MCP community. By addressing the open questions and considerations outlined in this article, we can pave the way for a more robust and sustainable MCP ecosystem. For more information on semantic versioning and best practices, visit semver.org.