A file, not a command
You add a Cursor MCP server by editing a file, not by running a command: Cursor reads .cursor/mcp.json for a single project and ~/.cursor/mcp.json for every project. Postdom runs over stdio from the published @postdom/mcp@0.3.0 package, and once connected Cursor reads workspace state and can submit a plan to publish supplied finished video to TikTok, Instagram Reels, YouTube Shorts, LinkedIn, Facebook Reels, X, Snapchat Spotlight, Threads and Bluesky. The project file lives inside your repository, so the entry below names your key rather than containing it.
Cursor has no add-a-server command. Its CLI can read the configuration back and enable or disable a server, but nothing writes the entry for you, so you put it in one of two files — and where you put it decides who gets the server and what can leak.
.cursor/mcp.json~/.cursor/mcp.json{
"mcpServers": {
"postdom": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@postdom/mcp@0.3.0"
],
"env": {
"POSTDOM_API_KEY": "${env:POSTDOM_API_KEY}"
}
}
}
}The command and arguments in that entry were run directly over stdio: the server answered as postdom version 0.3.0 and listed 13 tools. The package is @postdom/mcp@0.3.0 and requires Node.js 22 or newer.
A human creates the workspace and the key. Postdom shows the exact configuration once, at the moment the key is created. Export it as POSTDOM_API_KEY in your shell, or put it in a gitignored file and point the entry at it with envFile, so the value lives outside anything you might commit.
Use the project file to give a repository the server, or the home-directory file to have it everywhere. Both hold one mcpServers object, so add the postdom key to what is there instead of pasting over the file. @postdom/mcp@0.3.0 needs Node.js 22 or newer.
The file extension matters. A project rule must be .mdc with frontmatter; a plain .md file is ignored by the rules system, and a rule with neither a description nor globs is only used when you @-mention it. Give it a description so Cursor can pull it in when the work is about publishing.
Run agent mcp list to see the server and its connection status, and agent mcp list-tools postdom to see the tools it exposes. If it is missing, check the toggle under Customize in the sidebar: a disabled server does not load and does not appear in chat, however correct the file is. Then ask Cursor to call get_workspace_status, because registration is not the same as a working key.
The human owns the account, the audience, consent, disclosures and the approval itself. Cursor can prepare a bounded request and read the result. It cannot approve its own plan, widen policy, or turn its own confidence into permission to publish.
Read it back with agent mcp list, and see what the server exposes with agent mcp list-tools postdom. Cursor also lists MCP servers under Customize in the sidebar, with a toggle per server. Cursor's MCP documentation covers both files and the variables it resolves in them; its CLI reference covers the commands.
The brief is what makes the connection useful: it tells the agent what to check before proposing a post, what a workflow state does and does not mean, and when to stop and ask a human. It belongs in .cursor/rules/postdom.mdc, and the extension is load-bearing. Cursor ignores a rules file with no frontmatter, so a brief pasted into a plain .md file is silently never used.
---
description: Postdom operating brief. Rules for planning, approving and publishing short-form video through Postdom's MCP tools.
alwaysApply: false
---Open the file with those three lines, then the brief below them. A description and no globs is the rule Cursor pulls in when it judges the work relevant; a rule with neither waits to be @-mentioned. Cursor project-rules documentation sets out the four rule types. The operating brief itself is the same text in every client.
The connection exposes 13 tools. This list is checked against the tool registrations in the MCP server's own source, so the two cannot drift apart without failing a build. Each tool links to its own reference.
get_workspace_statuslist_accountsconnect_accountget_briefget_digestupload_mediaget_mediasubmit_planget_planpublish_videoget_publishget_performanceget_best_postsPostdom publishes supplied finished video to these destinations. It does not generate video, add networks it has not shipped, or make every feature inside a destination available.
Running an agent that is not Cursor? Postdom as a Claude Code MCP server and Postdom as a Codex MCP server cover the same connection where the client registers it by running a command instead.
These four have different causes, and separating them beats editing a file that may already be correct.
Run agent mcp list before you change anything else, because it separates "not registered" from "registered and not running". If the server is listed, check the toggle under Customize in the sidebar: a disabled server neither loads nor appears in chat. A correct file is not the same as a live connection.
The connection is fine and the credential is not. If the entry uses ${env:POSTDOM_API_KEY}, the variable has to be set in the environment Cursor itself inherits, which is not always the shell you tested in — restart Cursor after exporting it. If that is set, confirm the key was copied whole; Postdom shows it once, so revoke it in Postdom Accounts and create a new one rather than guessing at a truncated copy.
Open the Output panel and select MCP Logs from the dropdown. It carries server initialisation, tool calls and errors, which is where a startup failure shows up. The first thing to rule out is the Node.js version: @postdom/mcp@0.3.0 requires Node.js 22 or newer and fails before any tool is registered on an older runtime, so a server that is listed and enabled can still have failed to start.
The published entry sets no POSTDOM_API_URL on purpose: the package already defaults to Postdom's hosted API, and a variable that is named but never exported resolves to an empty value that defeats that default rather than falling back to it. Add POSTDOM_API_URL only if you run Postdom somewhere else, and then give it a real value rather than a reference to a variable you have not set.
Confirm the file is .cursor/rules/postdom.mdc and not a .md file, and that it opens with frontmatter. Cursor ignores a rules file with no frontmatter, and a rule with no description and no globs waits to be @-mentioned instead of applying on its own.
Cursor asks for approval before it runs an MCP tool, which is the right default and is not the same as the guarantees below. These four hold whatever the client does.
An accepted or requires_approval response is not provider publication. A scheduled state is not publication either. Keep the returned post ID and read that same post through to a terminal per-destination outcome before you call it published.
A failed or partial state does not prove a destination never published, so it is not a licence to retry automatically. Reconcile each destination first; retrying a request where one destination already succeeded is how duplicates get made.
When a platform does not report a value, Postdom keeps it unavailable with its reason attached and leaves it out of aggregates. null is not zero, and treating it as zero silently understates everything it touches.
Cursor can prepare a bounded request and interpret the result. The human owns credentials, connected accounts, policy, consent, audience and disclosures. Approval is enforced on the exact version and request that will be sent.
Yes. Postdom publishes an MCP server exposing 13 tools. Cursor connects to it over stdio using the published @postdom/mcp@0.3.0 package and a workspace key you create.
In .cursor/mcp.json for one project, or ~/.cursor/mcp.json for every project. Cursor has no add-a-server command, so this is a file you edit. Both files hold a single mcpServers object, so add the postdom entry rather than replacing what is there.
Only if it holds no key, and only with the review a committed file deserves. Cursor resolves ${env:NAME} in the entry, so write ${env:POSTDOM_API_KEY} and keep the value in your environment; the file then carries no secret and everyone on the project gets the server. What it does carry is a command that runs on every collaborator's machine, so treat a change to it the way you would treat a change to CI configuration. The entry pins an exact package version rather than a floating one for that reason.
It can read workspace status, accounts, the brief and the digest; submit and read a plan; publish supplied finished video; and read publish outcomes and performance. Postdom does not generate video. You supply the finished file, and a human approves what goes out.
A project rule has to be an .mdc file in .cursor/rules with frontmatter at the top, such as .cursor/rules/postdom.mdc. A plain .md file is ignored by the rules system, and an .mdc file with neither a description nor globs is only included when you @-mention it. Giving the brief a description is what lets Cursor bring it in on its own.
No. accepted, requires_approval and scheduled are workflow states, not provider publication. Keep the returned Postdom post ID and read that same post through to a terminal per-destination outcome before treating any destination as published, and before retrying anything.
They stay unavailable, with the reason attached. Postdom does not substitute a zero for a missing observation: null is not zero, and an unavailable metric is excluded from aggregates rather than quietly dragging them down.