# Keeping One MCP Server Working Across SDK Renames and Three CLIs > Source: > Published: 2026-09-14 23:47:59+00:00 An MCP server breaks at three seams: the SDK class name, the upstream request shape, and each CLI's server config. Treating those as one upgrade is what makes a small rename expensive. Put a thin adapter between your tools and the vendor SDK. Keep all imports and request construction in one module, so a FastMCP to MCPServer or genai client bump touches one file. Add a startup check that lists tools, sends one tiny generation call, and prints the resolved model, endpoint, and SDK version on failure. DIY baseline that covers the rename case: pin exact versions in the lockfile, run that smoke script in CI, and keep one config snippet per CLI pointing at the same entrypoint. For a single-maintainer server, that is usually enough. The remaining gap is silent divergence: one CLI passes env or cwd differently, or the Interactions API returns 400 for a field shape the old SDK sent. Log the outbound payload bytes on non-2xx and diff them against the last known-good call before changing code. What workaround have you used when the same MCP server passes in one CLI but fails in another?