How do I install LinkedIn Content Planner?

Copy the http config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.

Does LinkedIn Content Planner need an API key?

No required environment variable is listed on this record.

What transport does LinkedIn Content Planner use?

LinkedIn Content Planner is reached over HTTP.

When was LinkedIn Content Planner last checked?

Last checked 2026-11-07. Draft, revise and review LinkedIn posts; a human approves each one before it goes live.

LinkedIn Content Planner MCP server

Power your agent

Add this server

The publisher's own URL. Not a PlugMCP endpoint.

Add to Cursor Add in Claude Add to VS Code Run on PlugMCP

Host a copy with our keys and logs.

Server URL

https://linkedin-mcp.theona.app/mcp

The Claude button above opens Claude with the name and URL filled in. You still confirm it there.

shClaude Code

1claude mcp add --transport http app.theona-linkedin-content-planner https://linkedin-mcp.theona.app/mcp

Run in a terminal.

jsonClaude Desktop

1{2  "mcpServers": {3    "app.theona-linkedin-content-planner": {4      "command": "npx",5      "args": [6        "-y",7        "mcp-remote",8        "https://linkedin-mcp.theona.app/mcp"9      ]10    }11  }12}

claude_desktop_config.json

Remote · HTTPPublisher installStep-by-step: add this in Claude

Remote URL or a command on your machine? How the two installs differ

Run on PlugMCP

Host a copy with our keys and logs.

A new server you create. It is not this listing's official endpoint. Use the publisher install when you want their URL and their credentials.

Launch

Server facts

Remote

Transport: http
Version: 0.1.0
Last checked

Tools

No tool list yet. Remote servers get one after the first health check.

FAQ

Questions

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: create_post, update_post_content, submit_review, 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: create_post, list_posts, get_post, update_post_content, str_replace_post_content, set_post_state, set_post_date, delete_post. Versions: list_versions, get_version_diff, revert_to_version. Review: submit_review, list_reviews. Comments: add_comment, list_comments, resolve_comment. Attachments: prepare_attachment_upload, attach_file, list_attachments. Preview: render_preview. Webhooks (subscribe to post lifecycle events): create_webhook, list_webhooks, update_webhook, delete_webhook, list_webhook_deliveries. 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 ATTACHMENT_UPLOAD_SECRET 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 planner_mcp_….

A key opens /mcp for one workspace as the user who created it, and /mcp still re-checks that membership on every request. Only the key's sha256 is stored, so it is shown once and can only be revoked afterwards. When the key store cannot be reached, /mcp answers 503 rather than 401, so a client holding a working key is not told to replace it.

Discovery

Two unauthenticated documents let a client — or an MCP registry — learn what this server is and how to authenticate before it holds any credential:

Path	What it says
`/.well-known/mcp.json`	Server card: name, description, version, source repo, and the `streamable-http` endpoint at `/mcp`. Shaped to the MCP registry's `server.json` schema, so the bytes served here are the bytes submitted when publishing to a registry. The auth scheme rides in `_meta` under the registry's reverse-DNS key, since server.json has no first-class field for it.
`/.well-known/oauth-protected-resource/mcp`	RFC 9728 Protected Resource Metadata: the resource identifier, the authorization server, and the single `planner:agents` scope. This is what `/mcp`'s 401 `WWW-Authenticate` header points at, and it stays authoritative — the card only signposts it.

The card is served in every configuration; with AUTH_ENABLED unset it advertises authorization: { type: "none" } and the PRM is not registered at all, because the OAuth authorization server it would name is not mounted either. Both documents are built from APP_PUBLIC_BASE_URL, the same value the token check validates aud against.

The server's name and version live in apps/server/src/mcp/identity.ts and feed both the card and the serverInfo block of the MCP initialize response, so a registry listing cannot drift from what a connected client sees.

Publishing to the registry

Listed in the official MCP registry as app.theona/linkedin-content-planner. The namespace is the reverse DNS of theona.app and is proved by an Ed25519 TXT record on that domain's apex; the private half is MCP_REGISTRY_DNS_KEY and exists nowhere else. Rotation is one new key pair, one edited TXT record, one replaced secret — which is why the key needs no escrow and why any doubt about it should be answered by rotating rather than investigating.

It is an environment secret on mcp-registry, not a repository secret. A repository secret is readable by any workflow that anyone with write access adds; this one is released only to a job that names the environment and clears its rules — a required reviewer, and deployments restricted to v* tags. So pushing a tag does not publish: it opens a run that waits for a human.

Releasing is pushing a v<version> tag once the new version is deployed. The Publish to MCP Registry workflow fetches /.well-known/mcp.json from production and submits those bytes; nothing in this repository restates the card, so there is no second copy to drift. The order matters and the workflow enforces it: a tag whose version does not match what the deployed server reports fails the run rather than publishing the previous release's card under the new version's name. Deploy, then tag.

Monorepo layout

apps/server — REST API + MCP server (Streamable HTTP at /mcp), same process, same core logic.
apps/web — React UI: backlog, calendar, post review.
packages/core — domain types and service layer shared by REST and MCP.
packages/formatting — markdown-subset ⇄ LinkedIn Unicode formatting.
packages/db — Drizzle ORM schema and migrations.

License

PolyForm Noncommercial License 1.0.0. Source-available, not OSI open source: free to use, modify, and self-host for any noncommercial purpose; any commercial or paid use requires a separate license from Theona, Inc.

Add this server

Host a copy with our keys and logs.

Server facts

Tools

Questions

How do I install LinkedIn Content Planner?

Does LinkedIn Content Planner need an API key?

What transport does LinkedIn Content Planner use?

When was LinkedIn Content Planner last checked?

Documentation

LinkedIn Content Planner (MCP)

Local development

MCP tool surface

Uploading an attachment

Access keys

Discovery

Publishing to the registry

Monorepo layout

License