Reads a local Git repository's commit log via git log to generate release notes and CHANGELOG drafts, with tools to inspect commits between specified refs.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@git-changelog Generate release notes from v1.2.0 to HEAD in this repo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that turns local git log into release notes and CHANGELOG drafts.
Generate conventional-commit–grouped release notes between tags/commits, inspect commit groups, and write a CHANGELOG.md draft — from Cursor, Claude Desktop, or any MCP client.
Local git only. This server reads your local repository via
git log. It does not push, force-push, scrape remotes, or rewrite history. Use only on repos you own or have permission to inspect.
npx -y @mcpx-digital/git-changelogPublish note: Prepared for npm as
@mcpx-digital/git-changelog. Until published, run from a local clone.
Related MCP server: Git Commit MCP Server
mcp.json example{
"mcpServers": {
"git-changelog": {
"command": "npx",
"args": ["-y", "@mcpx-digital/git-changelog"]
}
}
}Local clone:
{
"mcpServers": {
"git-changelog": {
"command": "node",
"args": ["/absolute/path/to/git-changelog-mcp/index.js"]
}
}
}Tool | What it does |
| Markdown release notes from |
| Group commits by conventional type ( |
| Write (or dry-run) a |
“Generate release notes from tag v0.1.0 to HEAD in this repo”
“Group conventional commits since v1.2.0”
“Draft CHANGELOG.md for version 0.2.0 (dry run first)”
git clone https://github.com/TheoryofShadows/git-changelog-mcp.git
cd git-changelog-mcp
npm install
npm test
node index.jsSuggested listing price: $6.
Install command: npx -y @mcpx-digital/git-changelog
MIT © TheoryofShadows
Generate markdown release notes from git log between optional from/to refs (tags or commits), with conventional-commit grouping. Operates on a local git working tree only (reads history via git log). Does not access remotes or rewrite history.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Newer ref (default: HEAD). | |
| from | No | Older ref (tag/commit). Omit for all history up to `to`. | |
| title | No | Optional markdown H1 title. | |
| repoPath | No | Path to local git repo (default: cwd). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It explicitly discloses that the tool reads history via git log, operates on a local working tree only, does not access remotes, and does not rewrite history. This is strong non-destructive context, though it omits return format and edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The core action and ref-range semantics are front-loaded, followed by concise behavioral constraints. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description could more explicitly state whether the tool returns markdown content or writes a file. However, for a read-only generation tool with all-optional parameters, the essential invocation context—scope, repo path, title, and refs—is covered well enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds useful context around refs being tags or commits and mentions conventional-commit grouping, but it largely mirrors the schema and adds little meaning beyond it for title or repoPath.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb and resource: 'Generate markdown release notes from git log'. It clearly scopes the operation to a ref range with conventional-commit grouping, and the local-only/read-only qualifiers distinguish it from the sibling tools without needing their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for using the tool ('between optional from/to refs', 'local git working tree only') but does not explicitly say when to prefer it over group_conventional_commits or write_changelog_draft, nor does it name alternatives or exclusions. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List and group commits in a range by conventional type (feat/fix/docs/…). Operates on a local git working tree only (reads history via git log). Does not access remotes or rewrite history.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Newer ref (default: HEAD). | |
| from | No | Older ref (tag/commit). | |
| repoPath | No | Path to local git repo (default: cwd). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly discloses that the tool is read-only, reads via git log, operates locally, and does not access remotes or rewrite history. This is strong transparency, though it does not describe the output format or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core purpose is front-loaded, and the behavioral constraints follow immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only git tool with fully documented optional parameters, the description is nearly complete. It explains the operation, scope, and safety profile. The absence of an output schema means some return-format detail is missing, but the tool's purpose is simple enough to still be usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters. The description adds minimal parameter-specific meaning beyond indicating a commit range, but it does not need to compensate for missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'List and group commits in a range by conventional type.' It further distinguishes itself from siblings by emphasizing it operates locally and only reads history, not generating release notes or changelogs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful constraints ('local git working tree only', 'does not access remotes or rewrite history') but does not explicitly say when to use this tool instead of generate_release_notes or write_changelog_draft. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a CHANGELOG.md draft for a version from local git history. Use dryRun to preview. Operates on a local git working tree only (reads history via git log). Does not access remotes or rewrite history.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Newer ref (default: HEAD). | |
| date | No | ISO date YYYY-MM-DD (default: today). | |
| from | No | Older ref (tag/commit). | |
| dryRun | No | If true, return preview without writing. | |
| version | No | Version label (default: Unreleased). | |
| repoPath | No | Path to local git repo (default: cwd). | |
| outputPath | No | Output file path (default: <repo>/CHANGELOG.md). | |
| prependExisting | No | If true and file exists, prepend new section under # Changelog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and largely delivers: it discloses that reads happen via git log, that remotes are never accessed, and that git history is never rewritten. The dryRun preview behavior is also surfaced. It does not explicitly flag that the non-dryRun path mutates the filesystem by writing outputPath, though 'Write a CHANGELOG.md' makes this fairly inferable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: purpose first, then the preview flag, then the safety constraints. Every sentence earns its place and the structural boundary (local working tree only) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no annotations and no output schema, this description covers the core behavior, safety profile, and operation domain well. The main gap is return-value disclosure: with no output schema, an agent doesn't know what a successful call returns (e.g., written path, diff, success message), since only the dryRun preview outcome is hinted at.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds modest value by framing to/from as local git refs and highlighting dryRun as the preview mechanism, but most parameter meaning already lives in the schema. It does not add formats, edge cases, or interaction details beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Write a CHANGELOG.md draft for a version from local git history' — which clearly differentiates it from siblings: generate_release_notes (likely remote/API-based) and group_conventional_commits (an analysis/grouping operation). The local-only scoping reinforces the distinct identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is present through constraints ('Operates on a local git working tree only', 'Does not access remotes or rewrite history'), which tells an agent when this tool is appropriate over a remote-capable alternative. However, it never names the siblings or gives explicit when-to-use/when-not-to-use guidance, leaving differentiation to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0generate_release_notesgroup_conventional_commitswrite_changelog_draftScored across 3 tools
There is meaningful overlap: group_conventional_commits, generate_release_notes, and write_changelog_draft all derive output from the same conventional-commit git history. However, the descriptions clarify the intended boundaries: low-level listing, markdown release notes output, and writing a CHANGELOG.md draft.
All tool names follow the same snake_case verb_noun pattern: group_conventional_commits, generate_release_notes, and write_changelog_draft. This is fully predictable and consistent.
Three tools is a well-scoped size for a dedicated git changelog server. Each name corresponds to a distinct output stage, and there is no bloat or unnecessary expansion.
The server covers the core changelog workflow: grouping commits, generating release notes, and writing a draft changelog file. A minor gap is that there is no obvious tool for updating or appending to an existing CHANGELOG.md, but this is not a critical omission for draft-oriented usage.
Generate changelogs, release emails, help-center articles, banners, and social posts from commits.
Turn a raw dev log (commit subjects, PR titles) into customer-facing release notes Markdown.
Deploy & release tracking with native MCP — ask Claude what's in production and cut the release.
MCP-native notes and memory for ChatGPT, Claude, and other AI tools.
