verified: stdio · pending verification: connector over OAuth
Postdom runs as a Claude Code MCP server over stdio, and that is the transport verified here against the published @postdom/mcp@0.3.0 package. Once connected, Claude 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. Claude Desktop can read the same stdio configuration from its own file. The separate claude.ai connector route, which uses the hosted endpoint and OAuth instead, is pending verification.
Both reach the same workspace. They are not equally proven, so they are not described as though they were.
Verified · to the last step before your key
Verified against the published @postdom/mcp@0.3.0 package: install, startup, MCP initialize, discovery of all 13 tools, and a live request that surfaced a clean authorization error inside the tool result rather than crashing. The only untested step is substituting a real workspace key, which is yours to hold.
Use this configurationPending verification · server live, connector flow not yet exercised
The server side is live: the endpoint answers with a correct authorization challenge and publishes the discovery documents an OAuth connector follows. The connector flow itself — adding the server, granting consent, and seeing the grant appear in your authorized clients — is pending verification, so this page does not claim it works end to end.
Endpoint: https://api.postdom.com/mcp
The configuration below has the shape Postdom Accounts generates when you create a workspace key. Substitute the server URL and key it shows you; both appear once.
{
"mcpServers": {
"postdom": {
"command": "npx",
"args": ["-y", "@postdom/mcp@0.3.0"],
"env": {
"POSTDOM_API_URL": "<server URL shown in Postdom Accounts>",
"POSTDOM_API_KEY": "<workspace key, shown once>"
}
}
}
}The package is @postdom/mcp@0.3.0 and requires Node.js 22 or newer. The workspace key lives in this file, never in a chat message.
.mcp.json~/Library/Application Support/Claude/claude_desktop_config.json%APPDATA%\Claude\claude_desktop_config.jsonClaude Code can add the same server without editing a file. The form below is adapted from Claude Code's MCP documentation — the shape is theirs, the values are ours — and it is written out here rather than run.
claude mcp add \
-e POSTDOM_API_URL=YOUR_SERVER_URL \
-e POSTDOM_API_KEY=YOUR_WORKSPACE_KEY \
--scope project postdom -- npx -y @postdom/mcp@0.3.0Without a --scope flag, claude mcp add uses local scope: private to you and active only in the current project. Local and user scope are both written into Claude Code's own ~/.claude.json — local under the current project's entry, user at the top level — so let the command manage that file rather than editing it by hand. Use --scope user to make the server available across all your projects, and --scope project to write the .mcp.json above instead.
Then run claude mcp list to confirm postdom is registered before you depend on it.
A human creates the workspace and the key. Postdom shows the exact configuration once, at the moment the key is created. The key belongs in your Claude client configuration file, never in a chat message and never in a prompt.
Save the block as .mcp.json in your repository root to share the server with the project. Claude Desktop reads the same block from its own config file, whose path differs by operating system. To install it for yourself across every project instead, run the command above with --scope user, because that scope lives inside Claude Code's own managed configuration rather than a file you edit. The package is @postdom/mcp@0.3.0 and it needs Node.js 22 or newer.
Claude Code can register the same server without editing a file, using claude mcp add with the environment values passed as flags. As printed above, the command writes project scope; swap in --scope user for every project on your machine. Pass one or the other explicitly, because without a scope flag the server lands at local scope, which is neither the .mcp.json nor the Desktop file above. Run claude mcp list afterwards to confirm postdom is registered before you rely on it.
Add the operating brief to CLAUDE.md so the instructions load with the project rather than depending on someone remembering to paste them. The brief is an operating brief, not a setup prompt: copying it connects nothing on its own.
Ask Claude to call get_workspace_status. A successful response confirms the connection and shows setup progress, connected accounts and policy. If the tools are missing, stop and restore the connection rather than working around it.
The human owns the account, the audience, consent, disclosures and the approval itself. Claude 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.
The connection exposes 13 tools. This list is checked against the tool registrations in the MCP server's own source, and the package version below is pinned to the one that ships, 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_postsVerified against the published @postdom/mcp@0.3.0 package by listing the tools the server registers and calling one of them. Scope of that check: the connection and the error surface, not an authenticated publish.
Postdom 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.
For the workflow itself once you are connected — what to ask for, and what to check afterwards — read publishing from Claude Code. The instructions Claude loads are the operating brief.
Three failures account for most of them, and each has a different cause worth separating before you start changing the configuration.
Restart Claude, then run `claude mcp list` to see whether postdom is registered at all. A server that is registered but failing shows up here, which separates a configuration problem from a connection problem.
Check the Node.js version first: the package requires Node.js 22 or newer, and an older runtime fails before any tool is registered. If Node is current, confirm the configuration is in the scope you expected — a project `.mcp.json` does not apply outside that project.
The server is reachable and the key is being rejected. Confirm the workspace key was copied whole, and that it is in the configuration file rather than pasted into a chat message. Postdom shows the key once, so regenerate it rather than guessing at a truncated copy.
This is the part most integrations leave out, and it is the part that decides whether you can trust your own logs.
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.
Claude 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. Claude Code connects to it over stdio using the published @postdom/mcp@0.3.0 package and a workspace key you create. That path is verified here to the last step before a real key.
Claude Desktop can read the same stdio configuration from its own file, which is the transport verified here. The separate claude.ai connector route uses the hosted endpoint over OAuth: that endpoint is live and answers the authorization challenge correctly, but the connector flow itself is pending verification, so this page states the server is ready rather than claiming the end-to-end experience has been confirmed.
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.
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.
This page is the connection: transports, configuration, tools and verification. The Claude Code page covers the workflow itself once the connection exists. If you are deciding how to wire Postdom into Claude, start here.