Description
The Kosli MCP server (kosli-dev/mcp-server, npm @kosli/mcp-server) is now documented at /integrations/mcp_server, but its releases are not picked up by the "Update changelog" workflow. Releases up to and including v0.5.0 have shipped with no changelog entries.
Changes to .mintlify/workflows/update-changelog.md
-
Add to context:
- repo: "kosli-dev/mcp-server"
-
Add a bullet to the release-convention list describing how the repo releases: semver GitHub Releases (v0.2.0, v0.3.0, v0.4.0, v0.5.0). Check the Releases list for new versions.
-
Add the tag mapping:
- kosli-dev/mcp-server → ["MCP Server"]
Filter out chore releases
The repo is pre-1.0 and ships frequent Dependabot and CI bumps — most of v0.5.0's commits are ci: and chore:. Without a filter the changelog fills with noise.
Apply the same rule the workflow already uses for kosli-dev/setup-cli-action: only write an entry when a release changes something user-facing (tool names or parameters, environment variables, install methods, the supported Node version, or a breaking change), skip pure dependency and chore releases, and consolidate several accumulated releases into a single entry keyed to the newest one.
Beta status is worth calling out explicitly when it changes — tool names and parameters may change between releases while the server is in beta, and that is user-facing.
Acceptance criteria
Out of scope
Auto-updating integrations/mcp_server.md itself on new releases. That page has real version coupling (Node floor, the pinned version in the beta warning, the tool table, the env var table, and the BETA tag when it goes GA), but a dedicated workflow is deferred until the need is clearer. Handle page updates manually for now.
Description
The Kosli MCP server (
kosli-dev/mcp-server, npm@kosli/mcp-server) is now documented at /integrations/mcp_server, but its releases are not picked up by the "Update changelog" workflow. Releases up to and includingv0.5.0have shipped with no changelog entries.Changes to
.mintlify/workflows/update-changelog.mdAdd to
context:Add a bullet to the release-convention list describing how the repo releases: semver GitHub Releases (
v0.2.0,v0.3.0,v0.4.0,v0.5.0). Check the Releases list for new versions.Add the tag mapping:
Filter out chore releases
The repo is pre-1.0 and ships frequent Dependabot and CI bumps — most of
v0.5.0's commits areci:andchore:. Without a filter the changelog fills with noise.Apply the same rule the workflow already uses for
kosli-dev/setup-cli-action: only write an entry when a release changes something user-facing (tool names or parameters, environment variables, install methods, the supported Node version, or a breaking change), skip pure dependency and chore releases, and consolidate several accumulated releases into a single entry keyed to the newest one.Beta status is worth calling out explicitly when it changes — tool names and parameters may change between releases while the server is in beta, and that is user-facing.
Acceptance criteria
kosli-dev/mcp-serverappears in the workflow'scontext["MCP Server"]tag mapping documentedv0.5.0, or correctly produces nothing if judged non-user-facingOut of scope
Auto-updating
integrations/mcp_server.mditself on new releases. That page has real version coupling (Node floor, the pinned version in the beta warning, the tool table, the env var table, and theBETAtag when it goes GA), but a dedicated workflow is deferred until the need is clearer. Handle page updates manually for now.