إصدار الأدوات والمخططات

Once others connect, they rely on your tool names and argument shapes. Changing them carelessly breaks every client at once.

Adding an optional parameter with a default keeps old callers working. They simply ignore the new field they do not send.

Renaming a tool, removing an argument, or making one required is breaking. Existing clients suddenly send calls that no longer fit.

To evolve a field, add the new one and keep the old. Mark the old as deprecated in its description so callers know to migrate.

For a real break, ship a v2 tool beside v1. Both run for a while, letting clients move over at their own pace.

Your server announces a name and version during the handshake. Bump it so clients can see which release they connected to.

Use semver: bump patch for fixes, minor for additive features, and major when you make a breaking change. The number tells a story.

Adding a field to a result is usually safe; removing one is breaking. Treat your output schema as a promise clients parse.

Record every tool and schema change in a changelog. Users upgrading need to see what moved, what is new, and what is gone.

Announce when an old tool will be removed. A clear sunset date pushes migration without yanking the rug from anyone abruptly.

Before release, run your tests as an older client would call you. That catches accidental breaks the type checker cannot see.

Which change to an existing tool is safe for current clients?

Prefer additive changes, deprecate before removing, ship v2 for real breaks, follow semver, and keep a changelog. You can ship with confidence! 🚀