v0.5.1

[0.5.1] – 2026-07-28

Wartungs-Release der Release-Infrastruktur. Funktional ändert sich nichts:
die 21 Tools sind unverändert, die einzige Anpassung in src/ ist der
Versionsstring im User-Agent. Wer das Paket nutzt, bekommt nichts Neues — der
Release existiert, damit die neuen CI-/Release-Bausteine einen getaggten Stand
haben.

Neu / Added

• Workflow «Draft Release» (.github/workflows/draft-release.yml, manuell
  via workflow_dispatch): legt aus dem passenden CHANGELOG.md-Abschnitt ein
  Draft-Release an, ohne dass lokal ein Tag gepusht werden muss — GitHub
  erzeugt den Tag erst beim Veröffentlichen. Mit Guards gegen
  Versionsabweichung zu pyproject.toml, bereits existierende Tags/Releases und
  fehlende CHANGELOG-Abschnitte. Veröffentlicht bewusst nicht selbst: das
  löst über publish.yml PyPI und die MCP Registry aus und ist unumkehrbar,
  daher bleibt der letzte Schritt ein bewusster Klick. Release-Verfahren in
  CONTRIBUTING.md / CONTRIBUTING.de.md dokumentiert.
• CI-Check «Versions-Sync» (scripts/check_version_sync.py, im lint-Job):
  vergleicht pyproject.toml mit server.json → version und jedem
  packages[*].version und bricht bei Abweichung ab. Schliesst die Lücke, durch
  die das Registry-Manifest von v0.2.3 bis v0.5.0 unbemerkt veraltet war —
  publish.yml überschreibt die Version beim Veröffentlichen aus dem Tag,
  weshalb die committete Datei nie auffällig wurde. Nur Standardbibliothek
  (tomllib), lokal ausführbar.

Geändert / Changed

• User-Agent auf 0.5.1 mitgezogen. Der Versionsstring in api_client.py
  wird bei jedem Release von Hand gepflegt — bleibt er stehen, entsteht genau
  die Drift, die in v0.5.0 nach drei Releases aufgefallen ist. Bis er aus den
  Paket-Metadaten gelesen wird, gehört er in jeden Versionsbump.

Behoben / Fixed

• server.json auf 0.5.0 nachgezogen. Das MCP-Registry-Manifest stand seit
  v0.2.3 auf einer veralteten Version und war damit über mehrere Releases hinweg
  nicht mit pyproject.toml synchron. Rein kosmetisch: publish.yml
  synchronisiert die Version beim Veröffentlichen ohnehin aus dem Tag-Namen,
  weshalb in der Registry korrekt 0.5.0 publiziert wurde. Die committete Datei
  spiegelt jetzt den tatsächlichen Stand, statt beim Lesen in die Irre zu führen.
• Draft Release: führende und nachfolgende Leerzeilen im Release-Body. Die
  Extraktion begann bei der Leerzeile unter der CHANGELOG-Überschrift und endete
  bei den Leerzeilen vor der nächsten — im ersten Lauf (v0.5.0-Entwurf) als
  Abstand am Anfang sichtbar. Der Abschnitt wird jetzt getrimmt; die
  Leer-Prüfung greift neu nach dem Trimmen, damit ein Abschnitt aus reinen
  Leerzeilen genauso abbricht wie ein fehlender.