LinkedIn Content Planner MCP server

LinkedIn Content Planner (MCP)

A LinkedIn content pipeline built for AI agents, not humans typing into a text box. Your agent (Claude Code, Claude Desktop, or any MCP-compatible client, on whatever schedule you run it — cron, an agent loop, a chat session) drafts, formats, and moves posts through a review pipeline by calling MCP tools directly: createpost, updatepostcontent, submitreview, and more. A human just reviews, comments, and approves/requests changes from the web UI before anything goes live — the same shape as reviewing a PR before merge, not manually operating a scheduling tool.

Multi-tenant and OAuth-secured out of the box: agents authenticate against the planner's own OAuth 2.1 authorization server (PKCE, dynamic client registration) and every MCP call is scoped to the caller's workspace.

See PLAN.md and ARCHITECTURE.md for the full design.

Local development

Requirements: Node 20+, pnpm, a Postgres 16 instance (via infra/docker-compose.yml or a local install).

# 1. Start Postgres
docker compose -f infra/docker-compose.yml up -d
# (or point DATABASE_URL at any local Postgres 16 instance)

# 2. Install dependencies
pnpm install

# 3. Configure env
cp apps/server/.env.example apps/server/.env
# edit DATABASE_URL if not using the default docker-compose credentials

# 4. Generate + run migrations, seed default workspace
pnpm --filter @linkedin-planner/db generate
DATABASE_URL=postgres://linkedin_planner:linkedin_planner@localhost:5432/linkedin_planner_dev pnpm --filter @linkedin-planner/db migrate
DATABASE_URL=postgres://linkedin_planner:linkedin_planner@localhost:5432/linkedin_planner_dev pnpm --filter @linkedin-planner/db seed

# 5. Run the server
pnpm dev:server

MCP tool surface

Posts: createpost, listposts, getpost, updatepostcontent, strreplacepostcontent, setpoststate, setpostdate, deletepost. Versions: listversions, getversiondiff, reverttoversion. Review: submitreview, listreviews. Comments: addcomment, listcomments, resolvecomment. Attachments: prepareattachmentupload, attachfile, listattachments. Preview: renderpreview. Webhooks (subscribe to post lifecycle events): createwebhook, listwebhooks, updatewebhook, deletewebhook, listwebhookdeliveries. Full tool schemas are served at the /mcp endpoint itself; see PLAN.md for the design rationale behind each.

Uploading an attachment

attach_file takes base64 inline, which is only practical for small files: a 160 KB image is ~217,000 base64 characters, more context than most agents can spend and more than any of them can retype without a silent corruption. Anything larger goes through a ticket instead:

prepare_attachment_upload(postId, filename, mimeType)
  -> { uploadUrl, method: "PUT", expiresAt, maxBytes }

curl -T ./carousel.pdf '<uploadUrl>'     # bytes never enter the conversation
list_attachments(postId)                 # confirm it landed

The URL embeds an HMAC-signed ticket scoped to that one post, valid 15 minutes, and rejected afterwards. Both paths converge on the same attachFile service, so the 25 MB per-file and 250 MB per-workspace caps apply identically. Set ATTACHMENTUPLOADSECRET when running more than one instance — unset, each process signs with its own random key and a ticket minted by one instance will not verify on another.

Access keys

Some MCP clients cannot run the OAuth flow — an Apify Standby Actor, for one, whose Authorization header already carries the caller's Apify token. For those, a signed-in user creates a long-lived access key on the Connect page (/connect?label=Apify prefills the form) and the client sends it as Authorization: Bearer plannermcp….

Shortened. The full README is on GitHub.