LinkedIn Content Planner

LinkedIn コンテンツプランナー（MCP）

人間がテキストボックスに入力するためではなく、AI エージェント向けに構築された LinkedIn コンテンツパイプラインです。エージェント （Claude Code、Claude Desktop、または任意の MCP 対応クライアント）は、 実行するスケジュール（cron、エージェントのループ、チャットセッションなど）に応じて、MCP ツールを直接呼び出し、 投稿の下書き、書式設定、レビューパイプラインへの移動を行います。使用するツールは create_post、 update_post_content、submit_review などです。人間が行うのは、ウェブ UI でレビューし、コメントし、 承認または変更を依頼することだけです。投稿が公開される前に、スケジュール管理ツールを手動で操作するのではなく、 マージ前に PR をレビューするのと同じ流れです。

マルチテナント対応で、OAuth によるセキュリティ保護が初期状態で有効です。エージェントは、プランナー独自の OAuth 2.1 認可サーバー（PKCE、動的クライアント登録）に対して認証を行い、すべての MCP 呼び出しは 呼び出し元のワークスペースにスコープされます。

設計の全容については、PLAN.md と ARCHITECTURE.md をご覧ください。

ローカル開発

必要なもの：Node 20 以降、pnpm、Postgres 16 インスタンス（infra/docker-compose.yml 経由、またはローカルインストール）。

# 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 ツール一覧

投稿：create_post、list_posts、get_post、update_post_content、str_replace_post_content、 set_post_state、set_post_date、delete_post。バージョン：list_versions、get_version_diff、 revert_to_version。レビュー：submit_review、list_reviews。コメント：add_comment、 list_comments、resolve_comment。添付ファイル：prepare_attachment_upload、attach_file、 list_attachments。プレビュー： render_preview。Webhook（投稿のライフサイクルイベントを購読）：create_webhook、 list_webhooks、update_webhook、delete_webhook、list_webhook_deliveries。すべてのツールスキーマは /mcp エンドポイント自体で提供されます。各ツールの設計上の根拠については、PLAN.md をご覧ください。

添付ファイルのアップロード

attach_file はインラインで base64 を受け取りますが、実用的なのは小さなファイルに限られます。160 KB の画像でも base64 では約 217,000 文字になり、ほとんどのエージェントが使えるコンテキスト量を超え、黙ってデータを破損させずに 再入力するのはどのエージェントにとっても困難です。それより大きいファイルは、代わりにチケット経由でアップロードします。

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

URL にはその投稿だけを対象とする HMAC 署名付きチケットが埋め込まれており、有効期間は 15 分で、その後は拒否されます。 どちらの方法も同じ attachFile サービスに集約されるため、ファイルあたり 25 MB、ワークスペースあたり 250 MB の 上限が同様に適用されます。複数のインスタンスを実行する場合は ATTACHMENT_UPLOAD_SECRET を設定してください。 未設定の場合、各プロセスはそれぞれ独自のランダムキーで署名するため、あるインスタンスが発行したチケットは 別のインスタンスでは検証できません。

アクセスキー

Apify Standby Actor のように、OAuth フローを実行できない MCP クライアントもあります。この場合、Authorization ヘッダーには呼び出し元の Apify トークンがすでに含まれています。そのようなクライアントを使用する場合は、 サインイン済みのユーザーが Connect ページで長期間有効なアクセスキーを作成します（/connect?label=Apify にアクセスすると フォームに値があらかじめ入力されます）。クライアントは Authorization: Bearer planner_mcp_… としてキーを送信します。

キーを使うと、作成したユーザーとして、1 つのワークスペースの /mcp にアクセスできます。また、/mcp はリクエストごとに そのユーザーのメンバーシップを再確認します。保存されるのはキーの sha256 のみで、キーは一度だけ表示され、 その後は取り消すことしかできません。キーストアにアクセスできない場合、/mcp は 401 ではなく 503 を返すため、 有効なキーを持つクライアントにキーの置き換えを要求することはありません。

ディスカバリー

クライアントや MCP レジストリは、認証情報を保持する前に、このサーバーの概要と認証方法を確認できます。認証なしでアクセスできるドキュメントが 2 つあります。

パス	内容
/.well-known/mcp.json	サーバーカードです。名前、説明、バージョン、ソースリポジトリ、および /mcp の streamable-http エンドポイントを記載しています。MCP レジストリの server.json schema に準拠しているため、ここで提供されるデータは、レジストリへの公開時に送信されるデータと同一です。server.json には認証方式を記述する専用フィールドがないため、認証方式はレジストリの逆 DNS キーに対応する _meta に格納されています。
/.well-known/oauth-protected-resource/mcp	RFC 9728 の保護対象リソースメタデータです。リソース識別子、認可サーバー、および唯一の planner:agents スコープを記載しています。/mcp の 401 WWW-Authenticate ヘッダーがこのドキュメントを指し、サーバーカードは参照先を示すだけで、こちらが正式な情報源となります。

カードはどの設定でも提供されます。AUTH_ENABLED が未設定の場合は authorization: { type: "none" } を通知し、PRM は登録されません。PRM に記載する認可サーバーもマウントされないためです。どちらのドキュメントも APP_PUBLIC_BASE_URL をもとに作成されます。これはトークン検証で aud の照合に使われる値と同じです。

サーバーの名前とバージョンは apps/server/src/mcp/identity.ts に定義されており、カードと MCP の initialize 応答の serverInfo ブロックの両方に使われます。そのため、レジストリの掲載情報と、接続したクライアントに表示される情報が食い違うことはありません。

レジストリへの公開

公式 MCP レジストリに app.theona/linkedin-content-planner として掲載されています。この名前空間は theona.app の逆 DNS 名であり、そのドメインの apex にある Ed25519 TXT レコードで所有権を証明しています。秘密鍵は MCP_REGISTRY_DNS_KEY で、ほかの場所には存在しません。ローテーションする場合は、新しい鍵ペアを 1 つ作成し、TXT レコードを 1 つ編集し、シークレットを 1 つ置き換えます。そのため、鍵をエスクローする必要はなく、疑念が生じた場合は調査するよりローテーションするべきです。

これはリポジトリシークレットではなく、mcp-registry の環境シークレットです。リポジトリシークレットは、書き込み権限を持つ人が追加したすべてのワークフローから読み取り可能です。一方、このシークレットが渡されるのは、環境を指定し、そのルールを満たすジョブに限られます。ルールには必須のレビュアーと、v* タグに限定されたデプロイが含まれます。したがって、タグをプッシュしても公開は実行されません。人による承認を待つ実行が開始されます。

リリースは、新バージョンをデプロイした後に v<version> タグをプッシュして行います。Publish to MCP Registry ワークフローは、本番環境から /.well-known/mcp.json を取得し、そのデータを送信します。リポジトリ内でカードの内容を再定義していないため、食い違いが生じる 2 つ目のコピーはありません。順序が重要であり、ワークフローでその順序が強制されます。タグのバージョンがデプロイ済みサーバーの報告するバージョンと一致しない場合、前のリリースのカードを新しいバージョン名で公開するのではなく、実行が失敗します。先にデプロイし、その後タグを付けてください。

モノレポの構成

• apps/server — REST API と MCP サーバー（/mcp で Streamable HTTP を使用）。同じプロセスで、同じコアロジックを共有します。
• apps/web — React UI：バックログ、カレンダー、投稿レビュー。
• packages/core — REST と MCP で共有するドメイン型とサービスレイヤー。
• packages/formatting — Markdown サブセットと LinkedIn の Unicode 書式との相互変換。
• packages/db — Drizzle ORM のスキーマとマイグレーション。

ライセンス

PolyForm Noncommercial License 1.0.0。ソースコードは公開されていますが、OSI のオープンソースではありません。非営利目的であれば、無料で使用、変更、セルフホストできます。商用利用または有料利用には、Theona, Inc. から別途ライセンスを取得する必要があります。