[Alex (Alexkuva)]

What does this PR change?

It completes #3 for the 0.2.0 release. #3 moves the package to kaitencloud-mcp and publishes it on a v* tag; this PR is stacked on it (base fix/ci-publish) and adds what the rename needs, plus the release notes.

• /health reports the right version. The server reads its version from the distribution kaiten-mcp, which no longer exists under that name. With ci: publish the image to its own package and the Python package to PyPI #3 alone, an installed server reports 0.0.0. It now reads kaitencloud-mcp.

• uvx kaitencloud-mcp runs the server. uvx runs the command named after the package, and with ci: publish the image to its own package and the Python package to PyPI #3 alone the package only provides kaiten-mcp. kaitencloud-mcp is now the same entry point, and kaiten-mcp stays.

• [project.urls] gains the docs page and the changelog, next to ci: publish the image to its own package and the Python package to PyPI #3's homepage, repository and issues.

• The README and MCP.md install from PyPI (uvx kaitencloud-mcp stdio) and from ghcr.io/kaitencloud/kaiten-mcp:0.2, a tag ci: publish the image to its own package and the Python package to PyPI #3's rules produce, instead of the repository. Building from a checkout stays as the third way.

• CHANGELOG.md starts at 0.2.0.

• MCP.md's troubleshooting says what a client actually receives:

  • a bad token gets Kaiten's 401 [ValidateToken.Invalid] from each tool call, not a 401 from /mcp: the server forwards the credential without checking it;
  • a call with no credential gets No Kaiten credential;
  • a missing scope gets Kaiten API error (403 Forbidden) [Auth.MissingScope], with the scope named.

  The console labels are Service Accounts and Generate Token.

It replaces #5, which duplicated #3's rename, lockfile and publishing.

Why?

Without the first two changes, the release #3 publishes would report a wrong version and would not start with the command its own package name suggests.

Testing

• ci: publish the image to its own package and the Python package to PyPI #3's branch on its own, built: the server reports version 0.0.0, and the package provides no kaitencloud-mcp command.
• This branch, built:
  • uvx --from ./dist/kaitencloud_mcp-0.2.0-py3-none-any.whl kaitencloud-mcp --help and the same with kaiten-mcp both answer;
  • the server reports 0.2.0.
• uvx uv@0.9.1 lock --check passes: the lockfile ci: publish the image to its own package and the Python package to PyPI #3 relocked stays valid, since a console script is not part of it.
• uv run ruff check ., uv run ruff format --check ., uv run pytest: 56 passed.
• The server, against a fresh task quickstart of kaiten main, through an MCP client:
  • uv run pytest -m e2e: 5 passed;
  • a read:* token gets 403 [Auth.MissingScope] from a write tool, and an invalid token gets 401 [ValidateToken.Invalid];
  • kaiten_delete previews until confirm=true;
  • the read-only server lists 15 tools.

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 #7: the same two commits, taken again on top of main. After #3's squash merge, updating this branch from main left two [project.urls] tables in pyproject.toml (TOML parse error, lint and test red) and a merge commit without a sign-off (DCO red), which only a history rewrite could fix here.