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

No annotations, so the description carries the burden. It discloses the row-granularity behavior of aggregation modes and that client_id is required when multiple clients exist, which is useful. But it doesn't state default date range behavior (the schema does), pagination, rate limits, or how many rows could be returned for high-cardinality 'day' queries.

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?

Front-loaded with purpose and metric list, then aggregation options, then filtering, then client lookup pointer. Every sentence earns its place and none repeat structured data verbatim.

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 read tool with rich schema and no output schema, the description covers metrics returned, granularity, filtering, and dependency on list_clients. The absence of an output schema means the metric list in the description does useful work. Minor gap: no mention of date defaults or that customer_ids overrides default accounts (both in schema, so acceptable).

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 7 parameters including the enum. The description's mention of aggregation semantics and filtering matches the schema rather than extending it. 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?

Specific verb (retrieves) + resource (Google Ads campaign performance metrics) + the platform differentiator against the many sibling get_*_campaign_performance tools (Meta, TikTok). An agent can immediately distinguish this from get_meta_campaign_performance or get_tiktok_campaign_performance.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use each aggregation ('campaign' default for totals, 'campaign_day' for trend analysis, 'day' for account-level timeseries) and points to list_clients for client IDs. However, it does not name when-not-to-use or point to sibling metric tools (search_terms, keywords, impression_share) that cover non-performance dimension 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?

With no annotations, the description carries the full burden and does disclose the exact metric set returned per bucket and the important behavioral fact that hours are in the advertiser's Google Ads time zone. It omits read-only confirmation, row-volume/limits, and date-default behavior, but the timezone and metric disclosure is substantive.

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: the first front-loads the breakdown shape, the second gives usage and metric list. No filler, and the most distinctive information (hour/day buckets) leads.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating the returned metrics and the bucket dimensions, which is exactly what an agent needs to interpret results. Missing only edge detail like empty-bucket behavior or row limits, which is minor for an aggregate report.

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 all five parameters are already documented in the schema (client_id, campaign_ids, customer_ids, date range defaults). The description adds only the timezone interpretation, which is bucket semantics rather than parameter semantics, so baseline 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?

States a specific verb (Returns) plus resource (Google Ads performance) and the exact breakdown axes (hour-of-day 0–23, day-of-week MONDAY–SUNDAY, per campaign). This cleanly separates it from get_google_ads_campaign_performance and the other non-hourly siblings.

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 names the use case (dayparting / ad-schedule analysis) and the downstream action it informs (ad_schedule bid adjustments). It does not name a competing sibling to route away from, so it stops short of full when/when-not 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?

With no annotations provided, the description must carry the full behavioral burden. It explains the meaning of metrics and gives interpretation heuristics, but does not disclose important operational details such as required permissions, rate limits, or what happens if no client_id is provided when multiple clients exist. For a read-only metrics tool, this is a notable gap.

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 front-loaded with the core purpose, followed by metric explanations and decision rules. It is efficient and each sentence adds value, though the transition from 'estimated_missed_impressions shows the scale...' to the decision rules could be slightly tighter. No redundant filler.

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 6-parameter, no-required-parameter tool with no output schema and no annotations, the description covers purpose, metrics, and actionable thresholds well. However, it omits behavioral aspects like authentication/configuration requirements and result format, which are needed for safe invocation. It is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters in detail. The description adds no parameter-specific information (e.g., format, default behavior) beyond what the schema provides. Thus, 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 opens with a specific verb (Retrieves) and resource (impression share metrics), and explicitly scopes it to Search and Performance Max campaigns. It clearly distinguishes itself from the sibling performance tools by focusing on impression share, loss breakdown, and opportunity metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides actionable interpretation rules (budget-lost > 20% → increase budget; rank-lost > 30% → improve bids/QS) and directs to list_clients for client IDs, which gives clear context for when to use the tool. However, it does not explicitly state when to use this tool versus other performance tools or any 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?

With no annotations, the description carries the full burden, and it does disclose non-obvious behavior: the account-level QS distribution summary, the 1-4 flagging rule, and the CPC consequence. It omits permissions/auth requirements, rate limits, and pagination behavior, which keeps it from a 5.

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?

Four sentences, front-loaded with purpose and then progressively more operational detail; little waste. The min_impressions advice mildly duplicates the schema text, which is the only 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?

For an 8-parameter read tool with no output schema and no annotations, the description covers purpose, output shape, and the key filter heuristic, and points at list_clients for the client_id prerequisite. It does not explain pagination/limit interaction or return ordering beyond what the schema states, leaving a small 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 schema already documents all 8 parameters including defaults and the min_impressions=100 recommendation. The description largely restates that same min_impressions guidance rather than adding format or interaction semantics, matching the baseline 3.

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?

States a specific verb and resource ('Retrieves keyword performance and Quality Score data from Google Ads') and names the concrete artifact returned (quality_score_distribution). This is clearly distinguishable from siblings like get_google_ads_search_terms or get_google_ads_campaign_performance without opening any schema.

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?

Gives actionable usage context: 'Use min_impressions=100 to focus on keywords with enough data for reliable QS' and routes the agent to list_clients for client IDs. It stops short of explicitly stating when to choose this over the sibling search-terms or campaign-performance tools, so it lacks true alternatives/exclusions 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?

With no annotations, the description carries the full behavioral burden. It helpfully defines wasted spend as terms with budget consumed but zero conversions and discloses the response-level fields (total_spend, wasted_spend, wasted_spend_pct), which partly compensates for the missing output schema. It says nothing about permissions, rate limits, or result volume 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?

Front-loaded with purpose, then readable guidance sentences. Efficient overall, though the min_spend and zero_conversions_only sentences largely duplicate schema text and could be trimmed.

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 an 8-parameter read tool with no annotations and no output schema, the description covers return aggregates and the key filtering flags, which is most of what an agent needs. Missing pieces are auth/client resolution details and pagination/limit behavior.

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 8 parameters, and the baseline is 3. The description restates zero_conversions_only and min_spend semantics that the schema already provides, adding no format or interaction detail beyond it.

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?

States a specific verb and resource ('Retrieves search term performance data from Google Ads') and frames the distinctive purpose (identifying wasted spend), which separates it from get_google_ads_keywords and the campaign-performance siblings. It does not explicitly name those siblings, so it stops short of a 5.

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?

Gives concrete invocation guidance: zero_conversions_only=true to focus exclusively on wasted spend, min_spend to filter negligible terms, and list_clients to discover client IDs. It lacks an explicit 'when not to use this vs get_google_ads_keywords' comparison, but the usage 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?

No annotations are provided, so the description carries the full burden. It discloses the algorithm (rolling-baseline Z-score), the per-campaign-metric evaluation scope, severity banding (severe/moderate/mild based on multiples of threshold), direction (spike vs drop), and output ordering (severity → recency → |z|). It does not state auth requirements, rate limits, or computational cost, but the behavioral disclosure is unusually rich for an analysis tool.

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?

Front-loaded with the core purpose and carries dense technical detail in a few sentences. Every sentence contributes to understanding the algorithm or usage. Slightly long but justified by the complexity of the detection model; no obvious padding.

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 an analysis tool with 8 parameters, 100% schema coverage, no output schema, and no annotations, the description supplies the algorithmic context an agent needs to interpret results (what a flag means, severity levels, sorting). It does not describe the return format (list of anomalies with fields), which would help, but the core call-time context is 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 the schema already documents all 8 parameters with defaults, ranges, and formats. The description adds semantic meaning by explaining what baseline_days and z_threshold do in the algorithm (trailing days vs prior baseline, flagging threshold), which is helpful context beyond the schema's terse descriptions. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb+resource ('Detects daily anomalies in Meta campaign performance') and immediately distinguishes itself from the closest sibling by referencing Meta's MCP ads_insights_anomaly_signal and clarifying it is computed locally. An agent can differentiate this from get_meta_campaign_performance and get_tiktok_anomaly_signal without opening schemas.

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 the use case at the end: 'Use to triage something changed yesterday before doing a full audit.' It also names the equivalent MCP tool, effectively routing the agent between local and remote anomaly detection. When-to-use is clear; when-not-to-use is implied by 'before doing a full audit.'

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?

No annotations, so the description carries the full burden and does well: it discloses the sort order (worst offenders to top), the below_average_count output, the default min_impressions threshold and why it exists (Meta never assigns labels under that volume), and the underlying endpoint (/act_<id>/insights at level=ad). It does not state auth requirements 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?

Dense but front-loaded: the return payload and label set come first, then the computation, then the sort rationale, then the filter. Every clause is informative; slightly long but not padded.

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 7-param read tool with 100% schema coverage and no output schema, the description explains the returned fields, the label semantics, the default threshold behavior, and the sort output. An agent has everything needed to call it correctly; only auth/permission context is absent.

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 reinforces the min_impressions default and its rationale and the meaning of the date range defaults (today, 30 days ago), adding minor value beyond the schema but not new syntax or constraints.

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?

States a specific verb and resource (returns Meta's three auction-ranking labels per ad) and enumerates the exact labels and value domains. An agent can distinguish this from siblings like get_meta_campaign_performance or get_tiktok_auction_rankings without opening the schema.

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?

Clearly establishes context: it filters out low-volume ads and surfaces worst offenders. It names the sibling Meta MCP tool (`ads_insights_auction_ranking_benchmarks`) for the same data, implying equivalence, but does not state when to prefer this tool over that one or over get_meta_campaign_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?

No annotations are provided, so the description bears the full burden. It discloses the return granularity (campaign × day) and enumerates returned metrics, which is helpful. But it doesn't mention authentication needs, rate limits, pagination behavior, or what happens when client_id is omitted but multiple clients are configured (schema hints it's required then, but description is silent).

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?

Four sentences, each front-loaded and informative: purpose, return metrics, filtering, granularity, and a pointer to list_clients. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose, filters, and return granularity, but with no annotations and no output schema, it should do more to disclose behavioral traits like required permissions or default behaviors when parameters are omitted. It's adequate but not rich enough for a tool with six optional 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 schema already documents all six parameters in detail. The description adds only a high-level overview of filters (date range, account/campaign IDs, status) without adding syntax, format details, or constraints beyond what the 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?

States a clear verb (Retrieves) and specific resource (Meta campaign performance metrics) with explicit scope (Facebook/Instagram). It distinguishes itself from Google/TikTok siblings by platform, though it doesn't differentiate from get_meta_hourly_performance, which is a plausible confusion given the sibling list.

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 advises using list_clients to find client IDs and describes what filters are available, which implies usage. However, it gives no explicit guidance on when to use this tool versus get_meta_hourly_performance or get_meta_opportunity_score, leaving the agent to infer based on granularity.

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?

No annotations are provided, so the description bears full burden. It discloses the time-zone semantics (audience time zone) and how dimensions are derived (day-of-week client-side, hours from Meta's hourly_stats_aggregated_by_audience_time_zone), which is useful behavioral context. However, it omits the safety profile (read-only?), rate limits, and pagination 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 dense sentences with no filler. The purpose and use case are front-loaded, followed by metric and derivation details. Slightly long but every clause earns its place for a complex analytical tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description correctly enumerates the returned metrics and their sources. It covers the analytical context and data derivation. Lacks explicit mention of the zero-required-parameter behavior (e.g., returns all campaigns if campaign_ids omitted, defaults for date range are in schema). Fairly complete but missing some operational details.

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 five parameters. The description adds no additional meaning about parameter syntax or defaults beyond what the schema provides. Baseline 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?

States a specific verb and resource ('Returns Meta Ads performance broken down by hour-of-day and day-of-week per campaign'), distinguishing it explicitly from the sibling get_meta_campaign_performance, which lacks the dayparting dimension. The granularity (hour 0-23, MONDAY-SUNDAY) is 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?

Gives a clear use case ('Use for dayparting / ad-set scheduling analysis') and the analytical goal ('identify when ads perform best and worst'). Does not explicitly name the alternative (get_meta_campaign_performance) or state when not to use this tool, but the intended 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?

With no annotations, the description carries the burden and does well: it names the underlying Marketing API edge (/act_<id>/recommendations), discloses the auth model ('client's stored access token'), and describes the normalized return shape. It does not state whether the call is read-only or how large the recommendation queue can get, but for a read-style score endpoint the disclosure is above par.

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?

Front-loads what is returned, then the mechanics, then the use cases; no filler sentences. It is slightly dense with parenthetical detail, but every clause carries 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?

There is no output schema, and the description compensates by listing the normalized fields of each recommendation and the score range. It stops short of explaining how to interpret the 0–100 scale, empty queues, or partial-failure behavior, leaving a small gap for a two-parameter aggregation 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 description coverage is 100% — client_id points at list_clients in the schema and ad_account_ids documents its override behavior — so the schema does the heavy lifting. The description adds only the implicit link that the stored access token is resolved via the client, not new per-parameter semantics. Baseline 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?

States a specific verb and resource — Meta's account-level Opportunity Score plus the recommendations queue — and enumerates the recommendation categories covered. It is clearly distinguishable from the sibling performance/auction/anomaly tools, which return metrics rather than scores and 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?

Explicitly enumerates three usage contexts: scoring an account quickly, feeding recommendations into a Meta audit, and prioritising high-lift fixes. Strong positive guidance, but it names no alternatives or when-not conditions (e.g., when to prefer the performance tools instead).

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?

No annotations are provided, so the description carries the full behavioral burden. It adds real value by naming the four video-engagement metrics and an interpretation rule, but says nothing about pagination behavior, return format, auth requirements, or rate limits for a 9-parameter list tool.

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?

Front-loads the core purpose then adds three tight metric-definition sentences. Dense and readable, though the metric list could be trimmed by an agent that already knows TikTok terminology.

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 9-parameter read tool with no annotations and no output schema, the description explains the return metrics but omits pagination limits (limit max 500 is in schema), default date behavior, and how it differs operationally from sibling performance tools. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all nine parameters (limit, ad_ids, statuses, client_id, date_range, etc.) are already documented in the schema. The description adds no per-parameter syntax or meaning beyond what the schema provides, so the baseline 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?

States a specific verb and resource (returns TikTok Ads performance) and explicitly scopes it to the ad level with the campaign → ad group → ad hierarchy. Distinguishes it from sibling get_tiktok_campaign_performance by naming the ad grain.

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 performance-analysis usage and gives an interpretive heuristic (2s hold < 30% = creative-refresh signal), but never states when to use this tool versus get_tiktok_campaign_performance or get_tiktok_hourly_performance. No explicit when/when-not 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?

With no annotations, the description carries the full burden and does well: it discloses the algorithm (rolling-baseline Z-score), the defaults (baseline_days=14, z_threshold=2.0), the severity tiering rules, and the result ordering (severity → most-recent → |z|). It omits auth/data-source constraints and any pagination or result-size behavior, so it stops short of a 5.

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?

Four dense sentences, fully front-loaded with purpose first, then model, then mechanics, then ordering. No filler and nothing repeated from structured fields.

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 an 8-param, no-annotation, no-output-schema tool, the description supplies the algorithm, defaults, severity logic, and sort order an agent needs to interpret results. It leaves the returned payload shape and data-source scope unspecified, which is the only meaningful 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, but the description adds genuine derived meaning: severity tiers are computed relative to z_threshold, and date_range_start defaults to baseline_days + 14 days ago, a relationship not visible in the schema. It also enumerates the six evaluated metrics, reinforcing the schema enum.

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?

States a specific verb (detects), resource (daily anomalies in TikTok campaign performance), and the model used, and explicitly names the sibling it mirrors (get_meta_anomaly_signal). An agent can distinguish it from get_tiktok_campaign_performance and the meta sibling without opening any schema.

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 positions this as the TikTok counterpart to get_meta_anomaly_signal and describes the evaluation scope (campaign × metric), which implies when it applies. But it never states when to prefer it over get_tiktok_campaign_performance or get_tiktok_hourly_performance, nor any prerequisites.

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?

With no annotations, the description carries full burden and does well: it discloses the sort order (worst offenders to top), a computed field (below_average_count), the impression filter and its default, and null-handling for tiers lacking video_quality_score. It omits auth requirements, pagination, and response envelope shape, keeping it short of a 5.

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 dense but well-packed sentences, front-loaded with the returned fields before behavior. Every sentence carries information, though the phrase about the platform burning creatives is slightly editorial.

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 no output schema and no annotations, the description adequately specifies the return fields, their value domains, the derived count, and sorting. It stops short of describing the overall result envelope or how multiple filter parameters combine, but covers what an agent needs to invoke it 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 coverage is 100%, so the schema already documents all seven parameters and their defaults. The description only elaborates on min_impressions (its throttle purpose) and says nothing about ad_ids, campaign_ids, advertiser_ids, or the date range filters, so it adds little beyond baseline.

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?

States a specific verb (Returns) and resource (per-ad TikTok ranking signals) and enumerates the exact output fields: video_quality_score, engagement_rate_ranking, conversion_rate_ranking. An agent can distinguish this from get_tiktok_ad_performance and get_meta_auction_rankings purely from the description.

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?

Usage is implied through the statement that '1+ below-average rankings is a creative-refresh trigger on TikTok,' which signals the intended scenario. However, it never explicitly says when to choose this over siblings like get_tiktok_ad_performance or get_tiktok_campaign_performance, so the guidance remains inferential.

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?

With no annotations, the description carries the full burden. It usefully discloses data granularity (campaign × day) and the upstream endpoint (/report/integrated/get/), but omits pagination behavior, result limits, and whether client_id resolution requires a per-call lookup. Adds some value but leaves meaningful behavioral gaps for a data-retrieval tool.

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 return shape then capabilities; the metric enumeration is long but informative for an output-less schema. Little waste overall, though the API endpoint reference borders on internal detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by naming the exact returned metrics and the row granularity. Filtering is covered, but pagination/row limits and behavior when client_id is omitted remain unstated, leaving a modest 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 schema already documents all six parameters including defaults and the list_clients pointer. The description merely paraphrases the same filter categories (date range, advertiser IDs, campaign IDs, status) without adding syntax, interaction, or precedence detail. 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?

States a specific verb (Retrieves) and resource (TikTok Ads campaign performance metrics) with the returned metric set enumerated. It also implies differentiation from siblings via the 'campaign × day granularity' note, though it never names the sibling tools it differs from (get_tiktok_hourly_performance, get_tiktok_ad_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?

It lists what can be filtered (date range, advertiser IDs, campaign IDs, status) but gives no explicit when-to-use guidance, no when-not-to-use, and no routing to alternative tools when a different granularity is needed. Usage is only implied by the description of capabilities.

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?

No annotations are provided, so the description must carry behavioral burden. It usefully discloses the underlying source endpoint, the stat_time_hour dimension, and—crucially—that hours are in the advertiser's account time zone. It does not cover permissions/auth needs, rate limits, or pagination. A meaningful addition beyond a bare description, but not a full behavioral profile for a no-annotation tool.

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 front-loaded sentences: what it returns, where it comes from, and when to use it. Efficient and well-organized. The Spain dayparting example is arguably extra but adds practical value; not wasteful overall.

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 read-only reporting tool with no output schema, the description gives granularity, source endpoint, time-zone semantics, and usage context—enough for an agent to invoke it correctly. It lacks only auth/exclusion details, which is a minor gap given the structured fields 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?

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds scope/context (per campaign, granularity) but no parameter-level syntax or defaults beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource ('Returns TikTok Ads performance') and pins down the exact granularity (hour-of-day 0–23 and day-of-week MONDAY–SUNDAY, per campaign). This clearly distinguishes it from the sibling get_tiktok_campaign_performance (daily/aggregate) and parallels get_meta_hourly_performance / get_google_ads_hourly_performance for other platforms.

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 gives explicit use context ('Use for dayparting / ad-schedule analysis') and cites TikTok-specific patterns, but does not state when NOT to use it or explicitly route to the alternative hourly tool for other platforms. The intent is clear, but the alternative-selection guidance is implicit.

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?

No annotations are provided, so the description carries the full burden. It does disclose the return payload (ID, name, platforms), which is useful behavioral context, and 'Lists' implies a non-mutating read. But it says nothing about auth requirements, whether results are paginated, empty-state behavior, or caching/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, no filler, and the most important detail (call this first to get client_id) is placed at the end as the actionable takeaway after the payload description. 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?

For a parameterless discovery tool with no output schema, the description fully compensates by enumerating the returned fields and the platform enum values (google_ads, meta_ads, tiktok_ads). An agent has everything needed to call it and consume the result.

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, the baseline is 4. The description goes slightly beyond by explaining the meaning of the returned client_id ('used in other tools'), which is the key semantic an agent needs even though it isn't an input.

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?

States a specific verb and resource ('Lists all configured accounts available in this MCP server') and immediately clarifies the shape of what an account is (ID, name, platforms). An agent can distinguish it from the many per-platform performance siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing instruction: 'Call this first when you need to know which client_id to pass to other tools.' That names both the trigger condition and the downstream dependency on sibling tools, which is exactly the guidance needed for a discovery tool.

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