PostHog

PostHog MCP

PostHog の公式 MCP サーバーです。PostHog はあなたのプロダクトをセルフドライビングにします — データを読み取り、あなたとともに変更を出荷し、決してあなたなしでは行いません — そしてこのサーバーは MCP クライアント（Claude、Cursor、VS Code、Zed など）にその完全なサーフェスを提供します：アナリティクスと SQL、ダッシュボード、実験、フィーチャーフラグ、サーベイ、セッションリプレイ、エラートラッキングなどです。

ドキュメント: https://posthog.com/docs/model-context-protocol

MCP サーバーを使用する

クイックインストール

以下のコマンドを実行すると、MCP サーバーを Cursor、Claude、Claude Code、VS Code、Zed に自動的にインストールできます：

npx @posthog/wizard@latest mcp add

手動インストール

1. MCP Server preset を使用してパーソナル API キーを取得します。

2. デスクトップクライアント（例：Cursor、Windsurf、Claude Desktop）に MCP 設定を追加し、パーソナル API キーを追加します

{
  "mcpServers": {
    "posthog": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote@latest",
        "https://mcp.posthog.com/mcp",
        "--header",
        "Authorization:${POSTHOG_AUTH_HEADER}"
      ],
      "env": {
        "POSTHOG_AUTH_HEADER": "Bearer {INSERT_YOUR_PERSONAL_API_KEY_HERE}"
      }
    }
  }
}

最小限の Node クライアント（Streamable HTTP）

IDE の外から Node で MCP を呼び出したい場合は、Model Context Protocol SDK の Streamable HTTP トランスポートを使用してください。

• 認証: パーソナルな PostHog API キーを使用し、Authorization に Bearer トークンとして渡します。
• Accept ヘッダー: クライアントは Accept: application/json, text/event-stream を必ず含める必要があります。
• ライフサイクル: MCP では initialize の後にクライアントからの notifications/initialized が必要です。SDK は connect() 中にこれを行います。

// tools-list.mjs
import { Client } from '@modelcontextprotocol/sdk/client/index.js'
import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js'
import { ListToolsResultSchema } from '@modelcontextprotocol/sdk/types.js'
import { mkdirSync, writeFileSync } from 'node:fs'
import { join } from 'node:path'
import { URL } from 'node:url'

const AUTH = process.env.POSTHOG_AUTH_HEADER // "Bearer phx_…"
const MCP_URL = process.env.MCP_URL || 'https://mcp.posthog.com/mcp'

if (!AUTH?.startsWith('Bearer ')) {
  console.error('Set POSTHOG_AUTH_HEADER="Bearer phx_..."')
  process.exit(1)
}

const transport = new StreamableHTTPClientTransport(new URL(MCP_URL), {
  requestInit: {
    headers: {
      Authorization: AUTH,
      // Required for Streamable HTTP (JSON + SSE)
      Accept: 'application/json, text/event-stream',
    },
  },
  serverInfo: { name: 'example-node-client', version: '0.0.1' },
})

const client = new Client({ name: 'example-node-client', version: '0.0.1' })

// Handles initialize + notifications/initialized
await client.connect(transport)

const toolsResp = await client.request({ method: 'tools/list' }, ListToolsResultSchema) // { tools: [...] }
const tools = toolsResp?.tools ?? []
console.log('Tools:', tools.length)

// (Optional) Save the full JSON-RPC envelope to a file (run from repo root)
const envelope = { jsonrpc: '2.0', id: 'list-1', result: toolsResp }
mkdirSync('reports', { recursive: true })
writeFileSync(join('reports', 'tools-list-http.json'), JSON.stringify(envelope, null, 2))
console.log('Saved: reports/tools-list-http.json')

await client.close()

なぜこれらのヘッダーと手順が必要なのか？

• Streamable HTTP では、Accept ヘッダーに JSON と SSE の両方を含める必要があります。
• initialize の後、クライアントは notifications/initialized を送信する必要があります。SDK は connect() 内でこれを行います。

利用可能なツールとセットアップフローについては、PostHog MCP のメインドキュメントも参照してください: https://posthog.com/docs/model-context-protocol

プロンプトの例

以下は、現実的なプロンプトと期待される出力を示す詳細な例です：

例 1: フィーチャーフラグの管理

プロンプト: 「'new-checkout-flow' という名前のフィーチャーフラグを、ユーザーの 20% に対して有効にして作成し、その設定を見せて」

何が起こるか:

1. create-feature-flag ツールが 20% のロールアウトでフラグを作成します
2. キー、ロールアウト率、ターゲティングルールを含むフラグ設定を返します

期待される出力:

Created feature flag 'new-checkout-flow':
- Key: new-checkout-flow
- Active: true
- Rollout: 20% of all users
- URL: https://us.posthog.com/project/<project-id>/feature_flags/12345

例 2: アナリティクスクエリ

プロンプト: 「過去 7 日間にサインアップしたユニークユーザー数は、日別に分けるとどれくらい？」

何が起こるか:

1. query-trends ツールが $signup イベントをフィルタリングするトレンドクエリを実行します
2. ユニークユーザー集計を含む日別のカウントを返します

期待される出力:

Signups over the last 7 days:

| Date       | Unique users |
|------------|--------------|
| 2025-01-17 | 142          |
| 2025-01-18 | 156          |
| 2025-01-19 | 98           |
| ...        | ...          |

Total: 847 unique signups

例 3: A/B テストの作成と監視

プロンプト: 「チェックアウトページへのコンバージョンを測定する、価格ページの A/B テストを作成して」

何が起こるか:

1. experiment-create ツールがコントロール/テストバリアントを含む実験を作成します
2. ファネルメトリクスを設定します: 価格ページビュー → チェックアウトページビュー
3. バリアント割り当て用の関連フィーチャーフラグを作成します

期待される出力:

Created experiment 'Pricing page test':
- Feature flag: pricing-page-test
- Variants: control (50%), test (50%)
- Primary metric: Funnel conversion (pricing_page → checkout)
- Status: Draft (ready to launch)
- URL: https://us.posthog.com/project/<project-id>/experiments/789

例 4: エラーの調査

プロンプト: 「今週の私のプロジェクトにおける上位 5 件のエラーと、影響を受けたユーザー数は？」

何が起こるか:

1. query-error-tracking-issues-list ツールが発生回数でソートされたエラーグループを取得します
2. 影響を受けたユーザー数を含むエラーの詳細を返します

期待される出力:

Top 5 errors this week:

1. TypeError: Cannot read property 'id' of undefined
   - Occurrences: 1,247
   - Users affected: 89
   - First seen: 2 days ago

2. NetworkError: Failed to fetch
   - Occurrences: 856
   - Users affected: 234
   - First seen: 5 days ago
...

クイックプロンプト

よりシンプルなクエリには、短いプロンプトを使用できます：

• 「有効になっているフィーチャーフラグは？」
• 「今週の LLM コストを見せて」
• 「ダッシュボードを一覧表示して」
• 「どのイベントがトラッキングされている？」

機能のフィルタリング

MCP URL にクエリパラメータを追加することで、利用可能なツールを制限できます。機能が指定されていない場合は、すべてのツールが利用可能です。機能が指定されている場合は、それらの機能に一致するツールのみが公開されます。

https://mcp.posthog.com/mcp?features=flags,workspace,dashboards

利用可能な機能:

機能	説明
actions	アクション
alerts	アラート
annotations	アノテーション
batch_exports	データパイプライン
business_knowledge	ビジネスナレッジ
canvas	キャンバス
cohorts	コホート
conversations	会話
core	コアユーティリティ（プロジェクト切り替え、ドキュメント検索）
customer_analytics	カスタマーアナリティクス
dashboards	ダッシュボード
data_catalog	データカタログ
data_schema	データスキーマの探索
data_warehouse	データウェアハウス
debug	デバッグおよび診断ツール
docs	PostHog ドキュメント検索
early_access_features	早期アクセス機能
endpoints	エンドポイント
engineering_analytics	エンジニアリングアナリティクス
error_tracking	エラートラッキングアラート
events	イベントおよびプロパティの定義
experiments	実験
feedback	PostHog チームへのフィードバック送信
field_notes	フィールドノート
flags	フィーチャーフラグ
health_issues	ヘルス
hog_function_templates	CDP 関数テンプレートの閲覧
hog_functions	関数
insights	インサイトとアナリティクス
integrations	インテグレーション
links	PostHog アプリ URL の生成
llm_analytics	AI オブザーバビリティ
logs	ログ
managed_migrations	マネージドマイグレーション
marketing_analytics	マーケティングアナリティクス
messaging	メッセージング
mcp_analytics	MCP アナリティクス
mcp_store	MCP ストア
metrics	メトリクス
notebooks	ノートブック
persons	人物
platform_features	プラットフォーム機能
product_analytics	プロダクトアナリティクス
reminders	リマインダー
replay	セッションリプレイ
replay_vision	リプレイビジョン
reverse_proxy	リバースプロキシレコードの管理
review_hog	ReviewHog
signals	シグナル
skills	スキル
sql	SQL クエリの実行
stamphog	Stamphog
streamlit_apps	Streamlit アプリ
subscriptions	サブスクリプション
surveys	サーベイ
tasks	タスク
tracing	トレーシング
visual_review	ビジュアルレビュー
warehouse_sources	ウェアハウスソース
web_analytics	Web アナリティクス
workflows	ワークフロー
workspace	組織およびプロジェクトの管理

注記: 機能名ではハイフンとアンダースコアは同等に扱われます（例: error-tracking と error_tracking はどちらも機能します）。

機能ごとに利用可能なツールを確認するには、ドキュメントを参照するか、schema/tool-definitions-all.json を確認してください。

cli モードでの学習とスキル

Claude web とデスクトップは、exec のシリアライズされた inputSchema が 16,384 文字に達すると、exec を通知なく破棄します。 cli モードでは、exec ツールは通常の呼び出しに必要なガイダンスをそのスキーマ内に保持します。 コンパクトなツールドメインインデックスは command スキーマ内にインラインのまま残るため、Claude は呼び出しを行う前に関連するツールを発見できます。 オプションのタスク固有のガイダンスは、同じツールを通じて提供されます:

• learn は利用可能な組み込みガイドを一覧表示し、有効な場合は PostHog/プロジェクトのスキルディスカバリー構文も一覧表示します。
• learn analytics は詳細な分析ガイダンスと例を読み込みます。
• learn visualizations は可視化が利用可能な場合にレンダリングガイダンスを読み込みます。
• learn urls は PostHog アプリのリンクフォーマット規則を読み込みます（他のクライアントではインラインのまま保持されますが、Claude web とデスクトップではスキーマの予算を保護するためにガイドとして提供されます）。
• learn feedback はフィードバックが利用可能な場合にフィードバックガイダンスを読み込みます。
• learn skills は公開された PostHog バンドル（posthog:）と現在のプロジェクトの Skills ストア（project:）から修飾名を一覧表示します。
• learn -s "<最大 8 個のキーワード>" は両方のソースを名前、説明、Markdown 本文、およびバンドルされたファイルパス内で検索します。クエリに 8 個を超えるキーワードが含まれる場合、より長いキーワードが優先されます。両方のソースの結果は 1 つの関連性順にマージされます。
• learn -d <source>:<skill> [...] は各指定されたスキルの 1 行の説明を、その本文を読むことなく出力します（1 回の呼び出しにつき最大 20 個）。不明な名前はバッチを失敗させることなくインラインで報告されます。
• learn posthog:<skill> [path] または learn project:<skill> [path] は、スキルまたはそのバンドルされたファイルの 1 つを読み込みます。
• learn <source>:<skill> <path> [path...] は複数のバンドルされたファイルを、また learn <source>:<skill> [<source>:<skill>...] は複数のスキルを、1 回の呼び出しで読み込みます（最大 10 個のターゲット）。
• learn <source>:<skill> <path> -s "<最大 8 個のキーワード>" は 1 つの Markdown ファイル内を検索します。
• learn <source>:<skill> <path> --lines <start>:<end> は両端を含む行範囲を読み込みます。

組み込みガイドは Claude web とデスクトップに固有です。スキルディスカバリーは、mcp-exec-skills フィーチャーフラグが有効な場合、すべての cli モードクライアントが独立して利用できます。Claude Code を含む他のクライアントは、スキルコマンドのみを受け取り、Claude の組み込みガイドは受け取りません。フラグが存在しない、無効である、または評価できない場合、スキルコマンドはスキーマから省略され、実行時に拒否されます。 スキルディスカバリーが有効な場合、インラインプロンプトは Claude web とデスクトップを含むすべての非プラグイン cli クライアントに対し、自明でない PostHog の作業の前に learn -s "<タスクのキーワード>" で検索し、一致するものを正確な修飾名で読み込み、ツールを選択する前に読み込んだ SKILL.md に従うよう指示します。自明な検索や無関係な会話ではこのワークフローをスキップします。 スキルの使用は推奨です: 製品の call が learn をスキップしたために拒否されることは決してないため、MCP セッション ID を保持しているかどうかに関わらず、すべてのクライアントは同じように動作します。 スキルバンドルは Redis を通じて共有されます。各ポッドは起動時に一度だけ読み込み、メモリ上で解析して、その解析済みカタログからすべての learn コマンドに応答します。 バックグラウンドタイマーが Redis 内の小さなバージョンキーをポーリングし、バージョンが変わったときにのみ、ポッドはアーカイブのバイトデータを再度読み込みます。 共有コピーが10分より古い場合、同時に1つのポッドだけが条件付きリクエストを使ってソースからアーカイブを更新するため、リリースに変更がなければ304が返されます。 キャッシュされたバイトデータは30日間保持され、更新のたびに有効期限が延長されるため、ソースが停止していても最後に正常に取得したアーカイブを利用できます。 learn、initialize、discover のリクエストで、Redis からアーカイブを読み込むことはありません。 デフォルトでは、https://github.com/PostHog/posthog/releases/download/agent-skills-latest/skills.zip から読み込みます。 ローカル開発で別のアーカイブを使用するには、POSTHOG_MCP_SKILLS_URL を設定します。 カスタムのアーカイブ URL には別々の Redis キャッシュ名前空間が使われるため、ローカルバンドルが公開バンドルのキャッシュエントリーを読み取ったり、上書きしたりすることはありません。 プロジェクトのスキルは、リクエスト認証済みのプロジェクトから直接読み込まれ、MCP サーバーによってキャッシュされることはありません。 learn で公開されるのは、最新の有効な未分類スキルのみです。scouts などのカテゴリ別スキルは、それぞれ専用のサーフェスで提供されます。 プロジェクトの全文検索は、スキル10件、スキルごとに短いスニペット2件、データベースのタイムアウト5秒に制限されています。 個々の learn レスポンスは44,000文字未満に保たれます。サイズの大きなリファレンスでは、後続の検索や行の読み取りに使う見出しのアウトラインが返されます。 コマンドの固定構文はツールスキーマに保持され、スキル名と本文はリクエストされたときにのみ読み込まれます。 consumer=plugin と consumer=posthog-code では、機能フラグの設定にかかわらず、どちらのサーフェスも独自のスキルコンテキストをバンドルして提供するため、learn は省略されます。

その他のクライアントでは、コマンドのインラインリファレンス全体が保持されます。

ツールのフィルタリング

CLI モードでは、tools と exclude_tools は名前空間付きの接続ツールにも適用されます。features フィルターを指定すると、tools で明示的に指定されていない限り、接続ツールは除外されます。除外設定は明示的な選択より優先されます。

より細かく制御するには、tools クエリパラメーターを使って、ツール名で特定のツールを許可リストに指定できます。機能カテゴリにかかわらず、一覧にある完全一致のツール名だけが公開されます。

https://mcp.posthog.com/mcp?tools=dashboard-get,feature-flag-get-all,execute-sql

features と tools の両方を指定すると、両者は和集合として扱われます。つまり、機能カテゴリに一致するか、tools の一覧に含まれるツールが含まれます。これにより、機能グループを選択したうえで、個別のツールをいくつか追加できます。

https://mcp.posthog.com/mcp?features=flags&tools=dashboard-get

上記の例では、すべてのフラグツールに加えて dashboard-get が公開されます。

サーバーモード（ツールと CLI）

MCP サーバーは、PostHog の各ツールを個別に登録する（tools モード）か、すべてのツールを単一の exec CLI 風ツールの背後にまとめる（cli モード）かを選択できます。 すべてのクライアントで cli がデフォルトです。 呼び出し元がモードを指定していない場合、サーバーは、各ツールを個別に登録した構成のほうが適しているクライアントの短い許可リストに含まれる場合に限り、tools モードを自動選択します。現在は、自己申告されたクライアント名または Cursor/… User-Agent によって識別される Cursor が対象です。 OpenAI のすべての環境（ChatGPT、Codex、Agent Builder、Responses API）では、cli がデフォルトになります。OpenAI の openai-mcp クライアントは、公開済みプラグイン用に取得したツール一覧をキャッシュし、そのスナップショットをプラグインのすべてのユーザーに提供します。そのため、プラグインのリスト表示に使用するモードは、User-Agent ラベルから推測されるのではなく、OpenAI に送信する URL で指定します。

クエリパラメーターまたはヘッダーを使用して、モードを自分で固定できます。受け付ける値は tools と cli のみです。

https://mcp.posthog.com/mcp?mode=cli
https://mcp.posthog.com/mcp?mode=tools

x-posthog-mcp-mode: cli
x-posthog-mcp-mode: tools

値	動作
tools	tools モードを強制します（PostHog の各ツールに MCP ツールを 1 つずつ割り当てます）。
cli	cli モードを強制します（単一の exec ツールですべてのツールをまとめます）。

ヘッダーとクエリパラメーターの両方が設定されている場合、ヘッダーが優先されます。 明示的な値は常にクライアントの自動検出より優先されます。それ以外の値は無視され、自動検出が適用されます。

cli モードのコマンド仕様は、posthog.com/docs/model-context-protocol/tools で公開されています。このページには、ビルド時に schema/exec-command-reference.md が埋め込まれます。 このファイルは、scripts/generate-exec-docs.ts（hogli build:openapi の一部）が src/templates/sections/ 内のテンプレートから生成します。編集するのはこのファイルではなく、テンプレートです。

利用元の識別

PostHog MCP をインストールまたはプロキシするラッパーアプリや AI ツールのプラグインは、利用状況をインストール経路（例：プラグインからのインストールか、URL の手動貼り付けか）に紐付けるために、自己識別できます。ラップされる MCP クライアント（Claude Code、Cursor、…）は MCP の clientInfo ハンドシェイクで別途すでに記録されています。このシグナルは、ラッパーのコンテキストのみを示します。

https://mcp.posthog.com/mcp?consumer=plugin

x-posthog-mcp-consumer: plugin

ヘッダーとクエリパラメーターの両方が設定されている場合、ヘッダーが優先されます。予約済みの値：plugin（AI ツールのプラグインからのインストール）、posthog-code（PostHog Desktop Tasks サンドボックス）、slack（Slack 統合）。

データ処理

MCP サーバーは PostHog の米国および EU の Kubernetes クラスターで実行され、接続先のリージョンにセッション状態を保存します。 その前段にあるステートレスな Cloudflare Worker は、リクエストの認証とクラウドリージョンへのルーティングのみを行い、機密データは保存しません。

セルフホストインスタンスの使用

PostHog のセルフホストインスタンスを使用している場合は、MCP サーバーをローカルまたは独自のインフラストラクチャで実行する際に、POSTHOG_API_BASE_URL 環境変数を設定することで、カスタムベース URL を指定できます（例：POSTHOG_API_BASE_URL=https://posthog.example.com）。

開発

MCP サーバー（Node 上の Hono）をローカルで実行するには、次のコマンドを実行します。

pnpm run dev

または、リポジトリのルートから bin/start-mcp-server を使用します。このコマンドは .env の初期設定も行い、Redis とポートのデフォルト値を設定します。 その後、MCP の設定で https://mcp.posthog.com/mcp を http://localhost:8787/mcp に置き換えます。

サーバーはデフォルトでポート 8787 を使用し、.env から設定を読み込みます（.env.example を参照）。セッション状態の保存には、ポート 6379 で動作するローカルの Redis が必要です。本番環境へのデプロイでは、REDIS_URL に TLS で暗号化された rediss:// エンドポイントを設定する必要があります。

起動時には、接続の再試行を含め、Redis が準備完了になるまで最大 45 秒待機します。Redis への再接続ができなくなった場合、または制限時間を過ぎた場合、HTTP サーバーを起動せずにプロセスが終了します。

セッションキャッシュ

各 MCP トランスポートセッションは、project_id または organization_id による固定指定がない接続も含め、それぞれ独自のアクティブな組織とプロジェクトを保持します。固定指定のないセッションは、認証情報で許可された範囲内で、ユーザーのアクティブな組織とプロジェクトから開始します。その後のウェブサイト上での変更や、ほかの MCP セッションでの切り替えによって、この選択が変わることはありません。switch-project と switch-organization が更新するのは呼び出し元のセッションだけです。別の組織に切り替えると、以前のプロジェクトはクリアされます。

switch-project には正の整数の projectId が必要です。また、別名として project_id と new_project_id も使用できます。複数指定された場合は、projectId が優先され、次に project_id が優先されます。

MCP セッション ID を持たないクライアントは、代わりに SDK の conversation_id を使用します。最初のツール呼び出しで返されたハンドルを、以降の呼び出しで返してください。セッションまたは会話のハンドルを引き継がずに切り替えを行うと、エラーと新しいハンドルが返されます。そのハンドルを使って再試行すると、切り替えが適用されます。会話の状態は認証情報に紐付けられ、トランスポートセッションとは別に保存されます。いずれの識別情報もない呼び出しは、接続の固定指定またはデフォルトの選択から開始します。クライアントが会話ハンドルを保持できない場合は、接続 URL でプロジェクトまたは組織を固定指定してください。

従来の JSON-RPC バッチでは、各呼び出しの会話ハンドルが個別に復元されます。ラッパーの sessionId クエリパラメーターは分析用のヒントであり、会話ハンドルの代わりにはなりません。ラッパーのみを使った呼び出しでも、SDK から新しいハンドルが返されます。

セッションのデフォルト値は、明示的な選択とは別に、一度だけ保存されます。遅延して実行される検索では、そのリクエストのコンテキストを解決できますが、完了済みの切り替えが上書きされることはありません。

デフォルトのプロジェクト検出に失敗した場合、後続のリクエストはセッション開始時の組織内で再試行します。最初に成功したプロジェクト検出が採用され、明示的な切り替えが引き続き優先されます。組織を切り替える際、移行先のチーム一覧で選択済みプロジェクトがその組織に属すると確認できれば、認証情報でプロジェクトのメタデータを読み取れない場合でも、そのプロジェクトは保持されます。

セッションのクライアントコンテキストは、mcp:s:<id>:c キーにまとめて保存され、アイドル状態が 24 時間続くと期限切れになります。セッション内のリクエストごとに有効期限が更新されます。 同時実行されるリクエストは、Lua による比較とマージを通じてフィールドを統合するため、セッション中に初めて確認されたフィールドが、競合する書き込みによって失われることはありません。

mcp_session_cache_operations_total を監視し、read_error と write_error を確認してください。 どちらもノンブロッキングです。読み取りに失敗しても、現在のリクエストが持つコンテキストが使われるため、呼び出しが失敗するのではなく、アトリビューションの精度が低下します。 どちらの場合も [McpSessionRedisStore] を先頭に付けた警告がログに記録されるため、この処理経路での Redis 障害はメトリクスカウンターだけでなく、ログからも検索できます。

エッジプロキシワーカー（Cloudflare）

本番環境では、ステートレスなエッジルーターとして、薄い Cloudflare Worker が Hono のデプロイメントの前段に配置されます。このワーカーは OAuth メタデータエンドポイントを提供し、トークンを検証し、呼び出し元のクラウドリージョンを解決して、/mcp トラフィックを mcp.us.posthog.com / mcp.eu.posthog.com にプロキシします。 MCP プロトコル自体は提供しません。詳細は ARCHITECTURE.md を参照してください。 ワーカーのみをローカルで実行するには、次のようにします。

pnpm run dev:proxy

ローカルリソースを使った開発

MCP リソース（ワークフロー、プロンプト、例）をウォームロードしながら開発するには、次の手順に従います。

1. context-mill の開発サーバーを起動します：cd ../context-mill && npm run dev
2. ローカルリソースを使って MCP サーバーを起動します：pnpm run dev:local-resources（POSTHOG_MCP_LOCAL_SKILLS_URL を context-mill に向けて bin/start-mcp-server を実行します）

例のリポジトリでの変更は、次のリクエストから反映されます。

プロジェクト構成

• src/ - MCP サーバー：Hono アプリ（src/hono/）、ツールハンドラー（src/tools/）、プロンプトテンプレート（src/templates/）
• definitions/ - 手作業で作成された YAML ツール定義（モノレポ内の製品ごとの YAML は products/<product>/mcp/ にあります）
• schema/ - tool-definitions-all.json（ツールカタログ全体）などの生成されたスキーマファイル

開発コマンド

• pnpm run dev - MCP 開発サーバーを起動します
• pnpm run dev:proxy - エッジプロキシワーカー（wrangler）を起動します
• pnpm run lint / pnpm run format:check - ファイルを変更せずに、リンティングとフォーマットを確認します
• pnpm run lint:fix - 提案による修正は適用せず、安全なリンティング修正を適用します
• pnpm run format - Oxfmt のみでコードをフォーマットします
• pnpm run fix - 安全なリンティング修正を適用し、必ずコードをフォーマットして、いずれかのツールで発生した失敗を報告します

新しいツールの追加

ほとんどのツールは products/<product>/mcp/tools.yaml から生成されます。 その手順については、MCP ツール実装スキルとハンドブックのガイドに従ってください。 手書きのツールには、src/tools/README.md のみを使用してください。

環境変数

ルートディレクトリで .env.example を .env にコピーし、必要に応じて値を調整してください。

Model Context Protocol Inspector の設定

開発中は、MCP Inspectorを使用して、MCP ツール呼び出しの結果を直接確認できます。

次のコマンドを使用して起動できます。

npx @modelcontextprotocol/inspector npx -y mcp-remote@latest http://localhost:8787/mcp --header "\"Authorization: Bearer {INSERT_YOUR_PERSONAL_API_KEY_HERE}\""

または、MCP Inspector で次の設定を使用できます。

トランスポートの種類に STDIO を指定します。

コマンド：

npx

引数：

-y mcp-remote@latest http://localhost:8787/mcp --header "Authorization: Bearer {INSERT_YOUR_PERSONAL_API_KEY_HERE}"

Claude Desktop を使用した開発

Claude Desktop は MCP Apps をテストする最も簡単な方法の 1 つですが、PostHog Desktop はサポートしていません。Settings > Developer でアクセスを設定し、claude_desktop_config.json を次のように編集できます。

{
  "mcpServers": {
    "posthog-local": {
      "command": "npx",
      "args": ["-y", "mcp-remote@latest", "http://localhost:8787/mcp"]
    }
  }
}

プライバシーとサポート

• プライバシーポリシー： https://posthog.com/privacy
• 利用規約： https://posthog.com/terms
• サポート： https://posthog.com/questions または [email protected] までメールでお問い合わせください
• GitHub の課題： https://github.com/PostHog/posthog/issues

データの取り扱い

MCP サーバーは、お使いの PostHog インスタンスへのプロキシとして動作します。分析データは保存されません。すべてのクエリはお使いの PostHog プロジェクトに対して実行され、結果は AI クライアントに直接返されます。セッション状態（アクティブなプロジェクト／組織）は、API キーのハッシュをキーとして一時的にキャッシュされます。

EU のユーザーは、OAuth フローが EU の PostHog インスタンスにルーティングされるよう、mcp-eu.posthog.com エンドポイントを使用してください。