linkedin-campaign-manager-mcp
LinkedIn Campaign Manager MCP
LinkedIn Marketing API用MCPサーバー。Claudeから平易な英語でキャンペーン、パフォーマンス、リード獲得フォームをクエリできます。
広告アカウント、キャンペーン、クリエイティブ、パフォーマンス分析、デモグラフィック、動画分析、予算の進捗管理、期間比較、コンバージョン、リード獲得フォーム、オーディエンス、ターゲティングファセットを網羅した19種類の読み取り専用ツール。LinkedInでスポンサードコンテンツ、リード獲得フォーム、アカウントベースのキャンペーンを運用するB2B有料ソーシャルチーム向けに構築されています。
なぜこれが必要なのか
LinkedIn Marketing APIは、非常に扱いづらいことで知られています。毎月のRosettaバージョニング、文書化されていないフィールドマッピング、分析用のRest.li形式のネストされたクエリパラメータ、そして黙って期限切れになる60日間のアクセストークンなどです。このサーバーは、それらすべてを内部で処理するため、dateRange=(start:(year:...))のようなコードを手書きする代わりに、平易な英語で質問することができます。
LinkedIn広告用の他のオープンソースMCPサーバーで、これほど深い機能を持つものはありません。ほとんどは「キャンペーンの一覧表示」で止まっています。本サーバーには、デモグラフィック、動画視聴完了ファネル、予算の進捗管理、期間比較、そしてMarketoやSalesforceとリードを照合するための個人情報（PII）を含むリード獲得フォームの回答が含まれています。
プロンプトの例
インストール後、Claudeに以下のように尋ねることができます：
「過去28日間のLinkedIn広告の支出傾向を、キャンペーングループ別に教えてください。」
「今月と先月の競合他社攻略キャンペーンのCPLを比較して、どのクリエイティブが数字を動かしましたか？」
「支出額トップのキャンペーンのデモグラフィックを取得して、どの役職や業界がコンバージョンしているか教えてください。」
「先月、最も送信率が高かったリード獲得フォームはどれですか？また、リード単価はいくらでしたか？」
「認知度向上キャンペーンの動画視聴完了ファネルを表示してください。どこで離脱が発生していますか？」
「予算超過のリスクがあるキャンペーンはありますか？すべてのアクティブなキャンペーンの予算進捗を表示してください。」
「昨日のリード獲得フォームの回答を取得して、Marketoと照合できるようにしてください。」
デモ
🎥 解説動画近日公開 — Claude Codeから60秒以内にLinkedInキャンペーンのパフォーマンスをクエリする方法。
ツール
ツール | 機能 |
| ユーザーがアクセス可能なすべての広告アカウント（ステータスと通貨を含む）。 |
| 単一アカウントの詳細：通貨、ステータス、タイプ、請求情報。 |
| アカウント内のキャンペーン。ステータスやキャンペーングループでフィルタリング可能。 |
| キャンペーンの詳細：ターゲティング基準、入札額、予算、目的。 |
| キャンペーングループ（予算や目的を共有するコンテナ）。 |
| 広告クリエイティブ。キャンペーンやステータスでフィルタリング可能。 |
| クリエイティブの詳細：見出し、コピー、URL、画像/動画URN。 |
| 指定期間のインプレッション/クリック/支出/コンバージョン/リード。DAILY/MONTHLY/YEARLY/ALLの粒度。 |
| 企業/企業規模/業界/職種/役職/職位/地域/国別のパフォーマンス。 |
| WoW/MoM/YoY比較。サーバー側で計算された_current/_prior/_delta/_pct_change列を含む。 |
| クリエイティブごとの動画視聴完了ファネル：開始 → 25% → 50% → 75% → 完了 + 完了率。 |
| 設定期間におけるアクティブなキャンペーンの支出対予算消化率。 |
| Insight Tagコンバージョンイベントの定義：タイプ、アトリビューションウィンドウ、有効ステータス。 |
| コンバージョンイベント別のパフォーマンス（CONVERSIONピボット）：クリック後対ビュー後の内訳。 |
| DMPセグメント：マッチングオーディエンス、企業リスト、結合/類似セグメントとそのサイズ。 |
| ターゲティング値（役職、スキル、企業、業界、場所、職位）のタイプアヘッド検索。 |
| リード獲得フォーム + 質問設定 + ステータス。 |
| 個人情報（名前、メール、企業、役職）を含む実際のフォーム送信データ。 |
| クリエイティブごとのLGF指標：フォーム開封率、送信率、リード単価。 |
セットアップ
1. インストール
npm install -g linkedin-campaign-manager-mcpまたは、クローンしてローカルでビルド：
git clone https://github.com/ZLeventer/linkedin-campaign-manager-mcp
cd linkedin-campaign-manager-mcp
npm install
npm run build2. LinkedIn Developerアプリの作成
Marketing APIは制限されています。特定の製品承認を受けたLinkedIn Developerアプリが必要です：
developer.linkedin.com にアクセスし、アプリを作成（会社ページに関連付けます）。
Productsタブ — 以下へのアクセスをリクエストします：
Marketing Developer Platform(r_ads,r_ads_reportingを含む)Lead Gen FormsまたはCommunity Management API(r_ads_leadgen_automationを含む)
LinkedInがアプリのアクセス権を手動で審査します（通常2〜6週間）。
Authタブ — Authorized Redirect URLs に
http://127.0.0.1:53123を追加します。 （LINKEDIN_OAUTH_PORTを変更した場合は、そのポート番号を使用してください）。Authタブから Client ID と Client Secret をコピーします。
製品承認がない場合、すべてのAPI呼び出しは403を返します。サーバーは正常にコンパイルおよび起動しますが、403はアプリレベルの権限の問題であり、コードの問題ではありません。
3. 環境設定
cp .env.example .env
# edit .env with your LINKEDIN_CLIENT_ID, LINKEDIN_CLIENT_SECRET,
# LINKEDIN_DEFAULT_AD_ACCOUNT (numeric ID from Campaign Manager URL)4. 認証（初回のみのOAuthフロー）
npm run authこれにより、ポート53123（または LINKEDIN_OAUTH_PORT）でローカルHTTPサーバーが開き、ターミナルに認証URLが表示され、OAuthコールバックを待機します。ブラウザで承認すると、コードがアクセストークンと365日間のリフレッシュトークンと交換され、token.json（モード0600）に保存されます。
リフレッシュトークンが期限切れになった場合（365日後）のみ、npm run auth を再実行する必要があります。
5. Claude Code（または任意のMCPクライアント）への接続
~/.claude.json の mcpServers に以下を追加します：
{
"mcpServers": {
"linkedin": {
"command": "linkedin-campaign-manager-mcp",
"env": {
"LINKEDIN_CLIENT_ID": "your_client_id",
"LINKEDIN_CLIENT_SECRET": "your_client_secret",
"LINKEDIN_TOKEN_PATH": "/absolute/path/to/token.json",
"LINKEDIN_DEFAULT_AD_ACCOUNT": "123456789",
"LINKEDIN_API_VERSION": "202504"
}
}
}
}ソースから実行する場合：
{
"mcpServers": {
"linkedin": {
"command": "node",
"args": ["/path/to/linkedin-campaign-manager-mcp/dist/index.js"],
"env": {
"LINKEDIN_CLIENT_ID": "...",
"LINKEDIN_CLIENT_SECRET": "...",
"LINKEDIN_TOKEN_PATH": "/path/to/token.json",
"LINKEDIN_DEFAULT_AD_ACCOUNT": "123456789"
}
}
}
}Claude Codeを再起動します。19個のツールが linkedin サーバーの下に表示されます。
環境変数
変数 | 必須 | デフォルト | 説明 |
| はい | — | OAuthアプリのクライアントID |
| はい | — | OAuthアプリのクライアントシークレット |
| いいえ |
| トークンファイルの読み書きパス |
| 推奨 | — | 数値のアカウントID。 |
| いいえ |
| OAuthリダイレクト用のループバックポート |
| いいえ |
| LinkedIn Rosetta APIバージョン (YYYYMM) |
URNの取り扱い
LinkedInのリソースはURNで識別されます：urn:li:sponsoredAccount:123、urn:li:sponsoredCampaign:456 など。
すべてのツール入力は、数値IDのみ、または完全なURNのいずれかを受け入れます。クライアントが数値IDを自動的にラップします。数値IDはキャンペーンマネージャーのURL（/accounts/<id>/、/campaigns/<id>/）に表示されます。
日付入力
すべての日付パラメータは以下を受け入れます：
入力 | 意味 |
| リテラルISO日付 |
| そのままの意味 |
| 今日のN日前 |
デフォルト範囲：28daysAgo → yesterday。
LinkedIn特有の注意点
APIバージョンの変更
LinkedIn Rosettaは月次バージョン（202504 = 2025年4月）を使用します。バージョンはリリースから約12ヶ月後に廃止され、その時点で 410 Gone エラーが発生します。四半期ごとに LINKEDIN_API_VERSION を更新してください。バージョニングのドキュメントを参照してください。
分析クエリの形式
/adAnalytics は、単純なISO文字列ではなく、Rest.li形式のネストされたパラメータを使用します：
dateRange=(start:(year:2024,month:10,day:1),end:(year:2024,month:10,day:31))
campaigns=List(urn:li:sponsoredCampaign:123,urn:li:sponsoredCampaign:456)これは内部的に dateRangeParam() と liGetRaw() によって処理されます。サーバーを拡張する場合は、手動で構築したURLを使用して liGetRaw() 経由で分析呼び出しをルーティングしてください。URLSearchParams がネストされた括弧を壊すため、分析エンドポイントには liGet() を使用しないでください。
分析データの遅延
LinkedInの分析データは、ほとんどの指標で2〜6時間、コンバージョンデータでは最大24時間の遅延が発生します。昨日の数値は通常完了していますが、今日の数値は部分的です。
60日間のアクセストークン、365日間のリフレッシュトークン
アクセストークンは60日で期限切れになり、リフレッシュトークンは365日で期限切れになります。クライアントは必要に応じて、リクエストごとに自動的にアクセストークンを更新します。リフレッシュトークンが期限切れになった場合は、npm run auth を再度実行してください。
リード獲得フォームの回答に含まれる個人情報（PII）
li_get_leadgen_responses は、名前、メール、企業、役職といった実際のリードの個人情報を返します。出力は機密情報として扱ってください。共有ログ、暗号化されていないストレージ、または公開チャンネルには書き込まないでください。LinkedInのデータ利用ポリシーでは、リードが積極的に同意していない限り、受信から90日以内にリードの回答を削除することが義務付けられています。このツールは、承認されたCRM照合（Marketo/SFDC）を目的としています。
レート制限
LinkedInは厳密なレート制限数を公開していません。実際には、アプリごとに1分あたり約100回の分析呼び出しでスロットリングが発生すると予想してください。429エラー時の再試行機能は組み込まれていません。制限に達した場合は、呼び出し頻度を減らすか、クライアント側で結果をキャッシュしてください。
このサーバーを使用すべきでない場合
キャンペーン、予算、クリエイティブの作成または編集 — 設計上、読み取り専用です。キャンペーン作成には自動化するには失敗モードが多すぎるため、キャンペーンマネージャーのUIを使用してください。
リアルタイムのインプレッションデータ — ほぼリアルタイムのデータには、LinkedIn Insight Tag + GA4を使用してください。
任意のターゲティング基準に対するオーディエンスサイズの推定 — アドホックなサイズ測定には、キャンペーンマネージャーのオーディエンスビルダーUIを使用してください。
li_get_audience_insightsは、保存済み/アップロード済みのセグメントのサイズのみを返します。
ライセンス
MIT © 2026 Zach Leventer
Available Tools
19 toolsli_compare_periodsA
Compare LinkedIn campaign performance across two time periods. wow (week-over-week): last 7d vs prior 7d. mom (month-over-month): last 30d vs prior 30d. yoy (year-over-year): last 30d vs same 30d last year. Returns per-entity rows (keyed by campaign/creative URN) with _current, _prior, _delta, and _pct_change columns for every requested metric. Deltas are computed server-side so you do not need to post-process. Useful for weekly/monthly performance reports and anomaly detection.
| Name | Required | Description | Default |
|---|---|---|---|
| pivot | No | CAMPAIGN | |
| fields | No | ||
| comparison | No | wow: last 7d vs prior 7d. mom: last 30d vs prior 30d. yoy: last 30d vs same 30d last year. | wow |
| campaign_ids | No | ||
| ad_account_id | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. States it returns per-entity rows with delta columns and that deltas are computed server-side. Does not mention read-only status or rate limits, but for a comparison tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise 4 sentences with no fluff. Front-loads purpose, then details modes, output, and use cases. Effectively communicates without excess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return structure. Sufficient for agent to understand tool's niche among siblings. Could mention required parameters (none required) but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (20%). Description adds meaning for 'comparison' enum and 'fields' (implicitly). Does not detail 'campaign_ids' or 'ad_account_id', but these are standard in LinkedIn tools. Some value added beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Describes a specific action: comparing campaign performance across two time periods. Clearly distinguishes from sibling tools like li_get_campaign_performance which likely returns single-period data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains when to use (weekly/monthly reports, anomaly detection) and details the three comparison modes. Does not explicitly mention when not to use, but context is clear enough for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_accountA
Get full details for a single LinkedIn ad account, including currency code, status, account type (BUSINESS/ENTERPRISE), total budget, billing info, and the associated organization URN. Useful for confirming account currency before interpreting spend data, or checking billing status before troubleshooting ad delivery issues.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | Ad account numeric ID or URN (urn:li:sponsoredAccount:123). Defaults to LINKEDIN_DEFAULT_AD_ACCOUNT. The numeric ID is visible in Campaign Manager URLs: /accounts/<id>/. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It does not mention that the operation is read-only, any authentication requirements, rate limits, or error conditions. This leaves the agent without critical safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy. Purpose is front-loaded, usage guidance follows. Every word adds value, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description adequately covers what it returns and when to use it. It could be enhanced by mentioning the output structure more explicitly, but the listed fields suffice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description does not add significant new meaning beyond what the schema provides. Baseline of 3 is appropriate given the schema already describes the parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details for a single LinkedIn ad account, listing specific fields like currency, status, account type, etc. It distinguishes from sibling tools like li_list_ad_accounts (list vs detail).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: useful for confirming account currency before interpreting spend data or checking billing status before troubleshooting. While no when-not-to or alternatives are mentioned, the usage scenarios are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_audience_insightsA
List DMP (Data Management Platform) segments attached to a LinkedIn ad account. Segments represent matched audiences (USER type: contact list uploads, website retargeting, lookalike audiences) and company lists (COMPANY type: for account-based marketing). Returns segment name, type, source, estimated size (where LinkedIn reports it), and status. Use to audit available audiences before building campaigns, or to confirm a matched audience uploaded successfully and has enough members to serve ads.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | ||
| type | No | Filter segment type: USER (contact list / matched audience), COMPANY (company list for ABM), COMBINED (combined / lookalike segment). | |
| page_size | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return fields (name, type, source, estimated size, status) and the 'where LinkedIn reports it' nuance. Without annotations, this provides necessary behavioral insight, though pagination is not mentioned (implied by page_size parameter).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return fields and usage. It lacks error handling details but covers essential aspects for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only 'type' has schema description). The description reinforces the 'type' enum values from the schema but adds no extra meaning for 'ad_account_id' or 'page_size'. It partially compensates by explaining the tool's output context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List DMP segments attached to a LinkedIn ad account' and explains segment types (USER, COMPANY). This verb-resource pair is specific and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides two use cases: auditing audiences before campaigns and confirming upload success. It gives context but does not exclude alternatives or mention when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_budget_pacingA
Calculate budget utilization for active LinkedIn campaigns. Compares spend over the specified period_days window against total or estimated period budget, and returns a utilization_pct for each campaign. Useful for mid-flight pacing checks: if utilization is below 80% near the end of a month, the campaign may be under-delivering; above 100% means it is over-pacing. Accepts optional campaign_ids to limit scope; defaults to all ACTIVE campaigns in the account.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | ||
| campaign_ids | No | Limit pacing report to these campaigns. Omit to report all active campaigns in the account. | |
| period_days | No | Number of days to look back for spend. Should match your budget period (e.g., 30 for monthly). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the core behavior: compares spend over period_days, returns utilization_pct, operates on active campaigns. It is a read-only analytic, so safety is implied. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first defines purpose, second explains logic, third provides usage examples. Every sentence is essential and front-loaded. No unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (utilization_pct per campaign) and the underlying logic. It covers inputs, behavior, and output adequately for a simple analytic tool. The complexity is low, and the description is self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 67% of parameters with descriptions; the description adds context for period_days (should match budget period) and campaign_ids (defaults to all active). For ad_account_id, which lacks schema description, the description does not cover it, but it's a standard parameter. The description adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates budget utilization for active LinkedIn campaigns, specifying it compares spend and returns utilization percentage. This distinguishes it from sibling tools like li_get_campaign_performance, which provides general performance metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: mid-flight pacing checks with thresholds (below 80% under-delivering, above 100% over-pacing). Also explains optional campaign_ids and default scope. Could be improved by mentioning alternatives like li_get_campaign_performance for other metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_campaignA
Get complete detail for a single LinkedIn campaign, including the full targetingCriteria object (all included/excluded facets), bid strategy, unit cost, daily/total budget, run schedule, objective, optimization target, format, and locale. Use this when you need to audit targeting setup, diagnose budget configuration, or confirm campaign structure before pulling performance data.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign numeric ID or URN (urn:li:sponsoredCampaign:123). Required. | |
| ad_account_id | No | Ad account numeric ID or URN. Defaults to LINKEDIN_DEFAULT_AD_ACCOUNT. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states what is returned (full detail) but does not explicitly declare that the tool is read-only or has no side effects. However, the context implies a read operation, and the description is transparent about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and details, and the second sentence provides usage context. Every word is necessary and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists many returned fields (targetingCriteria, bid strategy, budget, etc.), giving a complete picture of what the agent can expect. For a tool with moderate complexity, this is thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with descriptions. The description adds value by noting that campaign_id is required and ad_account_id defaults to LINKEDIN_DEFAULT_AD_ACCOUNT, providing operational context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool retrieves 'complete detail for a single LinkedIn campaign' and enumerates specific elements like targetingCriteria, bid strategy, etc., clearly distinguishing it from sibling tools like li_get_campaign_performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool: 'audit targeting setup, diagnose budget configuration, or confirm campaign structure before pulling performance data.' This helps an agent select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_campaign_performanceA
Fetch performance metrics for LinkedIn campaigns over a date range. Returns impressions, clicks, spend (USD and local currency), website conversions, one-click lead form submissions, landing-page clicks, video views, follows, reactions, comments, and shares. Pass campaign_ids for specific campaigns or use ad_account_id for account-level totals. Supports DAILY/MONTHLY/YEARLY/ALL time granularity and CAMPAIGN/CAMPAIGN_GROUP/CREATIVE/ACCOUNT pivots. Default range: last 28 days.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_ids | No | Campaign numeric IDs or URNs. Omit to report at account level. | |
| ad_account_id | No | Ad account ID/URN. Used when campaign_ids is omitted. Defaults to LINKEDIN_DEFAULT_AD_ACCOUNT. | |
| start_date | No | Start of date range. Accepts YYYY-MM-DD, today, yesterday, or NdaysAgo. Default: 28daysAgo. | 28daysAgo |
| end_date | No | End of date range. Default: yesterday. | yesterday |
| time_granularity | No | ALL | |
| pivot | No | CAMPAIGN | |
| fields | No | Comma-separated metrics. Default: impressions,clicks,costInUsd,costInLocalCurrency,externalWebsiteConversions,oneClickLeads,landingPageClicks,videoViews,follows,reactions,comments,shares |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses default date range (last 28 days) and list of returned metrics. Implies read-only operation. Does not mention auth requirements or rate limits, but for a read tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One paragraph of 4 sentences, each sentence packed with meaningful information. Front-loaded with purpose and key metrics, then parameter usage. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description enumerates all returned metrics. Covers all 7 parameters with usage context. Explains aggregation levels (pivots) and date ranges. Complete for a read tool with no side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%. Description adds context beyond schema: explains the role of campaign_ids, ad_account_id, default dates, and lists default fields. Helps understand parameter behavior without reading schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Fetch performance metrics' for 'LinkedIn campaigns over a date range.' Lists specific metrics and parameters, distinguishing it from siblings like li_get_campaign (which would return campaign details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use campaign_ids vs ad_account_id, and default date range. Supports various time granularities and pivots. However, does not explicitly mention when not to use or alternative sibling tools like li_get_conversion_performance for conversion-specific metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_conversion_eventsA
List LinkedIn conversion event definitions on an ad account. Returns each event's name, type (URL/FILE_DOWNLOAD/SIGN_UP/etc.), enabled status, attributionType, post-click and view-through attribution window sizes, and associated Insight Tag. These are the events tracked by the LinkedIn Insight Tag on your website. Use to audit conversion event setup, confirm event names before pulling conversion performance, or verify attribution window configuration.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | Ad account numeric ID or URN. Defaults to LINKEDIN_DEFAULT_AD_ACCOUNT. | |
| enabled_only | No | If true, only return enabled conversion events. Set false to include disabled/archived events. | |
| page_size | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose read-only nature, authentication requirements, rate limits, or pagination behavior. The description is straightforward but lacks explicit behavioral warnings or details beyond the function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is three sentences with no wasted words: first sentence states purpose, second enumerates return fields, third lists use cases. Well front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return values (name, type, enabled status, attributionType, attribution windows, Insight Tag). It covers typical use cases but could mention pagination implications (page_size parameter) and prerequisites (ad account access). Minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (ad_account_id and enabled_only have descriptions). The description does not add significant parameter-level details beyond the schema; it lists return fields rather than elaborating on parameters like page_size. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists LinkedIn conversion event definitions on an ad account, and enumerates return fields. This distinguishes it from sibling tools like li_get_conversion_performance which return performance data, not definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states use cases: audit conversion event setup, confirm event names before pulling conversion performance, verify attribution window configuration. It does not explicitly exclude other uses or mention alternatives, but provides clear context for when to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_conversion_performanceA
Fetch conversion performance broken down by conversion event (CONVERSION pivot). Returns externalWebsiteConversions, externalWebsitePostClickConversions, externalWebsitePostViewConversions, impressions, clicks, and spend per conversion event. Use to compare cost-per-conversion across event types, diagnose which Insight Tag events are driving value, or build a funnel from impression → click → conversion. Scope to specific campaigns or report at account level.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_ids | No | Campaign numeric IDs or URNs to scope the conversion report. Omit for account-level. | |
| ad_account_id | No | ||
| start_date | No | Start of date range. Accepts YYYY-MM-DD, today, yesterday, or NdaysAgo. Default: 28daysAgo. | 28daysAgo |
| end_date | No | yesterday | |
| fields | No | Comma-separated metrics. Default: externalWebsiteConversions,externalWebsitePostClickConversions,externalWebsitePostViewConversions,impressions,clicks,costInUsd,costInLocalCurrency |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full responsibility. It clearly states the operation is a read fetch and lists the returned metrics. However, it omits details like rate limits, data freshness, auth requirements, or any side effects. For a read-only tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: core action first, then return fields, then use cases, then scoping. Each sentence adds value, though it could be slightly shorter. The front-loading is effective for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fairly explains return values by listing the metrics and their meaning. It also covers the pivot dimension. It does not mention pagination, data limits, or error handling, but for a report tool with moderate complexity, the coverage is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%. The description adds only minor repetition of scoping guidance for campaign_ids ('Scope to specific campaigns or report at account level'). It offers no additional meaning for parameters like ad_account_id, end_date, or fields beyond what is in the schema, and does not compensate for the 40% of parameters lacking schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('Fetch'), resource ('conversion performance'), and unique breakdown ('by conversion event'). It lists specific metrics returned and provides concrete use cases (compare cost-per-conversion, diagnose event value, build funnel). This effectively distinguishes it from sibling campaign-performance tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states scoping options ('Scope to specific campaigns or report at account level') and describes when to use (comparing cost-per-conversion, diagnosing event value, building funnels). No explicit when-not-to-use or alternatives, but the guidance is sufficient for an agent to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_creativeA
Get full detail for a single LinkedIn ad creative, including the creative content (headline, body copy, destination URL, image/video URNs, call-to-action label), intendedStatus, associated campaign URNs, and creative type. Use when auditing ad copy and creative assets, debugging a rejected creative, or pulling the landing page URL to cross-reference with GA4 UTM data.
| Name | Required | Description | Default |
|---|---|---|---|
| creative_id | Yes | Creative numeric ID or URN (urn:li:sponsoredCreative:123). Required. | |
| ad_account_id | No | Ad account numeric ID or URN. Defaults to LINKEDIN_DEFAULT_AD_ACCOUNT. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully discloses returned fields (content, status, campaign URNs, type). No mention of rate limits or auth, but sufficient for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, no redundant words. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description enumerates key return fields. Lacks error handling details, but covers primary use case comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds value by specifying 'numeric ID or URN' for creative_id and default value for ad_account_id, beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a specific verb+resource ('Get full detail for a single LinkedIn ad creative') and lists included fields, clearly differentiating from sibling listing tools like li_list_creatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use cases: auditing ad copy, debugging rejected creatives, cross-referencing URLs. Does not mention when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_demographics_reportA
Break down LinkedIn campaign performance by a demographic dimension of the people who saw or clicked your ads. Pivot options: MEMBER_JOB_TITLE (which titles engage most), MEMBER_JOB_FUNCTION, MEMBER_SENIORITY (director vs. manager vs. C-suite), MEMBER_COMPANY (which accounts clicked), MEMBER_COMPANY_SIZE, MEMBER_INDUSTRY, MEMBER_COUNTRY_V2, MEMBER_REGION_V2. Returns impressions, clicks, spend, leads, and conversions per dimension value. Useful for buyer-persona fit analysis and ABM account-list validation.
| Name | Required | Description | Default |
|---|---|---|---|
| pivot | Yes | Demographic dimension to break down by. MEMBER_JOB_TITLE / MEMBER_JOB_FUNCTION / MEMBER_SENIORITY are useful for persona fit; MEMBER_COMPANY / MEMBER_COMPANY_SIZE for ABM audience analysis; MEMBER_INDUSTRY for vertical benchmarking; MEMBER_COUNTRY_V2 / MEMBER_REGION_V2 for geo reporting. | |
| campaign_ids | No | ||
| ad_account_id | No | ||
| start_date | No | 28daysAgo | |
| end_date | No | yesterday | |
| fields | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It explains that the tool returns impressions, clicks, spend, leads, and conversions per dimension value, but does not disclose behavioral traits like required permissions, data freshness, pagination, or handling of multiple campaigns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (6 sentences) and well-structured, front-loading the purpose, listing options with context, stating return metrics, and ending with use cases. No superfluous sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (5 undocumented in both schema and description), no output schema, and moderate complexity, the description omits critical context for filtering (campaign_ids, ad_account_id, date range) and does not explain the response structure beyond listing metrics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value for the pivot parameter by explaining each enum value and grouping them by use case, supplementing the schema's 17% coverage. However, it provides no semantics for other parameters like campaign_ids, ad_account_id, start_date, end_date, and fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: breaking down LinkedIn campaign performance by a demographic dimension. It lists all pivot options and distinguishes itself from siblings like li_get_campaign_performance by focusing on demographic breakdowns and specific use cases (buyer-persona fit, ABM).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage contexts for each pivot option (e.g., persona fit, ABM analysis, geo reporting) and implies when to use the tool but does not explicitly state when not to use it or mention alternatives like li_get_campaign_performance for overall metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_leadgen_form_performanceA
Fetch LinkedIn Lead Gen Form performance analytics broken down by creative. Returns impressions, clicks, Lead Gen Form opens (oneClickLeadFormOpens), lead submissions (oneClickLeads), spend, and computed metrics: formOpenRate (opens / clicks), leadSubmitRate (submissions / opens), costPerLead (spend / submissions), and CTR. Use to identify high-performing LGF creatives, diagnose drop-off between form open and submission, or compare cost-per-lead across campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | No | yesterday | |
| start_date | No | Start of date range. Default: 28daysAgo. | 28daysAgo |
| campaign_ids | No | Scope to specific campaigns (pass campaign IDs or URNs). Omit to report across all campaigns in the account. | |
| ad_account_id | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the breakdown by creative and computed metrics, which aids transparency. However, it does not mention non-obvious behaviors like pagination, rate limits, authorization needs, or data freshness, which would be helpful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the action and metrics, followed by use cases. No redundant or unnecessary information. Every sentence is purposeful and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description is fairly complete: it explains what metrics are returned and provides use cases. However, it leaves ambiguity about how the breakdown by creative is structured and does not explain the role of ad_account_id or the default behavior of date parameters. Still, it covers the core purpose well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (2 of 4 parameters have descriptions). The description does not add information for the undocumented parameters (end_date, ad_account_id), nor does it clarify parameter usage beyond what the schema provides. It does not compensate for the missing schema descriptions, leaving the agent unclear about these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches LinkedIn Lead Gen Form performance analytics broken down by creative, listing specific metrics (impressions, clicks, opens, submissions, spend, and computed metrics like formOpenRate). It also differentiates from siblings like li_get_leadgen_forms (which lists forms) and li_get_leadgen_responses (which gets individual responses) by focusing on performance analytics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: 'identify high-performing LGF creatives, diagnose drop-off between form open and submission, or compare cost-per-lead across campaigns.' It implies when to use the tool but does not specify when not to use or directly compare with alternatives. However, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_leadgen_formsA
List LinkedIn Lead Gen Forms on an ad account. Returns form name, state (ACTIVE/DRAFT/ARCHIVED), the list of questions asked (field type, label, pre-fill source), the thank-you page URL and message, and the associated landing page (if any). Use to audit form question setup, confirm form state before troubleshooting lead delivery, or verify which forms are attached to active campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | ||
| state | No | Filter by form state. ACTIVE forms are live on ads. DRAFT forms are not yet submitted for review. | |
| page_size | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly implies read-only behavior by stating it 'lists' and 'returns' data. It does not disclose potential pagination or rate-limiting behavior. The description is adequate but not exhaustive for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: first states purpose, second lists returns, third gives use cases. No redundant information, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the main return values (name, state, questions, thank-you page, landing page). It lacks details on pagination metadata or any potential empty results. Overall, it is mostly complete for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 33% description coverage (only state has a description). The description adds context for the state parameter (e.g., 'ACTIVE forms are live on ads'), but does not elaborate on ad_account_id or page_size. Coverage is low, but the description partially compensates for state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with the specific verb 'List' and resource 'LinkedIn Lead Gen Forms on an ad account'. It enumerates returned fields (name, state, questions, thank-you page, landing page) and provides distinct use cases (audit form setup, confirm state, etc.). This clearly distinguishes it from sibling tools like li_get_campaign or li_get_leadgen_responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists three concrete scenarios (audit form setup, confirm state before troubleshooting, verify attached forms) that indicate when to use the tool. However, it does not explicitly state when not to use it or provide alternatives, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_leadgen_responsesA
Retrieve actual Lead Gen Form submission data from LinkedIn. Each response includes questionResponses with field-by-field values (first name, last name, email, company, job title, phone, etc.) and submission timestamp. Filter by lead_form_id and/or submitted_after/before date range. Use for lead-to-CRM reconciliation against SFDC or Marketo, for auditing lead quality, or for confirming that a form integration is capturing the right fields. NOTE: This endpoint returns PII — handle output as sensitive data.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | ||
| lead_form_id | No | Filter to a specific Lead Gen Form (numeric ID or URN). | |
| submitted_after | No | ISO date (YYYY-MM-DD). Only include responses submitted on or after this date. | |
| submitted_before | No | ISO date (YYYY-MM-DD). Upper bound for submission date. | |
| page_size | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It warns about PII and sensitive data handling, and describes the response structure. However, it lacks details on rate limits, authentication requirements, or pagination behavior for a tool with 5 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core action. Every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return values (questionResponses with fields and timestamp) and data sensitivity, which is crucial with no output schema. It lacks pagination details but is otherwise complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions filtering by lead_form_id and date range, adding meaning to those parameters. However, it does not mention ad_account_id or page_size. Schema coverage is 60%, so description compensates partially but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves Lead Gen Form submission data from LinkedIn, specifying the resource and the verb ('Retrieve'). It distinguishes itself from sibling tools like li_get_leadgen_forms (which lists forms) by focusing on responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: lead-to-CRM reconciliation, auditing lead quality, and confirming form integration. It does not mention when not to use or compare to siblings, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_get_video_analyticsA
Fetch video-specific performance metrics for LinkedIn campaigns, broken down by creative. Returns videoStarts, videoViews, videoFirstQuartileCompletions, videoMidpointCompletions, videoThirdQuartileCompletions, videoCompletions, plus a computed videoCompletionRate (completions / starts × 100). Use to evaluate video ad quality — high completion rates indicate compelling content; low rates signal drop-off. Scope to specific campaigns via campaign_ids or report at account level.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_ids | No | Campaign numeric IDs or URNs to scope the report. Omit to report at account level. | |
| ad_account_id | No | ||
| start_date | No | 28daysAgo | |
| end_date | No | yesterday | |
| time_granularity | No | ALL |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what data is returned but does not mention side effects, rate limits, auth requirements, or whether it is read-only (though implied). Basic transparency is present but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. The first sentence front-loads purpose and return fields, the second gives usage guidance, and the third explains scoping. Every sentence is essential and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description covers return metrics, interpretation, and scoping. Missing details like response format, pagination, or time zone handling. Still fairly complete for a read-only analytics tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (one parameter described). The description adds value by explaining campaign_ids: 'Scope to specific campaigns via campaign_ids or report at account level.' However, other parameters (ad_account_id, dates, time_granularity) receive no explanation. The description partially compensates for low schema coverage but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches video-specific performance metrics for LinkedIn campaigns, broken down by creative. It lists specific metrics and distinguishes from sibling tools like li_get_campaign_performance by specifying 'video-specific' and 'broken down by creative'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'Use to evaluate video ad quality — high completion rates indicate compelling content; low rates signal drop-off.' It also explains scoping options via campaign_ids or account level. However, it does not mention when not to use this tool or compare directly with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_list_ad_accountsA
List all LinkedIn ad accounts the authenticated user has access to. Returns account ID, name, status, currency, type (BUSINESS/ENTERPRISE), and reference organization URN. Use this first to discover the ad_account_id needed by other tools. Filter by status (ACTIVE/CANCELED/DRAFT/PENDING_DELETION/REMOVED) or omit to see all accounts.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by ad account status. Omit to return accounts in all statuses. | |
| page_size | No | Number of results per page (max 100). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adequately describes the tool as a read-only list operation, details the returned data, and mentions filtering. However, it does not disclose pagination behavior beyond the page_size parameter, rate limits, or authentication specifics beyond 'authenticated user.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences plus a filter note), front-loaded with the core purpose, and every sentence adds value. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers the tool's purpose, return fields, usage context, and parameter options. It lacks details on cursor-based pagination or error handling, but for a simple list tool with two optional params, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description reiterates the status filter and its options (including the default of showing all statuses when omitted), which adds marginal context but doesn't significantly supplement the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all LinkedIn ad accounts accessible to the user, specifies returned fields (ID, name, status, currency, type, reference organization URN), and distinguishes itself from siblings like li_get_account by focusing on listing multiple accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Use this first to discover the ad_account_id needed by other tools,' providing clear guidance on when to use this tool. It also explains the optional status filter and its effect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_list_campaign_groupsA
List campaign groups in a LinkedIn ad account. Campaign groups are containers that group related campaigns under a shared name and optional total budget cap. Returns group name, status, total budget, run schedule, and the campaigns count. Use to understand account structure before pulling campaign-level data.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | ||
| status | No | ||
| page_size | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the returned fields but omits details like pagination behavior, error handling, authentication requirements, or rate limits. The description is adequate for a simple list operation but lacks comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with purpose and output, then usage guidance. No redundant or extra words. Every sentence adds value and is easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity (3 params), the description lacks parameter details and pagination behavior. It covers purpose and output fields partially but not fully. It is usable but leaves the agent with unanswered questions for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It does not mention ad_account_id, status, or page_size at all. The only hint is 'in a LinkedIn ad account' implying ad_account_id, but no details on usage, default, or enum meanings. This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists campaign groups in a LinkedIn ad account, defines what campaign groups are, and specifies the returned fields (name, status, total budget, run schedule, campaigns count). It distinguishes from siblings by advising use before pulling campaign-level data, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use to understand account structure before pulling campaign-level data,' providing a clear context. It lacks explicit alternatives or when-not-to-use guidance, but the context is strong enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_list_campaignsA
List campaigns in a LinkedIn ad account. Returns campaign name, status, objectiveType (WEBSITE_VISITS/LEAD_GENERATION/BRAND_AWARENESS/etc.), optimizationTargetType, bid amount, daily/total budget, run schedule, and targeting criteria summary. Filter by status or campaign_group_id. Use li_get_campaign for full targeting detail on a specific campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | Ad account numeric ID or URN. Defaults to LINKEDIN_DEFAULT_AD_ACCOUNT. | |
| status | No | Filter by campaign status. Omit to return campaigns in all statuses. | |
| campaign_group_id | No | Filter to campaigns belonging to a specific campaign group (numeric ID or URN). | |
| page_size | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read operation by listing campaigns, but does not explicitly state read-only behavior, rate limits, or pagination details. It returns specific fields but not the output format (e.g., array).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, followed by returned data and filtering/alternative. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, inputs, and outputs sufficiently for a listing tool. However, it does not explicitly state the output is an array or mention pagination or sorting behavior. The return fields are listed but not structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 parameters described). The description mentions filtering by status and campaign_group_id, adding context to those parameters. However, it does not describe page_size or ad_account_id further, and the schema already covers parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with the resource 'campaigns in a LinkedIn ad account', making the action and scope clear. It also distinguishes itself from sibling li_get_campaign by noting that the latter provides full targeting detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states filtering options (status, campaign_group_id) and explicitly recommends li_get_campaign for full targeting detail. It lacks an explicit 'when not to use' statement, but the alternative is clearly given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_list_creativesA
List ad creatives in a LinkedIn ad account. Returns creative content type (SPONSORED_STATUS_UPDATE/MESSAGE/etc.), intendedStatus, associated campaigns, and content URNs. Filter by campaign_id to see all creatives on a specific campaign, or by status to find paused/archived ads. Use li_get_creative for full content detail on a specific creative.
| Name | Required | Description | Default |
|---|---|---|---|
| ad_account_id | No | ||
| campaign_id | No | Filter to creatives in a specific campaign (numeric ID or URN). | |
| status | No | Filter by intendedStatus. | |
| page_size | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes returned fields and filtering behavior. Lacks mention of pagination beyond page_size parameter, rate limits, or error handling, but overall is transparent about the tool's read-only nature and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and return fields adequately for a list tool with no output schema. Provides sibling guidance. Missing default ordering or pagination details (though page_size parameter exists), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes campaign_id and status well. Description adds practical usage context ('see all creatives on a specific campaign', 'find paused/archived ads'), enhancing parameter meaning beyond schema. However, does not elaborate on ad_account_id or page_size beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'List' and resource 'ad creatives in a LinkedIn ad account'. Explicitly lists return fields (creative content type, intendedStatus, campaigns, content URNs) and distinguishes from sibling li_get_creative, which provides full detail on a single creative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: filter by campaign_id or status. Directs to li_get_creative for detailed content, which prevents misuse and clarifies alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
li_search_targeting_facetsA
Search LinkedIn targeting facet values to find the correct URNs for audience targeting. Facets include: jobTitles (e.g., 'Supply Chain Director'), skills (e.g., 'S&OP'), companies, industries, seniorities, locations, and more. Returns matching facet values with their LinkedIn URNs, which can then be used to configure campaign targeting via the Campaign Manager UI. Useful for researching targeting options, confirming exact category names, or building audience documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| facet | Yes | Targeting facet to search. Use jobTitles for job title targeting, skills for skill-based targeting, companies to find specific company targets, industries for vertical targeting, seniorities for seniority-level targeting, locations for geo targeting. | |
| query | Yes | Search string to filter facet values. Example: 'supply chain' for jobTitles. | |
| locale | No | Locale for facet label localization. Default: en_US. | en_US |
| count | No | Maximum number of matching facet values to return (max 50). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool returns matching facet values with URNs, implying a read-only operation, but does not explicitly confirm idempotence or mention rate limits or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and structured with bullet-like examples. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for a search tool, but lacks details on the return format (e.g., object structure) and pagination. Given no output schema, a bit more on return values would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters, but the description adds value by listing example facets and explaining how results are used for campaign targeting, enhancing understanding beyond the schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches LinkedIn targeting facet values to find URNs for audience targeting. It lists specific facets and use cases, distinguishing it from sibling get/list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is useful for researching targeting options and building audience documentation, providing clear context. It does not explicitly state when not to use it or list alternatives, but the sibling set lacks other search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
19 tool updates
v1.0.0- First observed
li_compare_periods - First observed
li_get_account - First observed
li_get_audience_insights - First observed
li_get_budget_pacing - First observed
li_get_campaign - First observed
li_get_campaign_performance - First observed
li_get_conversion_events - First observed
li_get_conversion_performance - First observed
li_get_creative - First observed
li_get_demographics_report - First observed
li_get_leadgen_form_performance - First observed
li_get_leadgen_forms - First observed
li_get_leadgen_responses - First observed
li_get_video_analytics - First observed
li_list_ad_accounts - First observed
li_list_campaign_groups - First observed
li_list_campaigns - First observed
li_list_creatives - First observed
li_search_targeting_facets
TDQS
Scored across 19 tools
Each tool has a clearly distinct purpose: listing vs. getting details vs. performance reports vs. conversion/leadgen analytics vs. targeting research. Even similar-looking tools like li_get_campaign_performance, li_get_leadgen_form_performance, and li_get_conversion_performance target different metric types and dimensions, so an agent can reliably pick the right one.
All tools follow a consistent snake_case pattern with the li_ prefix and verb-noun structure (list_, get_, search_, compare_). The naming is highly predictable: li_list_* for enumeration, li_get_* for details or reports, and specific modifiers like _performance, _analytics, _insights. No mixed conventions or irregular verbs.
At 19 tools, this is slightly above the typical 3-15 range but still well-justified for the complexity of LinkedIn advertising. Each tool covers a distinct aspect (accounts, campaigns, creatives, performance, demographics, video, conversions, audiences, leadgen, targeting, pacing, comparison) without redundancy. The count feels reasonable for the domain's depth.
The toolset is heavily read/analytics-focused: it covers listing, getting details, and detailed performance/reporting for all major entities, but lacks any create, update, or delete operations for campaigns, creatives, or account settings. For a 'campaign manager' one might expect lifecycle management, but as a monitoring/analytics surface it is fairly complete. The gaps are significant if the intended scope includes editing, but for reporting and optimization analysis it works well.
Maintenance
Related MCP Connectors
Hosted LinkedIn MCP server that connects your own LinkedIn account to Claude, ChatGPT, Cursor, n8n and any MCP client. 33 tools: people and Sales Navigator search, profiles, companies, jobs, inbox, posts, invites, email and phone finding. Free 7-day trial, no card (connecting your own LinkedIn account needs a paid plan). Starter $19/month, Pro $49/month, Max $199/month. $10 top-ups.
Managed LinkedIn MCP server for AI agents: search, connect, message and enrich on accounts you own.
LinkedIn outreach MCP server — 19 tools for AI agents to prospect, sequence, and manage contacts.
LinkedIn Ads MCP server: 10 tools for campaigns, creatives, audiences, lead forms. Writes preview.
