Amplitudeのデータを使用してライブ製品の問題を調査します。「今日、イベントXは発生しているか」「リリースによってYが動作しなくなったか」「問題Zの影響を受けているユーザーは誰か」といった質問に答えます。 確認してから検索する一連の流れ、検索パラメータの設定方法、よくある失敗パターンに対応しています。 **次のような場合に使用:** - インシデント（本番環境の障害）の原因分析 - 計測機能の動作確認 - 影響を受けたユーザーの特定
Investigates live product issues against Amplitude data — "is X firing today", "did the release break Y", "which users are affected by Z". Covers the verify-then-query loop, query_amplitude_data parameterization, and its common failure modes. Use for incident analysis, instrumentation checks, and affected-user discovery.
このMCPサーバーで最も一般的な多機能ジョブです。ライブイベント（実際に発生しているイベント）の動作を確認し、影響度を数値化し、影響を受けたユーザーを特定します。実際に観察された呼び出しは一つの流れに従います。その流れに従いましょう。
背景情報を確認する。 get_amplitude_context（引数なし）を実行してから、projectIdで再実行します。
プロジェクトIDを推測しないでください。
再利用を優先する。 search_amp_entitiesで同じ領域の既存分析を探してください。保存されたチャートには正しいイベント名とセグメント（データの分類方法）が既に含まれています。
クエリ前に用語体系を確認する。 manage_amp_eventsのaction: 'get'で候補となるイベント名が実在することを確認してください（カテゴリ、スキーマ内かどうか、クエリ可能かを返します）。get_properties（propertyType: 'event' | 'user' | 'group'）で正確なプロパティ名とスコープ（イベント・ユーザー・派生値のどれに属するか）を確認してください。名前を推測しないでください。誤った名前はデータが空の正しい形式のチャートを返し、これは「ゼロ」と読み取られます。
イベントが実際に流れているか確認する。 check_for_recent_event_ingestionで最初に観測された日時と最後に観測された日時を確認してください。イベントが流れていない場合、定義がいくら正確でもチャートは空になります。
影響度を数値化する。 query_amplitude_dataは細かく分割して実行してください。バージョン別、理由プロパティ別、プラットフォーム別に1回の呼び出しごとに1つの切り口とし、1回の巨大なクエリにしません。型指定されたchartパラメータ（kind: 'segmentation'、イベント、条件・グループ化・日付範囲を含む）を優先してください。これはサーバー側でコンパイルされ、検証と用語体系の確認が自動的に実行されるため、事前の確認呼び出しは不要です。環境固有の質問の場合は、本番環境と検証用環境のプロジェクトを比較してください。
影響を受けたユーザーを特定する。 ユーザーIDでグループ化してquery_amplitude_dataを実行し影響を受けたユーザーをランク付けしてから、use_amplitude_cohortsのaction: 'find'で全体を確認してください。
タイムラインを再構築する。 ユーザーごとにget_amp_user_dataをinclude: 'timeline'で実行し、バッチ処理してください（母集団分析の場合、10～20件の並列呼び出しは正常です。このツールは1回の呼び出しで最大10個の識別子を受け入れます）。
コンパイルエラーは自力で解決できます。 型指定されたパスは、400エラーで問題のあるフィールドと修正のヒントを返します。そのフィールドだけを修正して再実行してください。全体を再構築しないでください。最もよく見られる3つのエラー：時間単位がintervalと合わない相対範囲（「過去3年間」を週間隔で指定）— 「過去156週」に置き換えるか、時間間隔を変更してください。ファネル分析のconversion_windowにunitが없음。そのチャートタイプで有効でないフィルタ演算子（値の有無を判定するsetはすべてのタイプで機能します）。
日付範囲は必須です。date_rangeを明示的に設定してください。{relative: "Last 30 Days"}またはエポック秒の{start, end}のいずれか一方とし、両方を指定しないでください。日単位より細かい時間間隔は短い期間のみ対応します（時間単位はおよそ8日が上限）。日単位はおよそ30日が上限です。
すべてのフィルタには有効な演算子とスコープの一致が必要です。 直感ではなく、用語体系の確認からopとscopeを取得してください。スコープの不一致（「プロパティXはこのイベントタイプで追跡されていない」）は、ユーザープロパティをイベントプロパティとして使用したか、その逆を意味します。
セグメントは条件と行動を組み合わせます。 where（プロパティの条件）に加えてperformed（「期間内にイベントをN回以上実行したユーザー」）を指定します。すべてのユーザーを対象にする場合はsegmentsを完全に省略してください。
生definitionフォールバック（複合計算、生涯収益価値、高度なパラメータ）：失敗時、レスポンスにはチャートタイプのスキーマ（有効な値と動作例）が組み込まれています。それに基づいて修正して再実行してください。
read ETIMEDOUTはバックエンド側のタイムアウトです。日付範囲またはフィルタを絞り込んで、1回だけ再試行してください。
The most common multi-tool job on this MCP server: verify live event behavior, quantify impact, find affected users. Calls observed in the wild follow one arc — follow it too.
get_amplitude_context (no args) → again with projectId.
Do not guess project IDs.search_amp_entities for existing analyses of the same
area — saved charts already encode correct event names and segments.manage_amp_events action: 'get'
to confirm candidate event names exist (returns category, isInSchema,
isQueryable), get_properties
(propertyType: 'event' | 'user' | 'group') for the exact property names
and scope (event vs user vs derived). Never guess names — a wrong
name returns a well-formed chart with empty data, which reads as "zero".check_for_recent_event_ingestion confirms
first-seen/last-seen before you query — a silent event means the chart
will be empty no matter how correct the definition is.query_amplitude_data bursts — one slice per call (by
version, by reason property, by platform), not one mega-query. Prefer the
typed chart parameter (kind: 'segmentation', events + where/group_by +
date_range); it compiles server-side and validation + taxonomy checks run
automatically — no separate pre-flight call needed. Compare prod vs
staging/UAT projects when the question is environment-specific.query_amplitude_data with a user-ID group_by
to rank affected users → use_amplitude_cohorts action: 'find' for the
full set.get_amp_user_data include: 'timeline' per
user, batched (10–20 parallel calls is normal for population analysis;
the tool accepts up to 10 identifiers per call).interval ("Last 3 Years" at weekly interval — re-denominate as
"Last 156 Weeks" or change the interval); funnel conversion_window
missing unit; unknown filter operator for that chart kind (use set
for presence — works in every kind).date_range explicitly, either
{relative: "Last 30 Days"} or {start, end} epoch seconds, never both.
Sub-daily intervals only allow short windows (hour caps ~8 days); daily
granularity caps around 30 days.op
and scope from the taxonomy lookup, not intuition. A scope mismatch
("property X is not tracked on this event_type") means you used a user
property as an event property or vice versa.where (property
conditions) plus performed ("users who did event ≥N times in a window").
Omit segments entirely for all users.definition fallback (composition, revenueLtv, advanced params):
on failure the response embeds the chart-type schema with valid enums and
a working example — fix from that and retry.read ETIMEDOUT is a backend timeout — narrow the date range/filters and
retry once.原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。