MCP stability & versioning
The Model Context Protocol follows a fundamentally different stability model than traditional REST APIs. Understanding the distinction between functional capabilities and technical contracts is essential for building durable AI integrations.
Capabilities are guaranteed stable
Once a domain capability is exposed on the MCP server, it remains available. We do not arbitrarily retire or remove tools from MCP as long as the underlying property management functionality exists in etg24. An agent designed to process tenant inquiries or look up unit contracts can rely on those capabilities remaining accessible over the long term.
Schemas and contracts are dynamic by design
What changes dynamically is the underlying technical specification of a tool: input parameter names, schema structures, and payload shapes. MCP is architected as an active discovery protocol, not a static contract.
Hardcoding MCP tool names, endpoints, or input schemas in client code is an antipattern. If an agent bypasses dynamic discovery and hardcodes parameter names, it will break when the backend updates a tool definition.
Recommended integration practices
- Discover dynamically at runtime: Always utilize
meta.tools.searchto resolve relevant tools, inspect current parameters viameta.tool.describe, and execute viameta.tool.execute. Consult the meta-tool workflow. - Avoid static code generation from MCP: Do not generate static TypeScript interfaces or client SDKs from captured MCP schemas.
- Design agents defensively: Prompts and agent frameworks should extract necessary fields from tool responses while gracefully ignoring unexpected or newly added attributes.
- Use REST for deterministic clients: If your system requires frozen, strictly versioned contracts to generate static typed SDKs, use the REST API v2. REST is designed for deterministic system integrations, while MCP is optimized for flexible agent cognition.
Role of the interactive tool reference
The MCP tool reference provides an interactive snapshot of available tools for developer orientation and manual debugging. Because tools evolve with continuous backend releases, meta.tool.describe remains the authoritative source of truth at execution time.