Keeping One MCP Server Working Across SDK Renames and Three CLIs

작성자

카테고리:

← 피드로
DEV Community · infracore · 2026-09-15 개발(SW)

infracore

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?

원문에서 계속 ↗