The worst moment to write a changelog entry is three days after you shipped. You have moved on, the details are fuzzy, and the entry that finally goes out is a vague "improvements and bug fixes."
The best moment is right after your agent finishes the feature, because at that point the diff is sitting in front of the one writer who has perfect recall of it: your coding agent. Patchlog now ships an MCP server, so Claude Code, Cursor, Claude Desktop, and any other MCP client can write and publish your changelog for you.
What you can do with it
Once connected, your agent gets six tools: list your projects and entries, read an entry, create one, update one, and publish one. In practice that means prompts like:
- "Add a changelog entry for the export feature we just built and publish it."
- "Draft entries for everything in this release branch. I will review them in Patchlog."
- "Fix the typo in the last published entry."
- "Schedule an entry about the pricing change for Monday 9am."
New entries default to drafts, so nothing goes public unless you say so. Publishing is explicit, and a scheduled entry stays hidden until its time comes.
Setup
You need a Patchlog account on the Pro plan (the API is a Pro feature) and an API token from Settings, then API Tokens.
Claude Code
One command:
claude mcp add patchlog -e PATCHLOG_API_TOKEN=your-token-here -- npx -y patchlog-mcp
Cursor
Add this to .cursor/mcp.json in your project, or ~/.cursor/mcp.json for all projects:
{
"mcpServers": {
"patchlog": {
"command": "npx",
"args": ["-y", "patchlog-mcp"],
"env": {
"PATCHLOG_API_TOKEN": "your-token-here"
}
}
}
}
Claude Desktop
Same block, in claude_desktop_config.json:
{
"mcpServers": {
"patchlog": {
"command": "npx",
"args": ["-y", "patchlog-mcp"],
"env": {
"PATCHLOG_API_TOKEN": "your-token-here"
}
}
}
}
No Node? Use the remote server
If you would rather not run anything locally, Patchlog also serves a remote MCP endpoint at https://patchlog.io/mcp. Point your client at that URL with your API token as a bearer token. In Claude Code:
claude mcp add --transport http patchlog https://patchlog.io/mcp --header "Authorization: Bearer your-token-here"
Both flavors expose the same six tools. Pick whichever fits your setup.
A workflow that actually sticks
The reason changelogs die is that updating them is a separate chore. The fix is to fold it into the work itself. Two patterns we like:
End of task. After the agent finishes a feature, one more prompt: "Now add a draft changelog entry for this." The agent has the full context of what changed and why it matters, so the draft is specific instead of generic. You review the wording in Patchlog and hit publish.
End of release. Before you tag a release, ask the agent to walk the branch and draft one entry per user-facing change. Ten minutes of review replaces the archaeology session you were dreading.
Write for the reader, not the diff. "You can now export reports as CSV" beats "Refactored the export pipeline." If you want a refresher on that, we wrote a whole guide on how to write release notes people actually read.
What about automatic drafts?
If you want drafts without even prompting, that is what the Patchlog GitHub Action does: it watches your pushes and drafts entries on a schedule using the diffs. The MCP server and the action complement each other. The action gives you a steady stream of drafts from CI; the MCP server gives your agent direct, interactive control when you are in the editor.
The fine print
The API and the MCP server are part of the Pro plan, which is $7 a month or $60 a year. Your token can read and write only your own projects, drafts stay private until published, and you can revoke a token at any time from your settings. That is the whole surface area.
If you hit anything odd, the server is open source at github.com/michaelyousrie/patchlog-mcp. Issues and PRs welcome.