[Alex (Alexkuva)]

What does this PR change?

It prepares v0.2.0, the first public release, and makes a v* tag publish the package to PyPI the way sdk-python does.

• release.yml runs on a v* tag:

  • it checks the tag against the version in pyproject.toml;
  • it runs the tests, builds, and checks the distributions with twine check --strict;
  • it publishes through PyPI trusted publishing (environment: pypi, id-token: write), with no stored token.

  ci.yml already publishes the image on the same tag.

• The package is kaitencloud-mcp, after the SDK's kaitencloud. kaiten-mcp on PyPI belongs to an unrelated project, so a reader who types it gets someone else's code.

  • The command stays kaiten-mcp. kaitencloud-mcp is the same entry point, so uvx kaitencloud-mcp runs it.
  • /health reads the version under the new name.
  • uv.lock changes by that name only.

• [project.urls]: the site, the docs page, the repository, the issues and the changelog, as on the SDK.

• The README and MCP.md install from PyPI (uvx kaitencloud-mcp stdio) and from the image (ghcr.io/kaitencloud/mcp) instead of the repository. Building from a checkout stays as the third way.

• CHANGELOG.md starts at 0.2.0.

Why?

The server is public, and reaching it from a git URL or a local docker build was the only way. A tag publishes nothing to PyPI until now, and the docs need a version to point at.

Before the tag

1. PyPI: add kaitencloud-mcp as a pending trusted publisher (owner kaitencloud, repository mcp, workflow release.yml, environment pypi), and create the pypi environment in this repository's settings.
2. GHCR: ci.yml's last run on main failed at the push, denied: permission_denied: read_package. The package ghcr.io/kaitencloud/mcp has to grant this repository write access, and be made public for an anonymous docker run.
3. Merge docs: write the README's examples in Kaiten's vocabulary #4 first, which only touches the README's examples and wording, then this PR. Tag v0.2.0 on the merge.

With docker/metadata-action's defaults, the tag publishes the image as 0.2.0 and latest.

Testing

• uv build builds kaitencloud_mcp-0.2.0 (wheel and sdist), and twine check --strict passes on both.
• From the built wheel:
  • uvx --from ./dist/kaitencloud_mcp-0.2.0-py3-none-any.whl kaitencloud-mcp --help and the same with kaiten-mcp answer;
  • the server reports version 0.2.0.
• docker build succeeds with uv sync --locked on the new lockfile.
• The built image, run against a fresh task quickstart of kaiten main:
  • GET /health answers {"status":"ok","version":"0.2.0",…,"reachable":true};
  • over Streamable HTTP with a Bearer ksh_… header, 31 tools are listed and kaiten_overview answers;
  • without a token, a call is refused with No Kaiten credential.
• uv run ruff check ., uv run ruff format --check ., uv run pytest: 56 passed. uv run pytest -m e2e against the same stack: 5 passed.

Checklist

• I have read CONTRIBUTING.md.
• Every commit in this PR includes a valid DCO Signed-off-by line.
• I have the right to submit all material in this PR.
• I have not included secrets or confidential data.
• I have updated tests where appropriate.
• I have updated documentation where appropriate.
• I have preserved required third-party licenses and attributions.

🤖 Generated with Claude Code · ✅ Tested and approved by Alex (@Alexkuva), maintainer

[Alex (Alexkuva)]

Replaced by 6, stacked on #3: #3 already renames the package, relocks and publishes to PyPI, so this one keeps only what the rename needs on top (the version /health reads, the kaitencloud-mcp command) and the release notes.