Cursor MCP: Turn Release Notes Into Scheduled Posts

The merge-to-post loop that clears announcement debt at the source.

In short:

• Announcement debt is what I call the gap between features that ship and people who never hear about them. AI made building cheap, and manual announcement effort did not get cheaper.
• Cursor talks to MCP servers through .cursor/mcp.json (project) or ~/.cursor/mcp.json (global), managed in the Customize pane. There is no cursor mcp add CLI command, which surprises people who came from Claude Code.
• Connect the PostSider MCP server and the same agent that merged the release can draft the announcement as a draft in your approval queue, minutes after the code lands.

I shipped a feature last month and forgot to tell anyone for nine days. The code was merged, the pull request was clean, the tests passed. The announcement simply did not happen, because announcing is a separate job that sits at the end of a day already full of shipping. That gap, between what you build and what your audience ever hears about, is announcement debt, and AI made it worse by making the building part faster.

This post is the fix I now use: Cursor, the editor where the code gets written, connected to PostSider over MCP, so the agent that merges the release can draft the announcement post in the same session, before the context evaporates.

Announcement debt grows where shipping outpaces announcing

Announcement debt is my own framing, and it means the features you shipped that the people who should care never heard about. Every silent release is a loan against your audience’s attention, and the interest is paid later, when a customer discovers a feature that has been live for three months and wonders why you hid it.

The economics shifted in one direction. Building got dramatically cheaper, so the number of things a small team can ship went up, while the manual work of telling anyone about each one stayed exactly as expensive as before. The result is a widening gap between release cadence and announcement cadence.

A changelog entry is not the same as an announcement. A changelog drop at the bottom of a docs page is where customer communication goes to be ignored: LaunchNotes, which builds changelog tooling, reports that relying on a single channel like a docs page or email means a large majority of customers never see an update at all.[1] The announcement is the active step, the one where you decide someone should hear and you put the post in front of them.

Cursor talks to MCP servers through mcp.json, and the Customize pane manages them

Cursor’s official documentation is clear about the current mechanism: MCP servers are installed and managed from the Customize page or configured in mcp.json, and Cursor supports three transports: stdio for local shell commands, SSE and Streamable HTTP for URL endpoints.[2]

There are two configuration locations. Project-scoped tools go in .cursor/mcp.json inside the project. Global tools go in ~/.cursor/mcp.json in your home directory. The two files are merged, and when the same server name appears in both, the project-level config wins.[3] Cursor resolves variables like ${env:NAME} and ${workspaceFolder} in the command, args, env, url, and headers fields.[2]

One thing people expect that does not exist: Cursor documents no cursor mcp add command. Claude Code has claude mcp add, Codex has its own CLI, and people coming from those tools hunt for the Cursor equivalent and find nothing. The supported paths are the JSON file, the Customize UI, Marketplace one-click installs, and a VS Code extension API. Configuration happens in JSON, and that is fine, because the JSON is simple.

A PostSider connection is one stdio entry in mcp.json

The PostSider MCP server exposes 17 tools over the public REST API and runs locally over stdio, which is exactly what Cursor expects from a local server entry.[4] The server ships in the PostSider repository as a developer tool you build yourself; it is not on npm and not a page in the dashboard, so the setup is a one-time build followed by a config block.[4]

Build it once, then add this to your project’s .cursor/mcp.json:

{
  "mcpServers": {
    "postsider": {
      "command": "node",
      "args": ["/absolute/path/to/apps/mcp/dist/index.js"],
      "env": {
        "POSTSIDER_API_KEY": "your-api-key",
        "POSTSIDER_API_URL": "https://api.postsider.com"
      }
    }
  }
}

Generate the API key in the PostSider dashboard under Settings, API. The POSTSIDER_API_URL variable points at your instance; leave it out and the default is the PostSider Cloud API. Restart Cursor, open the Customize pane, and the postsider server should appear with its tools ready to toggle.

The architectural point matters for what comes next: PostSider has no built-in post generator. The agent that writes your announcement is Cursor’s own model, calling tools the server exposes. That is the whole design, and it is why this loop works: the model doing the writing is the one that just wrote the code.

The agent that merged the code drafts the announcement from the same context

This is the payoff. After a merge or a release, ask Cursor to read the release notes or the commit list and turn them into a platform-native post, created as a draft through the PostSider tool.

The prompt pattern is short:

Read the changes in this release and draft a post announcing them for my audience. Use the postsider tools: find the next free slot, then create the post as a draft with the release highlights written in my voice. Do not schedule it. I will review it first.

Why this works only in this loop: the drafting model has the diff, the decisions, and the reasons in context, because it just wrote them. It knows what changed and why it matters, which is the exact knowledge a marketing tool guessing from a URL would lack. The announcement gets drafted in the same session where the feature got built, before the context evaporates and the debt accrues.

I keep the announcement prompt in the project rules file, so the habit survives new sessions. Every release gets a draft the same day. The changelog-to-post pattern is the baseline duty that comes before any bigger launch push, and it is the one that keeps the debt from accumulating in the first place.[5]

Two approval layers keep the merge-to-post loop safe

Autonomy is a dial, and this loop should never run at full auto. Two layers protect you.

First, Cursor asks for approval before it uses MCP tools by default.[2] It will propose the draft, show you the tool call, and wait. The behavior only changes in explicit auto-run modes like Yolo, which is why the second rule matters: keep posting tools out of allowlisted auto-run modes. Drafting can be automatic; publishing should never be.

Second, PostSider’s approval workflow sits between the draft and the queue. The agent creates a draft, and that draft has to move through review to approve before it can be scheduled.[6] Even a rogue tool call cannot publish by itself, because the content is parked in a state that requires a human decision.

That two-layer design is the difference between an agent that helps you ship announcements and an agent that posts to your company account without asking. The human-in-the-loop pattern library on this blog covers the rest of the design space, from draft-only modes to full autonomy ladders.

Queue publishing lets the draft wait for the right moment

Separating drafting from distribution is what makes the loop comfortable. The agent can write the announcement the minute the release lands, at 2pm on a Tuesday, and the posting queue decides when it actually goes out: the next free slot for that channel, a scheduled time you pick, a launch-hour slot if the release is big enough to deserve one.

The queue is the home for every announcement, not just launch-day posts. Draft the moment the feature exists, schedule for the moment your audience is actually looking. If you are new to the MCP mechanics underneath all of this, the MCP explainer and the agent-driving post cover the foundation.[7][8] The dev launch week playbook is what this loop feeds into when a release is big enough for a full push.[9]

Start with one announcement per release and make it a habit

The minimal first loop takes an afternoon: build the MCP server, add the config block, generate the API key, and after your next merge ask Cursor to draft the announcement. Approve the draft, watch it queue, and notice that the release did not go silent.

Then fold the prompt into the project rules so the habit survives, and start measuring which announcement formats actually earn engagement on your channels. Announcement debt does not get paid down in one heroic push. It gets prevented one release at a time, by a draft that exists the same day the feature exists.

The PostSider quickstart has the exact path from account to first scheduled post, and the MCP overview has the current build steps for the server.[4] The code is the easy half of shipping. The announcement is the half that decides whether anyone noticed.

Lukasz Blania is the founder of PostSider. He writes about solo-founder content operations and runs PostSider’s own social accounts through pipelines like the one above.

Sources

[1] https://www.launchnotes.com/blog/why-customers-ignore-product-release-notes [2] https://cursor.com/docs/mcp [3] https://cursor.com/help/customization/mcp [4] https://docs.postsider.com/agent/mcp/overview [5] https://www.releasepad.io/blog/product-announcement-examples/ [6] https://docs.postsider.com/features/approvals [7] https://postsider.com/blog/what-is-an-mcp-server [8] https://postsider.com/blog/driving-social-media-from-an-ai-agent-with-mcp [9] https://postsider.com/blog/dev-tool-launch-week-playbook