paid-ads

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate a non-read-only, non-destructive mutation. The description adds that it requires client confirmation and optionally resolves setup questions, but doesn't detail side effects like overwriting behavior or limits. This adds some value but leaves gaps.

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 a single, well-structured sentence that conveys core purpose, prerequisites, and optional functionality without unnecessary words.

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 complexity (12 parameters, output schema exists), the description covers the main action, optional features, and prerequisite. It is sufficient for an agent to understand when and how to use the 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 92%, so most parameters are described in the schema. The description ties parameters together (e.g., effective dates, setup question), adding workflow meaning beyond individual 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 uses specific verbs ('assigns') and resources ('synced campaign', 'reporting group'), clearly indicating the tool's action. It also mentions optional recording of effective dates and resolving setup questions, distinguishing it from siblings like 'resolve_context_follow_up' and 'save_reporting_groups'.

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 'after client confirmation', indicating a prerequisite for use. While it doesn't explicitly list when not to use or provide alternatives, the context of sibling tools implies this is for a specific workflow step, offering clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no new behavioral context. It does not contradict annotations, but no additional disclosure is provided beyond stating the output includes setup URLs.

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 concise sentences: first states what the tool returns, second gives usage guidance. No unnecessary words, and the key information 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 zero parameters, an existing output schema (hidden), and no complex behavior, the description provides all necessary context: it returns status and URLs, and directs UI needs elsewhere. Fully adequate for the tool's simplicity.

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 zero parameters, and schema coverage is 100%, so the description does not need to add parameter information. Baseline score of 4 is appropriate as no parameters exist to document.

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 returns connection status and setup URLs for the current user's MCP/Auth0, LinkedIn Ads, and Google Ads. It explicitly distinguishes from sibling tool 'render_auth_setup_status' by directing the agent to prefer that for UI, ensuring unambiguous purpose.

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 guidance: 'For the user-facing setup UI, prefer render_auth_setup_status.' This tells the agent when to use this data tool versus the UI-oriented sibling, avoiding misselection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true. The description adds value by enumerating the data fields returned, reinforcing that it is a safe read operation without 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?

Two sentences with no wasted words. First sentence describes purpose, second provides usage guidance. Very 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 zero parameters and an output schema, the description covers all necessary context: it specifies the data scope (current user's saved client context) and directs to the UI tool when appropriate.

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 zero parameters and 100% schema coverage, baseline is 4. The description does not need to add parameter info; it appropriately lists the data returned.

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 identifies it as a data tool for the user's saved client context, listing specific data elements. It distinguishes itself from render_context_onboarding by explicitly stating when to use the sibling for UI.

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 tells the agent to prefer render_context_onboarding for the user-facing setup UI, providing clear guidance on when to use this tool versus the sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true, so the tool is safe to use. The description adds context about the scope of help provided (auth, workflows, etc.), which goes beyond annotations without contradicting them.

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 one sentence covering the key points. It is adequately concise and front-loaded with the core purpose.

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's simplicity, one optional parameter, and existence of an output schema, the description provides sufficient context for an agent to understand when and how to use it.

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 100% of the single optional parameter with an enum. The description adds meaning by listing the topics (auth, LinkedIn, Google Ads, etc.) which correspond to enum values, helping the agent understand what each topic covers.

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 that the tool explains how to use the Paid Ads MCP Server, covering specific areas like auth, LinkedIn, Google Ads, UI, and starting tools. This distinguishes it from sibling tools which are action-oriented.

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 implies usage for getting help or guidance, but does not explicitly state when to use this tool versus alternatives like using specific tools directly. No when-not or exclusion criteria are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool lists specific campaigns (unmapped) and suggests its purpose, which aligns with annotations and provides useful context beyond them.

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 with no fluff. The first sentence states the purpose, the second provides usage guidance. Every word earns its place.

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 is read-only with annotations covering safety, an output schema (not shown but present), and the description clarifies when to use it, the description is complete for an agent to understand the tool's role.

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 the input schema already describes all parameters. The description does not add any additional meaning about parameters, meeting the baseline of 3 for high schema coverage.

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 synced campaigns without an active reporting-group assignment, using specific verbs and a defined resource. It distinguishes from siblings like classify_campaign_reporting_group.

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?

It explicitly says 'Use this after syncs to find campaigns that need client confirmation,' providing clear when-to-use context. It does not explicitly mention alternatives, but the sibling names imply them.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and destructiveHint. Description adds context that it's an 'app-only data workflow' for 'follow-up analysis', but does not elaborate on other behavioral aspects like auth requirements or data scope beyond what annotations provide.

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 purpose, then usage guidelines. Every sentence adds value with no redundancy or wasted words.

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 7 parameters (all well-documented in schema) and existence of output schema, the description provides enough context about the tool's workflow and output. It also covers when not to use it, making it self-contained for the agent.

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 the schema already documents all parameters. The description does not add new meaning beyond the schema; it mentions the output (metrics and leaderboard) but not parameter-specific 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?

Description clearly states the tool performs account analysis and builds compact metrics and a top-campaign leaderboard. It distinguishes from siblings by specifying 'app-only' and 'for follow-up analysis inside MCP Apps', and further clarifies by listing what not to use it for.

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 advises against using for broad visual reports and directs to alternative tools (google_ads_render_weekly_group_report and paid_ads_render_weekly_dashboard), providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the tool resolves a campaign by name, compares performance across trailing windows, and returns a compact analysis artifact with top rows. This provides useful behavioral context beyond the annotations.

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 consists of two concise sentences. The first sentence explains core functionality, and the second provides an important usage alternative. No fluff or redundancy; every sentence is essential.

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 9 parameters, schema coverage 100%, annotations, and an output schema, the description is mostly complete. It covers the workflow and return artifact. It does not mention prerequisites like needing to locate the campaign first, which is a minor gap.

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 100%, so the baseline is 3. The description summarizes parameters (resolves by name, compares across windows, includes ad/keyword/search-term rows) but does not add detailed semantics beyond what the schema already provides for each parameter.

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 is a data workflow for Google Ads campaign analysis, resolving a campaign by name and comparing performance across trailing windows. It distinguishes itself from the sibling tool google_ads_render_campaign_analysis by saying to prefer that for user-facing dashboards, providing a specific verb and resource.

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 to use google_ads_render_campaign_analysis for user-facing visual dashboards, indicating when not to use this tool. It also explains it returns a compact analysis artifact, implying programmatic use. However, it does not list other alternatives from the large sibling set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint: true, destructiveHint: false, indicating safe read behavior. The description adds that it resolves by name and returns an artifact, but does not elaborate on error handling or output specifics. With annotations covering the safety profile, the description is adequate but not rich.

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 front-loaded sentences: first defines the tool's action, second provides usage guidance with an explicit alternative. No extraneous words—every sentence earns its place.

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 and an output schema, the description sets proper expectations (data workflow, compact analysis, trailing windows). It does not detail return values, but the output schema covers that. A minor gap is not mentioning the window parameter explicitly, but it's referenced indirectly.

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% with clear descriptions for all 6 parameters. The description adds no new meaning beyond stating it resolves a campaign by name and uses trailing windows, which is already implied by the windows parameter. Baseline 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?

The description clearly states this is a data workflow for judging search-term quality, resolves a campaign by name, and returns a compact analysis artifact. It explicitly distinguishes from the user-facing visual dashboard sibling tool google_ads_render_search_terms_analysis, making its purpose unambiguous.

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 'For the user-facing visual dashboard, prefer google_ads_render_search_terms_analysis', providing a clear when-not-to-use and an alternative. This directly guides the agent on appropriate usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false, so description doesn't need to repeat safety. It adds context about trailing windows and compact result. 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?

The description is a single, efficient sentence with no redundant words. It is front-loaded and every part is 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?

Given the tool's complexity (5 params, output schema exists) and annotations, the description provides sufficient context for correct use. However, it does not elaborate on return structure or error cases, though output schema likely covers that.

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% with clear parameter descriptions. The tool description adds no additional parameter meaning beyond what's already in 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 compares a Google Ads campaign across trailing windows ending on a specific date, returning a compact campaign-level result. This distinguishes it from siblings that compare ads, keywords, or search terms.

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 implies usage for campaign-level comparison but does not explicitly state when to use this tool versus other compare tools. No alternatives or when-not-to-use guidance is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds that results are paginated with a stable entityType field and type-specific details, providing useful output behavior beyond annotations.

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 with front-loaded purpose, no redundant words. Each sentence conveys essential information efficiently.

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 9 parameters, 100% schema coverage, and an output schema, the description covers the core purpose and key behavioral traits. It omits session memory defaults but schema fills this gap.

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. Description only repeats the entityType enum values and implies endDate and windows usage, but adds no new semantic meaning 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 precisely states the tool compares Google Ads ads, keywords, or search terms inside one campaign, using trailing windows. It clearly distinguishes from sibling tool google_ads_compare_campaign_performance which compares campaigns.

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 specifies the scope (inside one campaign) and required entityType, providing clear context. However, it does not explicitly state when not to use or name alternatives, though the sibling tools imply the distinction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral context: searches across directly accessible customers and returns ranked matches for disambiguation. Adds value but does not detail pagination or ranking criteria.

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 covering purpose, usage guidance, and a chaining note. No redundancy, front-loaded with main function.

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?

Accounts for output schema, so return values not needed. Describes scope (directly accessible customers) and ranking. Lacks mention of what happens with no matches or how to handle multiple matches, but overall sufficient given sibling context and annotations.

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 schema fully describes parameters. Description reaffirms query parameter purpose ('by name or ID') but adds no new semantic detail 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?

Clear verb 'Finds' with specific resource 'Google Ads customer accounts' and method 'by name or ID across directly accessible customers returning ranked matches'. Distinguishes from sibling 'google_ads_list_accessible_customers' which lists all accounts without query.

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 when to prefer: 'when the user names an account but does not know the customer ID'. Also suggests chaining with 'render_shared_picker' for UI. Does not name alternatives but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds behavioral details: ranks matches, returns customer context, and references MCP pagination via pageSize and pageToken parameters. No contradiction; description enriches understanding beyond annotations.

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 with the core purpose, followed by usage guidance and a specific action. Every sentence earns its place with no wasted words.

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 7 parameters with 100% schema coverage and an output schema, the description covers the tool's function, mentions ranking and picker integration, and hints at pagination. Could briefly note what each match includes (e.g., campaign metadata), 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 description coverage is 100%, so the schema already documents all parameters. The description does not add per-parameter details beyond the schema. Baseline score of 3 is appropriate as the description provides overall context but not incremental parameter semantics.

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?

Clear verb+resource: 'Finds Google Ads campaigns by name', and distinguishes from siblings by mentioning 'prefer this or google_ads_analyze_campaign when the user gives only a campaign name'. The description also specifies the action of ranking matches and returning customer context, which differentiates it from other 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?

Provides explicit guidance: 'Prefer this or google_ads_analyze_campaign when the user gives only a campaign name.' Also instructs to call render_shared_picker for UI picker. Lacks explicit when-not-to-use or alternatives for other scenarios, but the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and destructiveHint=false. The description adds context: 'bounded', 'constrained manual-CPC forecast campaign', and notes the session memory fallback for customerId. This enriches behavioral understanding beyond annotations.

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 wasted words. The core purpose is stated first, followed by a note on customerId behavior. Efficient and 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?

Covers the tool's purpose, key behavioral aspects (customerId fallback, constrained campaign), and uses annotations effectively. Could mention return metrics or error conditions, but output schema exists and annotations cover safety.

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 100%, so baseline is 3. The description adds only the customerId fallback note beyond schema descriptions. No additional parameter semantics provided.

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 generates bounded Google Ads forecast metrics for a keyword set over a future date range using a constrained manual-CPC forecast campaign. This distinguishes it from sibling tools like google_ads_generate_keyword_ideas (generates ideas) and performance report 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 provides minimal usage guidance. It mentions the customerId fallback but lacks explicit when-to-use or when-not-to-use information compared to alternatives. No clear exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it as readOnlyHint=true and destructiveHint=false. The description adds value by stating it returns keyword ideas plus historical planning metrics, supports Google-native paging, and the customerId fallback. 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?

Two sentences, front-loaded with core functionality. Every sentence adds value without redundancy or unnecessary fluff.

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 tool with 10 parameters, nested objects, and an output schema, the description covers essential usage constraints, output type, paging, and customerId fallback. The remaining details are in the schema and output schema, so the description is complete enough for an AI agent.

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 adds minimal meaning beyond the schema, only emphasizing the 'exactly one seed mode' constraint. The schema itself describes parameters adequately.

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 a specific verb ('Generates bounded Google Ads keyword ideas') and explicitly names the three seed modes. It distinguishes this tool from siblings like google_ads_generate_keyword_forecast by focusing on ideas vs. forecasts.

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 clearly states the constraint of exactly one seed mode and explains customerId fallback behavior. However, it does not compare to alternative tools or give explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds the bounded traversal method and session memory fallback, but does not disclose other behaviors like depth limits or error cases. This is acceptable but not exceptional.

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, immediately stating the core action and then a conditional fallback. No redundant phrases, well-structured for quick 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 the presence of an output schema and the annotations, the description adequately covers key behavioral aspects like traversal and fallback. Absence of mention of depth limits or pagination is minor; overall sufficient for an agent to invoke correctly.

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 100%, so the schema already documents each parameter. The description adds minimal extra meaning, such as the session memory fallback for customerId and the default for maxDepth. This meets the baseline for a fully documented 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 retrieves the Google Ads customer hierarchy using bounded customer_client traversal, and distinguishes itself by specifying the visibility from a specific customer account. Among sibling tools, none duplicate this purpose.

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 does not provide explicit guidance on when to use this tool versus alternatives like google_ads_find_accounts or google_ads_list_accessible_customers. It only implies usage for hierarchy retrieval without contextual comparisons.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and destructiveHint=false. Description adds that it's a 'raw data tool' and 'bounded', implying data scope but no pagination details. Contradicts no annotations.

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 concise sentences. First sets purpose, second provides usage alternative. No wasted words, front-loaded with key verb and resource.

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 output schema exists and annotations are rich, description covers purpose and usage adequately. Misses behavioral details like default limit or pagination, but these are secondary given schema and annotations.

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 100%, so description doesn't need to add much. It mentions 'bounded' and 'date range' but does not elaborate on parameters beyond schema. Baseline 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?

The description clearly states it's a 'raw data tool for bounded Google Ads reporting rows over a date range' and specifies use cases: structured report data for chaining or custom analysis. It distinguishes from the sibling tool google_ads_render_weekly_group_report.

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 guides when to use this tool (for chaining/custom analysis) and when to use an alternative (for visual reports, prefer google_ads_render_weekly_group_report). Provides clear context and exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is clearly a safe read operation. The description adds that it returns 'compact recommendation-specific details,' but does not reveal further behavioral traits (e.g., pagination, rate limits) beyond what annotations provide.

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 concise sentences: the first states the tool's purpose and output content, the second advises on when to use a sibling tool. No wasted words, information is 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 the output schema exists, the description does not need to explain return values. It sufficiently describes the tool's role as a data retrieval tool for recommendations, covering the key fields users need to understand its output.

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 100% description coverage with clear explanations for all four parameters (limit, types, customerId, loginCustomerId). The description adds no additional meaning beyond what the schema already provides, so a 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?

The description clearly states the tool retrieves bounded Google Ads recommendations for a customer account, listing specific content (type, entities, impact metrics, details). It also distinguishes from a sibling tool (google_ads_render_recommendations) used for the UI, making its purpose unambiguous.

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 to prefer google_ads_render_recommendations for user-facing UI, implying this tool is for programmatic or data-focused use. While it gives clear context, it does not explicitly state when not to use this tool or list all alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false. Description adds that output includes deltas and metadata, but does not disclose pagination behavior, error handling, or authorization needs beyond what annotations imply.

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?

Single sentence, front-loaded with verb and resource, no redundant phrasing. While concise, it could optionally list key output elements more prominently for quicker scanning.

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 having an output schema, the description fails to explain the purpose of comparison dates (prior-window deltas) and pagination (pageSize, pageToken). With 6 required parameters and complexity, the description is too shallow for an agent to confidently invoke the tool without schema inspection.

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% with all 9 parameters well-described in the schema itself. The description adds no extra semantic context beyond what the schema provides (e.g., explaining the concept of current vs comparison windows).

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 returns weekly ad-level drilldown rows for one campaign, with specific data types (channel-aware metrics, prior-window deltas, ad metadata). This distinguishes it from sibling tools like google_ads_get_weekly_group_report (aggregated) and google_ads_compare_ad_performance (comparison).

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 implies usage for ad-level drilldown within a campaign for weekly reporting but does not explicitly state when to use or not use this tool over alternatives. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral detail about including descriptive names when Google returns them, and implies authentication context ('for the configured Google Ads credentials'). 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?

Two efficient sentences. First sentence defines the action and outcome; second provides usage guidance. No filler, all sentences add 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?

For a zero-parameter list tool with an output schema, the description covers the essential purpose, usage context, and a behavioral detail. It is complete and well-aligned with the tool's simplicity.

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?

There are no parameters, so baseline 4 applies. The description does not need to add parameter information, and it correctly focuses on the tool's purpose.

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 verb 'Lists' and the resource 'directly accessible Google Ads customers', and distinguishes it from sibling tools by specifying its use for discovering customer IDs before hierarchy or reporting 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 instructs when to use the tool: 'Use this to discover customer IDs before running Google Ads hierarchy or reporting tools.' This provides clear guidance on prerequisite context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is clear. The description adds information about rendering and dual-mode operation but no additional behavioral details.

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 well-structured sentences that front-load the key purpose and modes, with no extraneous 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?

Given the complexity (10 parameters, output schema, annotations), the description adequately explains the two modes and primary use. However, it does not mention prerequisites or expected return format (though output schema covers that), so slightly incomplete.

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 100%, so the input schema already documents all parameters. The description does not add extra meaning beyond the schema, so 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?

The description clearly identifies the tool as the 'preferred user-facing Google Ads campaign analysis tool' that 'renders the campaign analysis dashboard', using a specific verb and resource, and it distinguishes itself from sibling tools like google_ads_analyze_campaign and other render 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 two usage modes (with or without analysisPayload) and implies it is the primary tool for this task, but it lacks explicit guidance on when not to use it or comparison with alternatives like linkedin_render_campaign_analysis.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds limited behavioral detail. It mentions fetching and rendering but no additional safety or side-effect information beyond what annotations provide.

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 with no redundancy. Front-loaded with the primary purpose and immediately clarifies the two usage modes.

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 tool with 5 parameters and an output schema, the description adequately covers the two entry points. However, it does not mention return format, error handling, or dependencies on other tools beyond the sibling.

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 all parameters with descriptions (100% coverage). Description adds value by explaining the dual-mode usage pattern (payload vs direct fetch) and which parameters apply in each scenario.

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 'renders the recommendations table' and distinguishes itself by being the 'preferred user-facing' tool. It also explains two modes of operation (using payload or fetching directly), differentiating it from sibling google_ads_get_recommendations.

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 guidance on when to use recommendationsPayload vs direct fetching with account arguments. However, it does not explicitly state when not to use this tool or mention specific alternatives beyond the sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it renders a dashboard and can fetch data, but no further behavioral traits like auth or error handling are disclosed.

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 concise sentences: first establishes purpose, second explains the dual mode. No fluff, front-loaded with 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?

Given 7 parameters with 100% schema coverage, an output schema, and the dual-mode complexity, the description covers the key usage patterns and connections to sibling tools. It doesn't need to explain output format due to output schema.

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 adds value by grouping parameters into 'search-term-analysis arguments' and connecting analysisPayload to the sibling tool, clarifying the dual-mode usage beyond what the schema alone conveys.

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's a user-facing tool that renders the search-terms analysis dashboard, distinguishing it from the analysis tool and other render tools. The verb 'renders' and resource 'search-terms analysis dashboard' are specific.

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 describes two usage modes: taking analysisPayload from google_ads_analyze_search_terms or fetching directly with arguments. This guides the agent on when to supply which parameters, and the reference to the sibling tool for analysis clarifies the workflow.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context that this is a visual render tool and advises to keep text brief, which is consistent and adds value beyond annotations.

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 every sentence provides essential guidance with no wasted words.

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 complexity (8 parameters, nested objects, many siblings), the description is complete enough for an agent to understand when and how to use it. It covers purpose, usage guidelines, and parameter linkage, though it could briefly mention the output format.

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% with detailed parameter descriptions. The description adds value by specifying that reportPayload is the structuredContent object from google_ads_get_weekly_group_report, linking the parameters to the data flow.

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 is a 'User-facing render tool for Google Ads visual weekly reports' and provides example prompts like 'show me a Google Ads report'. It distinguishes itself from the sibling tool google_ads_get_weekly_group_report by stating when not to call the other tool first.

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 says to use this tool for visual reports and not to call google_ads_get_weekly_group_report unless raw data is needed. It also advises to keep assistant text brief, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint, openWorldHint. The description adds behavioral details like bounded search, validated, allowlisted fields, and parameter limits (max 200 rows, max 10 filters, etc.), enhancing transparency beyond the annotations.

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, fitting key information in limited space. It front-loads the purpose. Could be slightly more concise, but overall it is well-structured 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 the presence of an output schema and thorough annotations, the description covers all necessary facets: purpose, constraints, when to use, and behavioral traits. No gaps are apparent.

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% with detailed parameter descriptions. The tool description does not add new semantic meaning beyond what the schema already provides, so 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?

The description clearly states it is an advanced tool for bounded, validated Google Ads searches using allowlisted fields, and distinguishes itself from higher-level workflow tools for reporting and diagnostics.

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 when to use this tool (criteria/settings exports, bidding, targeting) and advises against using it for reporting, directing to other tools, providing clear alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so no addition needed for safety. The description adds transparency about output specifics, such as video metrics included, but does not discuss potential side effects like rate limits or data staleness. It is consistent with annotations, 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?

The description is comprised of two focused sentences. The first covers the core workflow, the second adds video-specific details and usage guidance. Every sentence provides essential information without redundancy or fluff. Front-loaded with primary action.

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 presence of an output schema covers return value documentation. The description outlines the artifact's content (top creative rows, video metrics) sufficiently. It could mention edge cases (e.g., unresolved campaign, no data), but given the complexity and sibling differentiation, it is adequately 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 parameters are already described. The description adds value by contextualizing parameters within the workflow (e.g., 'compares performance across trailing windows' explains the windows parameter, 'returns top creative rows' explains detailRowCount). This integration provides meaning beyond the schema definitions.

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: it resolves a LinkedIn campaign by name, compares performance across trailing windows, and returns a compact analysis with top creative rows. It also explicitly distinguishes itself from the sibling tool linkedin_render_campaign_analysis by noting the latter is for the user-facing dashboard. The verb and resource are specific.

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 guidance on when to prefer an alternative (linkedin_render_campaign_analysis for the visual dashboard). However, it does not mention when NOT to use this tool, such as prerequisites (e.g., requiring an ad account) or scenarios where the compact analysis is insufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value by detailing the comprehensive output (included/excluded facets, audience expansion, alignment, recommendations). No contradictions. It does not disclose additional behavioral traits like rate limits, but the annotations cover the most critical aspects.

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 a single sentence that front-loads the purpose and lists key components. Every element earns its place; no wasted words. It is appropriately sized for the tool's simplicity.

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's complexity and the presence of an output schema, the description sufficiently covers what the tool does. It could benefit from mentioning that it uses session memory for defaults, but this is already in the schema. Overall, it is complete enough for an agent to understand.

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 100% for the two optional parameters (accountId, campaignId). The description does not add any extra meaning beyond what the schema already provides, so 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?

The description clearly states the verb 'audits' and the resource 'a LinkedIn campaign's targeting setup', specifying the output includes included/excluded facets, audience expansion, objective alignment, and recommendations. It distinguishes this tool from siblings like 'linkedin_get_targeting_insights' and 'linkedin_analyze_campaign' by focusing on auditing targeting setup specifically.

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 implies usage for auditing campaign targeting but does not provide explicit guidance on when to use this tool versus alternatives like 'linkedin_get_targeting_insights' or 'linkedin_analyze_campaign'. No exclusions or prerequisites are mentioned. The optional parameters and session memory hint is present in schema, not in description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds context beyond annotations: it compares trailing windows, surfaces video-specific metrics, and describes default windows/page sizes. No contradictions. Annotations already cover readOnly and openWorld, so description supplements well.

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?

Relatively concise at 7 sentences, front-loaded with purpose. The 'Schema revision' opening sentence is awkward and adds little value, but overall structure is good and each sentence earns its place.

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's complexity (7 params, output schema exists), the description covers scope, fallback behavior, metric highlights, and alternatives. Lacks detail on output format, but output schema compensates. Good 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?

Schema coverage is 100% with descriptions, but description adds strategic value by explaining the when/why of accountId vs campaignId vs campaignIds, and defaults for omitted parameters. Provides meaning beyond raw 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 it compares LinkedIn creative-level performance across trailing windows, and distinguishes from sibling tool linkedin_get_creatives by positioning itself as the preferred creative follow-up tool. Specific verb and resource.

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 tells when to use this tool vs alternatives ('instead of falling back to linkedin_get_creatives...'), explains parameter scoping rules for accountId vs campaignId(s), and describes default behavior when inputs are omitted. Very clear guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnly=true and destructive=false. Description adds that it returns validated deltas, defaults to account scope, and uses session memory for accountId. No contradictions, but could mention data freshness or rate limits.

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, each adding distinct value: purpose+output, usage guidance, and default behavior. No filler, well 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?

Covers purpose, usage boundaries, default behavior, and parameter behavior. With output schema existing, description is sufficient for correct selection and 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?

Schema coverage is 100%, so baseline 3. Description adds context for accountId (session memory fallback) but other parameters are straightforward from schema. Minimal 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?

Clearly states it's a 'raw data tool for comparing LinkedIn performance across two explicit date windows' and specifies it returns 'validated absolute and percentage deltas'. Distinguishes from report rendering tool, making purpose unambiguous.

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 tells when not to use ('Do not call this directly for user-facing prompts') and suggests alternative ('prefer linkedin_render_weekly_group_report'). Also explains default scope and how to narrow by campaignId.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint. The description adds context about ranking matches and returning compact data, which goes beyond annotations without contradiction.

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 with core purpose, no extraneous information. Every sentence contributes 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?

With an output schema, the description doesn't need to detail returns. It covers purpose, usage alternative, and behavioral context. Annotations and sibling tools complete the picture.

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 adds meaning by mentioning 'by name' and 'across one account or all', relating to query and accountId parameters, and implies ranking and disambiguation purpose 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 clearly states the tool finds LinkedIn campaigns by name, ranks matches, and returns compact identity data for disambiguation. It also differentiates from the UI picker (render_shared_picker).

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 notes when to prefer render_shared_picker for the user-facing UI, providing clear context. It lacks explicit 'when not to use' details but the alternative is sufficient for differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds value by specifying what aspects are checked (posture, scopes, access, etc.), reinforcing the non-destructive, read-only nature.

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 a single, reasonably concise sentence that lists key areas. It could be slightly more structured (e.g., bullet points) but is not overly verbose.

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 presence of an output schema and the description covering the tool's purpose and scope comprehensively, the description is complete for a health check 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 100% with both parameters well-documented. The description does not add additional parameter information, so 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?

The description clearly states it's a 'LinkedIn account health check' and enumerates specific areas (API version, OAuth, account access, etc.), distinguishing it from other LinkedIn tools like linkedin_get_ad_accounts or linkedin_get_campaigns.

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?

While 'Marketer-friendly' hints at target users and the health check implies a preliminary step, there is no explicit guidance on when to use this tool over alternatives or when not to use it. Siblings exist but no direct comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description matches annotations: readOnlyHint=true (reading accounts), destructiveHint=false. Adds value by stating it requires authentication and returns specific fields. 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?

Two concise sentences front-loaded with the action and purpose. Every word is meaningful 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?

With one optional parameter, good annotations, and an output schema, the description is fully adequate. It tells what the tool returns and why to use it.

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 'count', and the schema already describes its default. Description adds no additional semantic detail beyond what schema provides. Baseline 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 verb 'Fetches' and resource 'LinkedIn Ad Accounts'. It specifies what is returned (URN ID, name, currency, status) and the purpose (find target Account ID). Distinct from siblings which are mostly analysis or reporting 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 says 'Use this to find the target Account ID', indicating the primary use case. Though it does not mention when not to use it, the context is clear and the sibling list contains no similar listing tools for LinkedIn.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, establishing the tool as safe and read-only. The description adds context about the tool's nature ('raw data for focused follow-up'), default date behavior (startDate defaults to 30 days ago, endDate to today), and session context fallback. This goes beyond annotations without contradicting them, though it omits details like pagination or rate limits. A 4 is appropriate.

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, followed by a caution and fallback rule. Every sentence is necessary and no wording is wasted. It is concise and structured effectively.

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's complexity (12 parameters, 3 entity levels, output schema present), the description adequately covers the main use case (raw data pulls), exclusions (broad reports), fallback (session selections), and default date behavior. It does not need to explain return values since an output schema exists. The description is complete enough for an agent to use correctly.

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 100% (12 parameters all have descriptions). The description adds no new parameter-level info beyond the schema, but it provides helpful context such as 'The reach alias maps to LinkedIn's approximateUniqueImpressions metric' and explains the interplay between entityLevel, accountId, and campaignId. While useful, this is moderate added value over the schema, so a 3 (baseline) is correct.

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 is 'Raw LinkedIn ad analytics data tool for focused follow-up metric pulls at account, campaign, or creative level,' providing a specific verb, resource, and granularity. It distinguishes from siblings by explicitly naming linkedin_render_weekly_group_report, linkedin_render_campaign_analysis, and linkedin_render_creative_comparison as alternatives.

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 says 'Do not use this as the primary response for broad user-facing prompts like "generate a report"...' and lists three alternative tools. It also clarifies fallback behavior: 'When accountId or campaignId is omitted, recent LinkedIn session selections are used when available.' This provides clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds value beyond annotations by disclosing that pivotValues are always included, default fields are impressions and clicks, and that for MEMBER_COMPANY pivots, organization URNs may not resolve to public names. It also mentions session-based fallback for account/campaign IDs.

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 sentences, front-loaded with the core purpose, and each sentence adds necessary detail without redundancy. It efficiently covers the main behavior, defaults, and special cases.

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 complexity of 14 parameters and the presence of an output schema, the description effectively covers the tool's purpose, default fields, special MEMBER_COMPANY behavior, and session fallback. It is complete enough for an agent to understand when and how to use the 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?

With 100% schema coverage, baseline is 3. The description adds meaning by explaining the default behavior when fields are omitted and the special handling for MEMBER_COMPANY parameters, providing context that the schema alone does not.

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 specifies it fetches LinkedIn demographic reporting grouped by a demographic pivot, listing specific examples like industry, seniority, etc. It distinguishes from sibling tools by focusing on demographic breakdowns and mentioning default fields like impressions and clicks.

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 context such as default fields and special behavior for MEMBER_COMPANY pivots, but does not explicitly state when to use this tool versus alternatives like linkedin_get_ad_analytics or other demographic-related tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety. It adds a behavioral caveat about API data availability. However, it does not disclose pagination behavior or data freshness.

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 a single, clear sentence with 25 words. It front-loads the purpose and adds a caveat. Could be considered efficiently concise.

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?

With an output schema present and full parameter descriptions, the tool is well-documented. The description adds context about API-dependent behavior. However, it lacks mention of authentication requirements or prerequisite account setup.

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?

Input schema has 100% coverage with individual parameter descriptions. The description does not add significant meaning beyond the schema, so baseline 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?

The description clearly states it builds a campaign-group report with performance, linked campaigns, and pacing analysis. It specifies a specific resource (campaign group) and action (builds report). However, it does not explicitly differentiate from similar tools like linkedin_get_weekly_group_report.

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 implies usage for performance analysis of campaign groups, but it does not provide explicit guidance on when to use this tool versus alternatives. The phrase 'when the API exposes that data' hints at limitations but lacks exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond annotations (readOnlyHint, destructiveHint), the description adds that it uses MFP-friendly cursor pagination to preserve context window and defaults to session memory for accountId. This enriches behavioral understanding.

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 wasted words. The purpose is front-loaded, and pagination and accountId behavior follow succinctly.

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's complexity (6 optional params, output schema exists, annotations cover safety), the description is adequate. It covers purpose, pagination, and account fallback. Minor gaps like error handling or permissions are acceptable with annotations and output schema present.

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 100% schema coverage, baseline is 3. The description adds value by explaining the accountId fallback and the benefit of cursor pagination, which is not in the 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 clearly states it fetches LinkedIn campaigns within a specific Ad Account. The purpose is specific and actionable, but it does not explicitly differentiate from sibling tools like linkedin_find_campaigns.

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 guidance on how to use the cursor pagination and the accountId fallback, but lacks explicit when-to-use versus alternatives. Usage context is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and destructiveHint, and the description adds valuable behavioral context: it returns diagnostic details and performs optional live LinkedIn probes. No contradiction; fully transparent.

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 with purpose, followed by usage context. Every word serves a purpose; no redundancy or wasted text.

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?

With three optional parameters, no required params, an output schema, and annotations, the description is nearly complete. It could briefly note the need for a valid LinkedIn auth token, but this is implied and not critical.

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?

Input schema provides 100% description coverage for all three parameters, so the description adds no additional meaning beyond what is already in the schema. Baseline score of 3 applies.

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 returns diagnostic details for auth posture and optional live LinkedIn probes, and lists specific debugging scenarios (missing tools, OAuth scope issues, unresolved company names), distinguishing it from sibling diagnostic 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 tells when to use the tool ('Use this when debugging...'), providing clear context and three specific use cases. Does not exclude alternatives but sufficiently guides selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about its inventory/discovery nature and default account/campaign memory behavior, which is useful beyond the annotations.

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 with no wasted words. The first states purpose, the second clarifies boundaries and alternatives, and the third provides fallback guidance. Well structured and 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 the high schema coverage and presence of an output schema, the description covers purpose, usage boundaries, and default behaviors adequately for an 8-parameter tool with no required parameters.

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% with each parameter well-documented. The description reinforces the default behavior for accountId and campaignIds but does not add significant new semantics beyond what the schema already provides.

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 searches creatives within a LinkedIn Ad Account and specifies it is an inventory/discovery tool for creative IDs, names, statuses, and campaign associations. This distinguishes it from performance-related sibling tools like linkedin_compare_creative_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?

Explicitly instructs not to use this tool for performance queries and directs to linkedin_compare_creative_performance or linkedin_render_creative_comparison instead. Also explains fallback behavior when accountId is omitted.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint. Description adds context about returning a facet catalog and performing live discovery, which clarifies the tool's dual mode behavior.

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 with purpose, no wasted words. Efficient and clear.

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?

With good annotations, full schema coverage, and an output schema present, the description is adequate. It could benefit from a note on when to use facet vs entityUrns, but not critical.

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% with good descriptions. The description adds overall context but does not enhance understanding of individual parameters 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 clearly states it's a targeting explorer that returns a facet catalog and can run live adTargetingEntities discovery for one facet or entity URNs. This is specific and distinguishes it 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?

No explicit when-to-use or when-not-to-use guidance. The description implies a use case but does not contrast with alternative tools like linkedin_audit_campaign_targeting.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is clear. The description adds value by explaining the use of exact date windows and the purpose of avoiding overload, providing behavioral context beyond annotations.

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 a single sentence that efficiently conveys the action, context, and purpose. It is front-loaded with the verb and contains no superfluous words.

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 complexity of 10 parameters and the availability of an output schema, the description adequately explains the tool's role within the app (nesting creatives under campaigns). It could be more explicit about pagination behavior, but overall provides good context.

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?

All 10 parameters have descriptions in the input schema (100% coverage), so the tool description does not add additional meaning. The description itself is generic regarding parameters, so a 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?

The description clearly states that the tool fetches creative rows for one campaign within a LinkedIn weekly report using specific date windows. It differentiates from sibling tools like linkedin_get_creatives by specifying the context of a weekly report with comparison windows.

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 context for when to use the tool (fetching creatives for nesting under campaigns in a weekly report) but does not explicitly state when not to use it or mention alternatives like linkedin_get_creatives for simpler queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true; the description adds pagination behavior ('full paginated campaign rows'), which goes beyond the annotations and clarifies the tool's read-only and iterative nature.

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?

Single sentence that captures purpose, pagination, and effect. No unnecessary words; front-loaded with verb and resource.

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 existence of an output schema and full parameter descriptions, the description sufficiently explains the tool's role as a detail fetcher. It could benefit from mentioning relationship to the main report more explicitly.

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% (all parameters described in schema). The description adds no additional meaning beyond 'paginated', which is already implied by pageSize/pageToken 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?

Description indicates specific verb 'Fetches' and resource 'campaign rows for one reporting group', clearly distinguishing from sibling tools like 'linkedin_get_weekly_group_report' which returns the main report summary.

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 phrase 'while keeping the main report summary compact' implies when to use this tool (to avoid overloading the main report). However, no explicit when-not-to-use or alternative comparisons are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey readOnlyHint=true and destructiveHint=false. The description adds that it 'renders the dashboard,' implying a read operation, and the two modes. Beyond that, no additional behavioral traits (e.g., rate limits, side effects) are disclosed. Given annotation coverage, a score of 3 is appropriate.

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 every sentence serves a clear role. No unnecessary words.

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?

With a full input schema, annotations, and an output schema (though not shown here), the description adequately covers the two modes. It could elaborate on what 'render' entails (e.g., UI output), but the openWorldHint suggests external effects. Overall, sufficient for an agent's decision-making.

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 descriptions cover all parameters (100% coverage), but the description adds critical context: parameters query, endDate, etc. are used only when analysisPayload is not supplied. This clarifies mutual exclusivity and the tool's dual-mode behavior, adding value 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 clearly states it renders the LinkedIn campaign analysis dashboard, distinguishing it from sibling tools like linkedin_analyze_campaign (which produces the payload) and other render tools. The phrase 'preferred user-facing tool' adds clarity.

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 two usage modes: taking analysisPayload from linkedin_analyze_campaign or fetching directly with query/endDate arguments. This provides clear context, though it does not explicitly list scenarios when to use this tool over others, which is acceptable given sibling tools are for different platforms.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds behavioral context: it can either accept a pre-fetched payload or fetch data directly, explains precedence of accountId over campaignId, and details pagination with pageSize and pageToken. No contradictions with annotations.

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 (3 sentences) but dense with actionable information. It is front-loaded with purpose and usage, and every sentence adds value. 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?

Given 8 parameters, 100% schema coverage, output schema presence, and annotations, the description covers all necessary aspects: purpose, modes of operation, parameter selection criteria, and relationship with linkedin_compare_creative_performance. It is fully complete for agent decision-making.

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% with clear descriptions for each parameter. The description adds interpretative guidance, such as accountId taking precedence over campaignId, and pageSize max 200, which is not in schema. It provides strategic context for parameter selection beyond the schema definitions.

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 it renders the LinkedIn creative comparison dashboard and is the preferred user-facing tool for creative performance, winners/losers, or visual reports. It clearly distinguishes from siblings like linkedin_compare_creative_performance by specifying it is the visual renderer.

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 when-to-use guidance: 'Use this when a user asks for LinkedIn creative performance...' and gives conditional parameter guidance: pass accountId for broad analysis, campaignIds or campaignId only for explicit campaign scope. It also mentions it can take comparisonPayload from linkedin_compare_creative_performance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral context: it can either accept a pre-fetched reportPayload or fetch fresh data, and it specifies the like-for-like comparison rule for multi-window requests. The description enhances transparency without contradicting annotations.

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 a medium-length paragraph that front-loads the main purpose. However, it includes verbose example queries and slightly repetitious context about parameter usage. It could be more concise while preserving key guidance.

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 complexity (11 parameters, nested objects, output schema present), the description explains the overall workflow and comparison logic but does not cover error handling or parameter conflicts. It is fairly complete but leaves some gaps for a tool with this many parameters.

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 100%, so the baseline is 3. The description provides high-level context for parameter groups (e.g., 'when reportPayload is not supplied') but does not add significant detail beyond what the schema already provides for individual 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 it is the 'preferred user-facing LinkedIn Ads report tool' and provides specific example queries like 'generate a report...for the past 7 and 30 days'. It distinguishes from sibling tools by noting it is preferred for broad report requests and explains how it relates to linkedin_get_weekly_group_report.

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 for broad report requests' and provides example use cases. It mentions when to use it vs. alternatives (e.g., can take reportPayload from linkedin_get_weekly_group_report) and gives specific comparison logic for multi-window requests. However, it does not explicitly state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about fetching fresh grouped data, comparison logic (each window compares with preceding same-length period), and that it renders a combined dashboard. 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?

The description is a single well-structured paragraph. It is fairly long but necessary to convey the detailed usage rules. Could be slightly more concise, but overall 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 the complexity (18 parameters, no required params, nested objects), the description covers main usage scenarios, comparison logic, and how to handle prebuilt payloads. Output schema exists, so return values are covered. Provides enough completeness for correct 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?

Schema coverage is 100%, so baseline is 3. The description adds additional semantics by explaining usage patterns for endDate, lookbackDays, windows, and how to handle multi-window prompts, providing value 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 clearly states it is a 'Preferred user-facing cross-channel report tool' for combining Google Ads and LinkedIn Ads, distinguishing it from platform-specific siblings like linkedin_render_weekly_group_report and google_ads_render_weekly_group_report.

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 when to use ('when the user asks for one report covering both Google Ads and LinkedIn Ads'), provides example prompts, and includes guidance like 'do not fetch raw data first' and comparison behavior rules.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint, openWorldHint) are consistent; description adds context about fetching fresh status if called without payload, which aligns with read-only nature.

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 extraneous 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?

For a simple tool with one optional parameter and output schema, the description adequately covers both modes and key behavioral traits.

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 optional param; description clarifies that statusPayload comes from get_auth_setup_status and that omitting it triggers a fresh fetch, adding 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?

Description clearly states it renders the auth setup UI and can take a payload or fetch fresh status, distinguishing it from sibling get_auth_setup_status.

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 says it's the preferred user-facing tool and explains the two invocation modes (with or without payload), but does not explicitly state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and destructiveHint=false, leaving ambiguity. The description says 'renders' and 'fetch fresh status', suggesting it may cause state changes (e.g., fetching updates context). However, it does not disclose whether it modifies any state or has side effects beyond rendering. More explicit behavioral details would improve 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?

Two sentences, front-loaded with the primary purpose, followed by a clear explanation of the two invocation modes. No redundant words. Perfectly concise for the information conveyed.

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 simple interface (1 optional param, output schema present), the description covers the core behavior. It references the related tool get_context_setup_status. However, it could mention complementing save_context_onboarding or specify that it's for rendering only. Still, it is sufficiently complete for an agent to use correctly.

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 the single parameter contextPayload with a description pointing to get_context_setup_status. The description adds value by explaining the parameter is optional and that omitting it triggers a fresh status fetch. This enriches the agent's understanding 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 clearly states it is a 'Preferred user-facing client setup tool' that 'Renders the saved client context MCP UI'. It distinguishes from siblings by detailing two modes of operation: with contextPayload or fetching fresh status. The verb 'renders' and the resource 'client context MCP UI' are specific and actionable.

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 when to use the tool with contextPayload (from get_context_setup_status) and when to call it without (to fetch fresh status). It implies it is the preferred tool for client setup, but does not explicitly state when not to use it or describe alternatives like save_context_onboarding. Strong guidance but lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.