mcp-publication-cadence-tracker について
会社の長文コンテンツの公開量と、公開ペースの加速・減速を測る Apify ベースの MCP サーバーです。コンテンツや市場の調査向けで、ページ更新を新規記事と誤認しないよう公開日を検証します。
主な機能
- 01月間公開ペースと記事数
- 02加速・減速トレンドの判定
- 03ブログや公開セクションの検出
- 04公開日の信頼性チェック
- 05根拠と信頼度のフィールド
活用シーン
- 01企業間のコンテンツ公開状況を比較
- 02編集コンテンツの変化を追跡
- 03企業のコンテンツ運営を評価
MCP 対応
MCP クライアントに `track_publication_cadence` を公開し、単一または複数ドメインのリクエストを Apify Actor に渡して分析結果を返します。`APIFY_TOKEN` が必要です。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
1掲載時のツール一覧 · 2 週間前に更新
| パラメーター | 型 | 必須 | 説明 |
|---|---|---|---|
| domain | string | いいえ | 単一の企業ドメイン(例:zapier.com)。domain または domains のいずれかを指定してください。 |
| domains | array | いいえ | バッチモード:1 回の呼び出しで複数の企業ドメインを分析します。domain より優先されます。各ドメインの処理時間は最大 domain_time_budget_ms(デフォルト 75 秒)で、batchSize 個のドメインを同時に実行します。そのため、デフォルト設定で 20 個のドメインを処理すると約 12 分かかり、この呼び出しは全処理の完了まで待機します。 |
| batchSize | integer | いいえ | 同時に分析するドメイン数です。デフォルトは 2 です。 |
| skipCache | boolean | いいえ | 強制的に再クロールし、3 日間の結果キャッシュを無視します。 |
| page_concurrency | integer | いいえ | 1 つのドメイン内で同時に取得するページ数です。範囲は 1~16、デフォルトは 8 です。 |
| max_pages_to_date | integer | いいえ | 日付を特定するためにドメインごとに取得する投稿ページ数です。デフォルトは 400 です。この上限を超える場合、アーカイブ全体から均等に抽出したサンプルでカウントを推定し、counts_are_estimate を true に設定します。大規模なアーカイブで数値の精度を高めるには上限を増やしますが、実行時間が長くなります。 |
| request_timeout_ms | integer | いいえ | HTTP リクエストごとのタイムアウト(ミリ秒)。3000~20000、デフォルトは 9000 です。 |
| max_sitemap_fetches | integer | いいえ | ドメインごとに取得するサイトマップファイル数の上限です。範囲は 4~40、デフォルトは 18 です。サイトマップインデックスが深くネストされたサイトでは、実行時間を制限するために値を下げてください。 |
| domain_time_budget_ms | integer | いいえ | ドメインごとの厳密な実時間上限です。デフォルトは 75000 です。上限に近づくとクロールを停止し、タイムアウトさせる代わりに partial_result true と信頼度を下げた行を返します。 |
詳細
Publication Cadence Tracker MCP サーバー
Apify 上の Mamba Labs Publication Cadence Tracker アクター用 MCP サーバーです。
企業のドメインを指定すると、その企業が月にどれくらい長文コンテンツを公開しているか、またそのペースが上昇しているか下降しているかをエージェントに伝えます。
ツール
track_publication_cadence
ドメインごとにフラットな行を返します。各行には、posts_last_30d、posts_last_90d、posts_last_12m、avg_posts_per_month、cadence_trend(accelerating、steady、declining、dormant、unknown)、trend_pct_change、most_recent_post_date、days_since_last_post、publication_url、formats_detected[]、distinct_authors_count、discovery_method、confidence、引用可能な文字列の配列 evidence[] が含まれます。
件数ではなくトレンドを示す理由
月に4本は特筆すべきことではありません。6か月で4本から12本に増えたなら、コンテンツ運用がスタッフの対応能力を超えつつあるということです。比較対象を明示します。直近90日と、それ以前の275日を比較し、どちらも月あたりの投稿数に換算します。25%以上の増減をそれぞれ accelerating と declining と判定します。
これは編集コンテンツの公開量であり、変更履歴の監視ではありません。リリースフィードは検出して除外し、公開コンテンツとして数えません。
提示を拒む数値
公開日は投稿ページから取得し、サイトマップの lastmod からは取得しません。測定したURLペア100組では、6サイト中4サイトで lastmod がページ自身の dateModified と連動し、datePublished より中央値で151~1653日遅れていました。これをもとに公開ペースを算出すると、古い投稿を200件更新した企業を、投稿を200件公開した企業として報告することになります。
ページのフィールドも同じように信頼できない場合があるため、その分布とサイトのフィードに照らして検証します。信頼性がない場合、date_source_reliable は false になり、すべての件数が null になります。数値を引用する前に、このフィールドを確認してください。
稼働中の9ドメインで測定した結果、公開元6社中5社で公開ペースを算出でき、対照サイト3社中3社で正しく何も返しませんでした。1件の未検出は、日付フィールドが編集日時と連動しているサイトをガードが拒否したものです。
track_publication_cadence
| 入力 | 型 | 備考 |
|---|---|---|
domain | string | 企業ドメインを1つ指定します。 |
domains | string[] | 一括指定します。domain より優先されます。 |
max_pages_to_date | integer | ドメインごとに取得する投稿ページ数です。デフォルトは400です。この値を超える場合、均等なサンプルから件数を推定します。 |
domain_time_budget_ms | integer | ドメインごとのハードな実行時間上限です。デフォルトは75000です。 |
batchSize | integer | 同時に処理するドメイン数です。デフォルトは2です。 |
skipCache | boolean | 3日間の結果キャッシュを無視します。 |
page_concurrency | integer | 1~16、デフォルトは8です。1つのドメイン内で一度に取得するページ数です。 |
max_sitemap_fetches | integer | 4~40、デフォルトは18です。ドメインごとに取得するサイトマップファイル数の上限です。 |
request_timeout_ms | integer | 3000~20000、デフォルトは9000です。HTTPリクエストごとのタイムアウトです。 |
max_charge_usd | number | この呼び出しに対する任意の支出上限です(USD)。実行費用がこの額を超える課金の前にアクターが停止し、すでに課金された行はすべて保持します。 |
実際に測定するもの
企業にブログがあるかどうかではありません。どれだけ投稿したか、いつ投稿したか、投稿頻度が変化したかを測定します。
ブログを見つける作業が大半を占め、素朴な実装ではここで失敗します。ブログは apex とは別のホストに置かれていることが多く、apex のサイトマップには記載されていません(blog.hubspot.com)。ホームページには変更履歴フィードだけが掲載されている一方で、実際のブログには何度もリンクされている場合があります(about.gitlab.com)。パスにロケールが付くことも多いため、/en-uk/ や /bg-bg/ によってアーカイブが40個に分断されることがあります。これらはすべて対応済みで、publication_url はロケール付きのセクションを https://example.com/*/knowledge/ のように示します。
数値を信頼する前に確認すべき3つのフィールドです。 date_source_reliable が false の場合、サイトの日付フィールドは公開日ではなく編集日を示しており、すべてのカウントが null に設定されています。counts_are_estimate が true の場合、アーカイブがページ数の上限を超えていたため、カウントは均等に抽出したサンプルを基に拡大推計されています。そのため、実行ごとに数件の差が生じることがあります。partial_result が true の場合、実行時間の上限によりクロールが停止しており、数値は下限値です。
料金
Apify ではイベントごとに課金され、料金はお客様ご自身の Apify アカウントに請求されます。ライブ料金レコードに記載の価格(2026-10-16 時点):
| イベント | イベントあたりの料金(USD) | 課金のタイミング |
|---|---|---|
actor-start | $0.00005 | 実行開始時に1回課金されます。 |
domain-analyzed | Free プランでは $0.004、上位の Apify プランでは $0.0034 まで割引 | 分析したドメインごとに1回課金されます。公開セクションがないドメインや、日付フィールドが公開日ではなく編集日を示していると判明したドメインも、分析対象としてカウントされ、課金されます。 |
アクターの Apify ページに最新の料金が記載されています。このサーバーを実行すると Apify クレジットを消費します。
セットアップ
{
"mcpServers": {
"mamba-publication-cadence-tracker": {
"command": "npx",
"args": ["-y", "@mambalabsdev/mcp-publication-cadence-tracker"],
"env": { "APIFY_TOKEN": "your-apify-token" }
}
}
}
console.apify.com/account/integrations でトークンを取得してください。読み取り専用です。分析したドメインごとに Apify クレジットを消費します。
こちらからも利用できます
このツールは、Mamba Labs のその他の GTM アクターとともに、GTM Suite 統合サーバーからも利用できます。複数のサーバーではなく、1つのサーバーを実行したい場合にご利用ください。
Mamba Labs が開発しました。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。