Your agent writes the release note.

01Create a token

In your workspace, open Agents and create a token: a name, a scope (propose, or propose and publish), optionally the products it may touch. The token is shown once. It looks like cp_live_…; keep it in an environment variable, never in a repository.

02Connect the agent

Claude Code, one command:

claude mcp add --transport http changelog-plus https://app.changelog.plus/mcp \
  --header "Authorization: Bearer $CHANGELOG_PLUS_TOKEN"

Or in the project’s .mcp.json, so the whole team shares it while each keeps their own token:

{
  "mcpServers": {
    "changelog-plus": {
      "type": "http",
      "url": "https://app.changelog.plus/mcp",
      "headers": { "Authorization": "Bearer ${CHANGELOG_PLUS_TOKEN}" }
    }
  }
}

Codex, Cursor and the others take the same URL and header in their MCP settings. The server speaks the 2026-07-28 revision of the protocol and still answers clients on the 2025 revision. Its card is at https://app.changelog.plus/.well-known/mcp/server-card.json.

03Instruct the agent

Paste this in the AGENTS.md (or CLAUDE.md) of the repository the agent works in. The Agents page gives it with your product slug filled in.

## Changelog+

This product publishes its release notes with Changelog+ (MCP server
changelog-plus, product your-product). When a change visible to users is
finished, tested and merged on the main branch:

1. Call style_guide_get and write inside it.
2. Capture the feature as the user sees it and send it with media_upload.
3. Call proposal_preflight, fix what it reports, then proposal_create.
   Never publish directly; the owner approves in Changelog+.
4. Report the draft URL in the final message.

Never propose a note for a dependency, a refactoring, CI or internal docs.

The server also publishes this procedure as an MCP skill, so hosts that read skills pick it up without the paste.

04Tools

• products_list · The products the token may write for.
• style_guide_get · Audience, tone, detail level, vocabulary, language, rules and the last releases. Read it before writing.
• releases_list · Recent published releases, to avoid telling a change twice.
• media_upload · A capture of the feature, base64, up to 4 MiB.
• media_import_from_url · The same, from a public https URL.
• proposal_preflight · Validate without writing: schema, secrets, media, scope, quota.
• proposal_create · Create the draft in the inbox. The owner approves it.
• proposal_get · Where a proposal stands: draft, awaiting approval, published, rejected.
• release_publish · Publish now. Needs the publish scope and the owner’s request.

Mutating tools accept an idempotencyKey: the same key with the same arguments replays the first answer for seven days.

05REST API

Everything above exists as HTTP with the same bearer token, for scripts and integrations that do not speak MCP. Base URL https://app.changelog.plus/api/v1, contract at /api/v1/openapi.json, errors as RFC 9457 problem details.

06What the agent can and cannot do

• It proposes. Nothing is published without approval unless you gave the token the publish scope.
• Everything it sends is validated: plain text, bounded lengths, no HTML, credentials detected and refused, images sniffed on their bytes.
• Each proposal is kept with the agent’s name, version and branch; you see who proposed what in the inbox.
• A proposal counts as one update in your plan, like a pipeline run.
• Revoke a token at any time; the agent is refused on its next call.