MCP's Changing Interface
The fact that MCP is a difference surface from your normal API allows you to ship MUCH faster to MCP. This has been unlocked by inference at runtime
Normal APIs are promises to developers, because developer commit code that relies on those APIs, and then walk away. If you break the API, you break the promise, and you break that code. This means a developer gets woken up at 2am to fix the code
But MCP servers are called my LLMs which dynamically read the spec every time, which allow us to constantly change the MCP server. It doesn't matter! We haven't made any promises. The LLM can figure it out afresh every time
Backward (or forward) compatibility is a consistently problem-rich space in software engineering. It shows up everywhere there are connections between systems that evolve separately. Data serialization formats like Protobuf or Apache Avro have built-in compatibility detection, API specification frameworks like gRPC and OpenAPI, or database schema migration tools like Flyway, all exist to try and either detect or adapt to compatability issues.
There's something very compelling about the fact that the LLM can reinterpret and negotiate a changing API spec. I'm not sure we're really ready to plug LLMs into service clients and auto-negotiate APIs every time we want to call them. Especially because the reason the LLM is able to negotiate the changing interface is because it is executing at runtime, having to digest and relearn the API spec each time, and because it has access to "all the data" and can supply newly required data. However, I expect we'll probably end up with LLM tools around these interfaces, making compatibility adjustments easier, statically updating code to force a migration off deprecated APIs.