mureo

by logly

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.7
Disambiguation4/5
Most tools are clearly distinguished by platform (google_ads, meta_ads, search_console) and action type, but the sheer number of similar operations across platforms (e.g., multiple 'create', 'list', 'update' tools) could cause confusion. Detailed descriptions mitigate ambiguity.
Naming Consistency5/5
Tool names follow a strict `platform.area.action` pattern (e.g., google_ads.campaigns.list, meta_ads.ads.create). Exceptions like analysis tools and rollback utilities are minor and still sensible.
Tool Count2/5
173 tools is excessive for a single MCP server. While they cover three major platforms and auxiliary functions, the volume impairs discoverability and suggests the server would benefit from decomposition into smaller, more focused servers.
Completeness4/5
The tool surface is extremely broad, covering CRUD, reporting, analysis, and diagnostics for Google Ads, Meta Ads, and Search Console. Minor gaps exist (e.g., no dedicated delete for Google Ads image assets), but overall coverage is comprehensive.
Average 4.5/5 across 158 of 173 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 24 of 24 community issues answered or closed in the last 6 months
- 325 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavioral traits. The text only says 'Get top pages' with no mention of authentication, rate limits, data freshness, or that it's read-only. It doesn't add any context beyond the action itself, leaving the agent without safety or nuance information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two short sentences, highly efficient and front-loaded. It states the core action first, then adds the shortcut relationship. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what 'top pages' returns (e.g., metrics, fields) and how 'top' is defined. It also doesn't clarify behavior when site_url is omitted or the row_limit default. The description is too sparse for an agent to fully anticipate the tool's output and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds the context that the tool uses a fixed dimensions=['page'], which clarifies why there is no dimension parameter and that the query is specialized. This minor extra meaning justifies the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get top pages for a site.' It also distinguishes itself from sibling tools by mentioning it's a shortcut for analytics.query with dimensions=['page'], which sets it apart from top_queries and device_breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Shortcut for analytics.query with dimensions=["page"]' implicitly tells the agent when to use this tool: when the desired output is top pages with a fixed page dimension, without needing to build a custom query. It doesn't explicitly list exclusions or alternative tools, but the shortcut framing provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Get device breakdown for a site' without disclosing return format, default row limit, or specific behavior. The shortcut reference to analytics.query adds some context, but it doesn't describe what the response looks like or any limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and a concise explanation of its relationship to the general query tool. No redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but includes a useful reference to analytics.query, which helps an agent infer that input and output behaviors align with that tool. However, without annotations or an output schema, the description could be more explicit about return values and required site_url usage. It's adequate but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all four parameters. The tool description does not add any parameter-specific guidance, but since the schema already documents each parameter adequately, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get device breakdown for a site' with a specific action and resource. It additionally distinguishes itself by noting it's a shortcut for analytics.query with dimensions=['device'], which separates it from the general query tool and other breakdown tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates this is a shortcut for analytics.query, implying it's the right choice when you specifically need device breakdown without writing the full query. It doesn't explicitly mention when not to use it or compare with other breakdown tools like top queries or top pages, but the context is relatively clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it only states the action and shortcut. It does not disclose behavior such as optional site_url meaning 'single verified site', how 'top' is determined (e.g., sort order), pagination, or response format. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the purpose, and the shortcut explanation is valuable. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple wrapper tool with no output schema and no annotations, the description should clarify return values and scope. It says 'top queries' but does not define the metric or whether site_url is required. The shortcut reference provides some context but leaves meaningful gaps for an agent deciding on this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the baseline is 3. The description does not add additional parameter-specific meaning beyond what the schema already provides, though it implies the tool is limited to the query dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get top search queries for a site' with a specific verb and resource. The 'Shortcut for analytics.query with dimensions=['query']' note distinguishes it from the general analytics.query tool and from siblings like top_pages and device_breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear alternative by noting this is a shortcut for analytics.query with a specific dimension, implying use when only query-level data is needed. However, it does not explicitly say when not to use it or contrast with top_pages/device_breakdown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It does disclose the output format (PNG) and intended use, but it does not mention the return mechanism, potential errors, rate limits, or any side effects. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the action, format, and purpose without any unnecessary words. It is front-loaded with the key verb and resource, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must clarify what the tool returns, but it only states the format (PNG) without explaining whether the output is a base64 string, a file path, or a URL. The purpose clause adds context, but the missing return mechanism leaves a gap for an agent deciding how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single 'url' parameter with a description, so the description adds no extra semantic detail. It does not clarify URL format requirements, accessibility constraints, or query parameters. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Capture') with a clear resource ('URL screenshot') and format ('PNG'). It distinguishes itself from sibling tools by being the only screenshot-capturing tool among them. The purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context ('for message match evaluation'), implying when it should be used. However, it does not explicitly state when not to use it or mention any alternative tools, though none of the siblings directly compete with this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It reveals that the tool creates a new run directory and provenance manifest, uses headless Chromium, requires the 'creative' extra, and handles Japanese text rendering. This is meaningful side-effect and prerequisite context beyond what the schema or name provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary purpose, then key technical detail and prerequisite. No filler; each sentence adds useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input (visual/copy/template/formats), output (PNGs in new run directory with manifest), tech behavior, and install requirement. It doesn't detail return values, but no output schema exists and the run-directory statement is sufficient for an agent to understand the result. Minor ambiguity about where the brand kit/logo comes from (no parameter) prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 100% of parameters, so the baseline is 3. The description reiterates the template/formats/copy parameters in prose and mentions the typography layer containing badge/logo, but adds little syntax or value beyond the schema. The badge's template-specific behavior is already noted in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('composite') and the resource transformation: ad copy + brand kit + key visual → per-format banner PNGs. It distinguishes itself from sibling tools like creative_studio_generate_visual and creative_studio_edit_visual by describing the composition/final render workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent to pick a template and formats and pass copy, implying usage for rendering banner ads from an existing visual. However, it does not explicitly state when to prefer this over sibling tools or mention exclusions/alternatives, so guidance is mostly implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations available, so description must carry disclosure burden. It states 'Read-only' and describes output fields, but omits pagination, error behavior, and rate limits. Adequate but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four compact sentences front-loaded with primary action, followed by return fields, read-only flag, and a diagnostic use case. No redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but description details the full return shape and even example enum values. Lacks pagination and result limits, but sufficient for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema documents both parameters with 100% coverage, including account_id format and fallback. Description adds catalog context but no parameter-specific detail beyond schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies verb (Lists) and resource (product feeds for a Product Catalog), and enumerates return fields. Distinguished from sibling feed-related tools by focusing on feed health listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use case: 'Use this to audit feed health' and links to missing products in DPA. Does not mention exclusions or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: read-only, only rows with conversions > 0 are included, and the technical limitation that cost_per_conversion is computed separately due to GAQL constraints. It also explains the full response structure. It lacks details on authentication or error handling, but for a read-only report these are less critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is information-dense but well-organized: a concise purpose statement, a detailed return shape, key filtering behavior, a technical caveat, and an explicit alternative. Every sentence adds value, though the lengthy output structure makes it less concise than ideal. Overall, it earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of an output schema, the description goes far beyond minimal by specifying the exact return objects (actions, daily_details, landing_pages) and their fields. It also explains row filtering and the GAQL limitation. It does not cover items like pagination or rate limits, but these are less likely to be significant for a reporting tool with this shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a descriptive schema entry (period enum with guidance, campaign_id as optional filter, customer_id with fallback). The description adds no extra parameter semantics beyond what the schema provides, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports Google Ads conversions broken down by conversion_action and date, with an optional campaign filter. It explicitly distinguishes from sibling tools by pointing to google_ads_performance_report for campaign-level metrics, and the detailed return structure leaves no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clear: it's a read-only conversion breakdown tool. The description explicitly says 'For campaign-level metrics use google_ads_performance_report', providing a direct alternative. It does not mention other potentially relevant alternatives (e.g., ad performance or search terms reports), but the guidance is sufficient for distinguishing from the most likely sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses atomic persistence, preservation of other report kinds, best-effort behavior when MCP is unavailable, and the return value (updated state document). This is substantial and goes beyond a simple purpose statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is moderately long but front-loaded with purpose, then covers parameter semantics and behavioral details. Each sentence contributes meaningful information without fluff. The structure is logical and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with a rich schema (enum, nested object details, path constraints), the description explains purpose, behavior, and return value. No output schema, but return is mentioned. Missing explicit permission details, but not critical for this MCP context. Overall complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with detailed descriptions (enum values, summary structure, path restrictions). The description adds a brief overview of summary conventions but mostly repeats what the schema provides. Baseline 3 is appropriate because schema does the heavy lifting for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Atomically persist a structured analysis report summary into STATE.json's reports section'. Clearly distinguishes from sibling state tools by targeting report summaries for the read-only dashboard. Unambiguous and immediately conveys the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use: to persist daily/weekly/goal report summaries so the dashboard can render without re-running the agent. Also gives behavioral context with 'best-effort' guidance to skip silently when MCP is unavailable. Does not explicitly name alternative tools or exclusions, but the intended use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and largely succeeds: it discloses return ordering (severity-ordered), specific anomaly types (zero spend, CPA spike, CTR drop), gating thresholds, and the null-baseline condition. It stops short of describing every edge case (e.g., read-only behavior) but provides strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense, non-redundant sentences. The first front-loads purpose, the second lists concrete outputs and thresholds, and the third explains an edge-case condition. Every sentence earns its place; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex detection tool with no output schema, the description covers core inputs, thresholds, null-baseline behavior, and return ordering. It does not specify the exact anomaly object structure, but given no output schema that is a minor, not critical, gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all four parameters with descriptions (100% coverage), so baseline is 3. The description adds valuable interpretive context: median-based baseline source, severity gating thresholds, and the default min_baseline_entries=7 behavior, which deepens understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Detect anomalies for one campaign by comparing its current metrics against a median-based baseline built from STATE.json's action_log history.' This specifies a concrete verb, resource, and method, distinguishing it from general analysis siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single-campaign anomaly detection and mentions internal threshold conditions (e.g., 30+ conversions, 1000+ impressions), but does not explicitly instruct when to choose this tool over alternatives like google_ads_cpc_detect_trend or meta_ads_analysis_cost. No exclusions or alternative references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only — does not change anything,' which is a clear safety guarantee. It further describes the return behavior: an ordered list of issues drawn from specific status fields, with examples of issue types and the format of each item (plain-language description and remediation hint). This provides meaningful transparency about both side effects and output semantics, though it does not discuss error handling or rate limits. Given the absence of annotations, this is a solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and each sentence earns its place: the first states the purpose and output, the second guarantees read-only behavior, and the third gives usage guidance. It is front-loaded with the core purpose, includes concrete examples, and contains zero filler or redundancy. This is a model of concise yet informative writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a diagnostic tool with no output schema, the description provides a remarkably complete picture: what it does, what it returns (ordered issues with descriptions and hints), the data sources (serving_status, primary_status, primary_status_reasons), safety (read-only), and usage context (before raw reports). It does not mention error conditions or ordering criteria explicitly, but for a single-campaign diagnostic with no output schema, the description is nearly sufficient. The only minor gap is the lack of explicit alternative tool references, but this is covered under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both campaign_id and customer_id having explicit descriptions in the schema. The description itself does not add any parameter-specific details beyond the schema—it refers to 'a campaign' but does not elaborate on the customer_id fallback behavior, which is already covered by the schema. Since the schema handles the parameter semantics, this is a baseline 3 for a high-coverage scenario.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Explains why a campaign is not serving or is under-delivering.' It goes beyond a vague verb by specifying the resource type (campaign) and the specific diagnostic angle (serving/under-delivery), and it distinguishes itself from raw reporting tools by framing its output as an ordered list of actionable issues. This is a specific verb+resource+scope, strongly differentiated from siblings like google_ads_campaigns_get or google_ads_performance_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Use this before pulling raw performance reports; it narrows the problem space.' This establishes a clear context and prioritization relative to performance reporting. It does not explicitly name alternative diagnostic tools (e.g., google_ads_health_check_all) or give when-not-to-use scenarios, but the provided context is sufficiently actionable. This fits 'clear context, no exclusions' rather than a full alternative analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses read-only behavior, return structure, target_cpa resolution priority, handling of new terms, and default period. However, it does not list the 'six hardcoded rules,' which is a notable omission for a tool that scores based on them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the core action and then detailing outputs, resolution logic, and exclusions. Every sentence adds value, though the return structure explanation could be seen as verbose without an output schema. Still, it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description appropriately explains return values and behavior. It covers read-only status, target_cpa resolution, new terms handling, and default period. However, the undefined 'six hardcoded rules' and the ambiguous 'intent_analysis?' leave gaps for a complex tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds some value by reinforcing the target_cpa fallback order and default period, but most parameter semantics are already captured in the schema. It does not introduce substantial new meaning beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Score every search term in a Google Ads campaign against six hardcoded rules and split them into add / exclude / watch buckets.' It uses a specific verb and resource, and distinguishes itself from sibling tools by naming alternatives for different analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'For keyword/N-gram overlap stats use google_ads_search_terms_analyze; for the raw query log use google_ads_search_terms_report.' It also states the default period and indicates read-only usage, providing clear context on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly discloses read-only behavior and lists the return field categories, but doesn't mention pagination behavior, rate limits, or error conditions. This is adequate but not rich; it covers safety (read-only) but leaves some operational details to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action ('Lists...'), and every sentence adds value: the first defines scope and return fields, the second gives concrete use cases. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with two optional parameters and no output schema, the description covers purpose, return values, and use cases. It doesn't explain pagination or sorting, but that's not critical for selecting/invoking correctly. The description provides enough context for an agent to act on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters (limit and account_id). The description doesn't add new parameter-level details 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Meta Automated Rules, identifies the resource (ad account), and specifies the returned fields (id, name, status, evaluation_spec, execution_spec, schedule). It distinguishes itself from sibling ad rule tools (get, update, create, delete) by explicitly focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this to audit existing automation before adding new rules or to find a rule_id before disabling / deleting an old one.' This clearly tells the agent when to call this tool versus alternatives, and the 'Read-only' note implies it's not for making changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly marks the operation as 'Read-only', which is a key behavioral trait. It also lists the exact fields returned. It does not mention pagination or rate limits, but the schema already documents the limit parameter, and the read-only disclosure is sufficient for safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and efficiently packs in returned fields and usage guidance. Every sentence earns its place, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a list tool: it explains the purpose, return fields, read-only nature, and use cases. The schema handles parameter details, and there is no output schema, so the field list is essential and provided. It could mention behavior with no results or pagination, but that is minor given the schema's limit description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds minimal parameter semantics beyond what the schema already provides—it reinforces the optional campaign scoping, but does not introduce new meaning for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists ad sets in a Meta Ads account, with optional scoping to a single parent campaign. It enumerates the returned fields, and the verb 'lists' is specific to this read operation, distinguishing it from sibling tools like meta_ads_ad_sets_get or meta_ads_ad_sets_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'use this to audit delivery settings or to find an ad_set_id before creating ads.' It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 well: it declares the operation as read-only and describes the output (decomposition with per-driver magnitude and action hint). It does not go into quota/cost limitations or auth details, but that is not critical 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, and the second gives the primary use case. Every sentence adds value, and the list of drivers is informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a diagnostic tool with no output schema, the description provides a solid overview of what the tool returns (driver decomposition, magnitude, action hint). It could be slightly more explicit about the exact return structure or data scope, but overall it is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 three parameters thoroughly. The description adds no additional parameter-level meaning, which is acceptable because the schema descriptions are detailed (period ranges, account_id format with fallback).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('diagnoses') and clearly identifies the resource (Meta Ads campaign cost/CPA issues). It enumerates the specific drivers it attributes cost changes to, which distinguishes it from sibling analysis tools like meta_ads_analysis_performance or google_ads_cost_increase_investigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Use this when the operator reports why did CPA jump'. It also clarifies what the tool does—separating auction-side from creative-side causes—but does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly discloses 'Read-only — does not create creatives', which is the key behavioral trait. It also indicates a human-in-the-loop via 'after operator review', but does not mention any other side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is 4 sentences, front-loaded with the primary purpose and output. Examples are illustrative but not excessive, and the follow-up direction is concise. Every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description states 'Returns a ranked list of suggestions' and provides concrete examples, which sufficiently defines the return value. It also covers safety (read-only), follow-up steps, and parameter context via schema. Minor gaps like failure modes or empty results are not critical for a suggestion tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and all parameters are fully described in the schema (period with ranges, account_id with format, campaign_id). The description itself does not add parameter semantics beyond the schema, so it receives the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generates concrete creative-improvement suggestions for a Meta Ads campaign based on recent ad performance', clearly stating the action, resource, and output. It distinguishes itself from other analysis tools by focusing on creative suggestions and explicitly says 'Read-only — does not create creatives'. Examples of suggestions further clarify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states 'Follow up with meta_ads_creatives_create* to materialize the suggestions after operator review', providing an explicit next-step alternative. It also frames context as 'based on recent ad performance', which implies appropriate use cases. However, it does not explicitly contrast against other meta_ads_analysis_* tools, though the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly declares 'Read-only', lists the return fields, and implies the response includes linked ad_accounts. It does not mention error cases or permissions, but for a simple read operation this is adequate and adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action and return values; the second provides targeted usage guidance. Every word earns its place, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema or annotations, the description is quite complete for a simple get operation: it names the return fields, explains prerequisite context (catalog_id from list), and gives specific use cases. It stops short of a 5 because it does not mention potential error responses or the behavior when a catalog is not found, but for a read-only fetch this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both catalog_id and account_id clearly documented. The tool description adds no parameter-level details beyond the schema, but it reinforces the purpose via 'single Product Catalog' and references catalog_id being returned by meta_ads_catalogs_list. This matches the baseline 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetches' and a clear resource 'full detail record for a single Product Catalog', distinguishing it from catalog list tools. It lists the exact return fields (id, name, product_count, vertical, feed_count, owner_business_id, linked ad_accounts), making the tool's function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Call this before meta_ads_catalogs_delete or before building a Collection creative (meta_ads_creatives_create_collection) to verify product_count > 0.' This is clear context, but it does not explicitly mention when not to use it or compare it with alternative get tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool is read-only and details the data sources (/me/accounts and /me/businesses -> owned_pages). It also specifies the output fields. It lacks details on pagination, error conditions, or token scopes, but covers the essential behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: one for the action, one for the output, and one for the use cases. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description covers the tool's purpose, return fields, and usage context. It does not mention pagination or edge cases, but for a simple list tool it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the single parameter (account_id) with format, optionality, and fallback behavior. The description adds no parameter-specific information, and schema coverage is 100%, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Lists Facebook Pages the current access token can manage', with specific details about aggregating personal and business-owned Pages. It also names the return fields (id, name, category), making it unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to find a page_id before creating lead forms, boosting posts, or attaching a Page to an ad set's promoted_object', providing clear context. However, it does not mention when not to use it or name alternative tools, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses key behavioral traits: atomicity, single-entry limitation, and the return of the updated state document. It does not detail failure modes or permissions, but for a logging tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action and outcome. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex nested parameter schema, but the schema covers all parameter meanings. The description clearly states the return value ('Returns the updated state document') and when to use it. While it doesn't cover error conditions, the overall context is strong enough for an agent to operate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds only the phrase 'single action_log entry', which is marginally useful but not necessary. Baseline 3 is appropriate given the schema's richness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('append') and resource ('a single action_log entry to STATE.json'), with concrete use cases ('budget changes, campaign pauses, negative-keyword adds'). It clearly distinguishes this from sibling state tools by focusing on the action log append operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this whenever a workflow takes an action that should be evaluable later' and gives examples, providing clear usage context. It does not mention exclusions or alternatives, but the context is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the reversal call is re-dispatched through the same MCP handler, re-entering auth/rate-limiting/validation, and that on success a new action_log entry is appended with rollback_of=index. This is useful, but it does not mention failure behavior or return values, so it is not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences and packs in the operation, the re-dispatch behavior, side-effect, and a required parameter. Every clause serves a purpose with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description provides enough context for a rollback execution tool: what it does, its internal re-validation, side effects, and the confirm requirement. It lacks explicit return-value information or failure handling, but these are not essential for executing a rollback plan and are reasonably inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all three parameters (index, confirm, state_file). The description adds some context by tying index to action_log and emphasizing confirm=true, but it does not materially expand on the schema descriptions. This aligns with the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Execute the rollback plan for action_log[index].' This clearly identifies the verb (execute), the resource (rollback plan), and the target (the action_log entry at the given index). It also implicitly distinguishes itself from sibling tool rollback_plan_get, which likely creates or retrieves a plan rather than executing it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the trigger and requirement: 'Requires confirm=true.' It also explains that the call re-enters auth, rate-limiting, and validation, which implies it should be used when executing a previously generated rollback plan. However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly says 'Read-only' and describes what the tool returns (groups of duplicate criteria, spend, conversions, quality score, consolidation recommendation). It does not mention auth/permissions or rate limits, but for a read-only analysis tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences that front-load the action, then state the return value, then provide usage context. Every sentence adds value with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description adequately explains the return value ('groups of duplicate criteria with per-ad-group spend, conversions, and quality score, plus a consolidation recommendation'). Combined with the complete input schema, this is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents campaign_id, period, and customer_id with clear descriptions. The tool description does not add significant parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Finds the same text+match_type keyword appearing across multiple ad groups in a campaign.' It clearly distinguishes this from sibling tools like google_ads_keywords_list or google_ads_keywords_audit by focusing on cross-ad-group duplicate detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context: 'run this before a keyword restructuring sprint' and explains why duplicates are problematic ('compete in the auction and hurt aggregate quality score'). It doesn't name specific alternatives or when-not conditions, but the use case is clear and well-situated among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for disclosing behavioral traits. It explicitly states 'Read-only; no mutation,' which is the most critical behavioral safety factor. It also describes the return shape in detail, including the exact structure of the metrics object. However, it does not mention potential edge cases like empty results, data freshness, or required permissions. Still, the explicit read-only declaration and detailed output shape provide strong transparency for a read-only aggregation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than some but every sentence contributes value: it states the action, the return shape (with metrics list), the read-only trait, and the alternatives. The information is front-loaded with the core purpose. It could be slightly tighter by omitting the metric list (since no output schema exists, that list is valuable), so it remains well-structured and not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description compensates by fully specifying the return structure (one row per campaign with a nested metrics object listing all fields). It also provides usage context and alternatives. The schema covers parameter details. The only missing piece is potential error/edge-case behavior, but for a read-only reporting tool this is not critical. Overall, the description is sufficiently complete for an agent to understand what the tool does and what it returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% and each parameter has a detailed description: 'period' explains the default and usage guidance, 'campaign_id' explains filtering vs. aggregation, and 'customer_id' explains the fallback behavior. The tool's description itself does not add further parameter semantics beyond what the schema already provides. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: aggregate campaign-level performance metrics for a Google Ads account. It uses a specific verb ('Aggregate') and names the resource ('campaign-level performance metrics'). It explicitly distinguishes itself from sibling tools by naming google_ads_ad_performance_report, google_ads_network_performance_report, google_ads_search_terms_report, and google_ads_conversions_performance, making it unmistakable which tool to choose for campaign-level totals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
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 for campaign-level totals.' It then lists clear alternatives for other use cases (per-ad, network splits, search terms, conversion actions). Additionally, the schema description for the 'period' parameter recommends shorter windows for recent changes and longer windows for trend baselines. This is exemplary differentiation and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses critical behaviors: it is mutating, reversible only by google_ads_sitelinks_remove using the returned asset_id, enforces a hardcoded limit of 20 sitelinks per campaign, returns a specific error format, and creates duplicate assets on repeated identical calls. This goes beyond the minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences covering purpose, process, return values, error conditions, limit, reversibility, and duplication. It is front-loaded with the main action and has no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description is remarkably complete: it explains the two-step service flow, success and error return shapes, the per-campaign limit, how to reverse the operation, and the duplicate-asset risk. Combined with rich schema descriptions, the context is fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no extra parameter-level details beyond what's in the schema, which is acceptable given the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Create a sitelink Asset and link it to a Google Ads campaign' with a specific verb and resource. It distinguishes from sibling tools like google_ads_sitelinks_list and google_ads_sitelinks_remove by describing the creation flow and the two-step mutate process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating sitelinks but does not explicitly state when to use it versus alternatives like callouts_create. It does mention google_ads_sitelinks_remove for reversal, which is a relevant alternative, but lacks 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It clearly explains the state change to ACTIVE, the prerequisite condition, the returned values (ad_id and new status), and that the operation is reversible. It doesn't mention auth or error behavior, but this is adequate for a simple state-change tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no filler or redundant information. Every sentence contributes useful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers purpose, prerequisites, return values, and reversibility. 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for both ad_id and account_id. The description doesn't add parameter semantics beyond the schema, but it doesn't need to because the schema already documents each parameter well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 resumes a paused ad by setting its status to ACTIVE. It specifies the resource (ad) and distinguishes itself from pause/enable operations on parent ad sets or campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context by noting the parent ad set and campaign must also be ACTIVE for the ad to serve. It also names reversal paths (rollback_apply or meta_ads_ads_pause), but doesn't explicitly contrast with meta_ads_ad_sets_enable or meta_ads_campaigns_enable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the safety disclosure burden by clearly stating 'Read-only.' It also explains behavioral context ('same targeting, same budget') and describes the output structure, adding meaningful transparency beyond the absent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose, followed by output details and usage guidance. No redundancy or filler—every sentence contributes valuable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description compensates by detailing the return fields (impressions, spend, conversions, CPA, CTR, relative-score, verdict). Combined with rich schema descriptions and an explicit read-only statement, the description is sufficient for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with detailed descriptions for all three parameters. The tool description adds no new parameter-specific semantics, only restating the ad_set_id scope that is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Runs an A/B-style comparison of ads inside a single ad set,' specifying the exact verb and resource scope. It distinguishes itself from sibling analysis tools by focusing on intra-ad-set comparison and producing verdicts like winner/laggard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use case: 'Use this to decide which creatives to pause' and pairs with meta_ads_ads_pause for action. However, it does not explicitly name an alternative analysis tool for cross-ad-set comparisons, though the scope restriction ('inside a single ad set') implies a boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses that the operation is read-only and adds a meaningful caveat about approximate counts lagging by 24–48 hours. It does not mention authentication, rate limits, or pagination behavior, but the essentials are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the primary action and return fields. Every sentence adds value, and the usage hint is placed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter list tool without an output schema, the description is complete: it names the resource, lists return fields, provides the primary use case, and notes the data freshness caveat. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the two parameters are already fully documented in the schema. The description repeats the limit default and account_id fallback but adds no new parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Lists Custom Audiences in a Meta Ads account.' It also enumerates the returned fields and clearly distinguishes this list operation from related audience tools like meta_ads_audiences_get, create, or delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: to find an audience_id before targeting an ad set or creating a lookalike. It names the dependent tools but does not explicitly mention when not to use it or name alternative list/get tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavioral traits. It does so effectively: 'Mutating — not automatically reversible; record before-state with mureo_state_action_log_append if you may need to roll back.' It also states the return value ('Returns the new catalog_id'), providing important behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, and every sentence adds value: purpose, return value, mutation warning, and follow-up tool guidance. There is zero fluff or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema or annotations, the description is remarkably complete. It covers what the tool does, what it returns, the mutation risk with a rollback strategy, and how to proceed after creation (adding products or creating feeds). This is everything an agent needs to confidently invoke and integrate this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add additional meaning to the parameters beyond what is already in the schema. It indirectly references business_id ('under a Meta Business') but provides no extra parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource: 'Creates a new Product Catalog under a Meta Business.' It also distinguishes itself from sibling tools by explaining that a catalog is the container and that products are added via meta_ads_products_add or meta_ads_feeds_create. This clearly identifies the tool's unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: to create a new catalog before adding products. It explicitly mentions alternatives for the next steps ('add products individually via meta_ads_products_add, or schedule bulk imports via meta_ads_feeds_create'). It does not explicitly state exclusions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly states 'Read-only' and lists the returned fields, which informs the agent of the safe, non-mutating behavior. However, it does not mention error handling or permission requirements, a minor gap for a simple get.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no waste. The first sentence states purpose and returns fields; the second provides a concrete usage scenario. It is front-loaded and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-resource get tool, the description is complete: it lists the return fields, states the read-only behavior, and gives a practical use case. With no output schema, the explicit return field list compensates. Parameter semantics are fully covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with descriptions for both parameters, including the fallback behavior of account_id. The tool description does not add meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches the full detail record for a single Meta Pixel, naming multiple specific return fields. It distinguishes itself from sibling tools like meta_ads_pixels_list by focusing on a single pixel's full detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to call it: to verify pixel setup before diagnosing conversion tracking issues or relying on the pixel for audience rules. It does not mention explicit alternatives or when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses 'Read-only' behavior, lists enum values for review_status, and explains that rejected products are excluded from ads. It does not mention rate limits or auth needs, but the key behavioral aspects are covered clearly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and return fields, and the second sentence gives a practical use case. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation with one required parameter and no output schema, the description is comprehensive. It lists all return fields, notes conditional fields, states read-only, and provides a troubleshooting context. This is fully adequate for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and both parameters have detailed descriptions in the schema. The description does not add parameter-specific details beyond noting that product_id is the Meta-assigned ID and not retailer_id, which is already in the schema. The return field list adds value but not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it fetches the full detail record for a single catalog product, which is a specific action on a specific resource. It lists the returned fields and differentiates from sibling tools like meta_ads_products_list or meta_ads_products_update by emphasizing 'single' product and 'full detail record'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit when-to-use instruction: 'Call this when DPA delivery stalls for a specific product to check review_status.' It gives clear context for use but does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It explicitly states 'Read-only' and discloses the default limit (100) and maximum (1000), plus the list of returned fields. It does not mention pagination cursors or behavior for missing products, but for a simple read-only list tool these omissions are minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose ('Lists products in a Product Catalog'), then providing return fields, read-only note, limits, and use cases. Every phrase earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, 1 required) and the schema documents all parameters. The description adds purpose, output fields, read-only behavior, limits, and practical use cases. Given no output schema, listing the returned fields is sufficient. It also cross-references a sibling tool (meta_ads_creatives_create_collection), making the context complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 limit default/maximum but adds no information about catalog_id or account_id beyond what the schema already provides. It mentions returned fields, which are output semantics, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lists products in a Product Catalog.' It enumerates the exact returned fields (id, retailer_id, name, availability, price, image_url, brand, category), which clearly distinguishes it from sibling tools like meta_ads_products_get, meta_ads_products_add, or meta_ads_products_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states concrete use cases: 'Use this to locate product_ids for use in meta_ads_creatives_create_collection or to audit feed health.' This gives clear context for when to call the tool. It does not explicitly describe when not to use it or name an alternative like meta_ads_products_get, so it stops short of a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'Atomically upsert', persistence of metrics for dashboard KPIs, and ad-level delivery status for diffing on the next run. It does not detail every side effect, but covers key behavioral aspects beyond a simple 'write' operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long and front-loads the core action. Each sentence adds meaning—purpose, metrics, ads—with no waste. It is slightly longer than necessary but remains efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (nested objects, optional fields) and the rich input schema, the description is largely complete. It does not describe return values (there is no output schema), but for a state-upsert tool, that is arguably minor. The inclusion of use cases and optional field semantics makes it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and provides detailed descriptions for all parameters. The description adds extra semantic context for the 'metrics' and 'ads' parameters, explaining their purpose in persisting KPIs and recording external pauses, which goes beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Atomically upsert a CampaignSnapshot into STATE.json (root campaigns array)', naming the resource (STATE.json), the action (upsert), and the scope (root campaigns array). It distinguishes itself from sibling mureo_state_* tools by specifying campaign snapshots specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: 'Use this to keep STATE.json in sync with campaign metadata changes the agent observes via vendor MCPs or BYOD imports.' This tells the agent when to invoke it, though it does not name alternatives or 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses important behaviors: no text is rendered, output file naming convention, validation, and return values (path, SHA-256, provider). This goes beyond minimal expectations, though it could add details about permissions or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences front-load the purpose and pack in essentia output details without fluff. Every phrase earns its place, from 'art-direction loop' to the file naming pattern and return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with 3 params and no output schema: it explains purpose, input semantics, output behavior, and return values. Missing minor aspects like error handling or prerequistites, but overall sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions, so baseline is 3. The description adds value by clarifying that the instruction describes imagery change ONLY and no text is rendered, which is not fully captured in the schema's 'What to change about the imagery'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool refines an existing key visual via an image provider's edit path, with a specific verb ('Refine') and resource. It distinguishes from sibling 'creative_studio_generate_visual' by emphasizing editing an existing visual and mentions the art-direction loop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: use for fixing weak visuals in an art-direction loop, implying it's for editing after generation. However, it does not explicitly name alternative tools (like generate) or state when not to use it, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Declares 'Read-only' which is critical since no annotations exist. Lists exact return fields (id, name, campaign_id, status, type, cpc_bid_micros, ad_rotation_mode). Does not mention pagination or auth fallback but sufficient for basic list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear front-loading: main action, scoping/filter options, return fields, and usage guidance. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple list tool: explains purpose, usage, and return schema. Lacks pagination/result limit details but that's a minor gap given no output schema and simple optional filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions for all three optional params, so description adds little beyond restating optional scoping and status filtering. Baseline 3 is appropriate; no meaningful new param context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists ad groups with optional scoping/filtering. Differentiates from related tools by explicitly pointing to ads.list for direct fetch and create/update for needing an ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: to locate ad_group_id before create/update calls. Also says when not to: if you already have the id, fetch directly via ads.list filtered by ad_group_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 return shape ('Returns one row per ad shaped as...'), the read-only nature ('Read-only; no mutation'), and filtering capabilities. It does not mention pagination, rate limits, or error conditions, but for a read-only report this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and every sentence adds value: purpose, return shape, filtering, safety, and alternatives. It is front-loaded with the core purpose and structured logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by specifying the exact row shape and metric list. It covers filtering, safety, and distinguishes from related tools. The only minor gap is lack of sorting/pagination behavior, but that is not critical for a report with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with well-described parameters. The main description adds only 'Filterable by ad_group_id and/or campaign_id (both optional, both numeric)', which largely restates the schema. It provides no additional syntax or format details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Report per-ad performance across Google Ads ad_group_ad rows', using a specific verb and resource. It also distinguishes from siblings by explicitly naming google_ads_ad_performance_compare and google_ads_performance_report for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides when-not and alternatives: 'For ENABLED-only A/B comparison within a single ad group with WINNER/LOSER verdicts use google_ads_ad_performance_compare; for campaign-level aggregates use google_ads_performance_report.' It also notes read-only and filterable by optional IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly states 'Mutating — not automatically reversible' and mentions return values (resource_name, id, initial approval_status) along with the typical approval timeline. It stops short of detailing error scenarios or prerequisites, but the critical mutation risk is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a distinct purpose: purpose, return info, mutation warning + rollback, and format requirements + alternative. The description is front-loaded with the primary action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description compensates by naming return fields and approval status. It also covers the rollback context and differentiates from the display ad tool. It relies on the fully covered schema for parameter details, which is acceptable, though it leaves out error behavior and authentication prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes 100% of parameters with rich detail, so the baseline is 3. The description repeats headline/description counts but does not add new parameter semantics beyond what the schema provides. It mentions return values, which are not parameter-related, so it does not raise the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a Responsive Search Ad (RSA) in the specified ad group', providing a specific verb, resource, and container. It explicitly names the sibling alternative 'google_ads_ads_create_display' for display/banner ads, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear when-to-use guidance: it states the RSA format requirements (3–15 headlines, 2–4 descriptions), points to 'google_ads_ads_create_display' as the alternative for display ads, and advises using 'mureo_state_action_log_append' for rollback. This covers both selection and pre-call steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and explicitly states 'Read-only,' which is a key behavioral trait. It also discloses the output shape (one entry per criterion, including fields and type enum values) and the 1000-criteria cap. It could add more about auth requirements or pagination behavior, but the current disclosure is strong for a 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it defines the resource, enumerates audience types, gives the return shape with an example, states read-only status, provides a concrete use case, and explains scoping. It is front-loaded with the action and remains information-rich without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates well by including the exact returned fields and value format (e.g., 'customers/1/userLists/42'). It covers the read-only nature, scoping, and cap. Minor omissions like pagination details or error behavior prevent a perfect score, but given the tool's list-only purpose, this is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with per-parameter descriptions, so the baseline is 3. The description adds valuable semantics by explaining the optionality and behavior of omitting both ad_group_id and campaign_id: 'omit both for the whole account (capped at 1000 criteria).' This enriches the parameter guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Lists audience-type criteria attached to ad groups,' and enumerates the exact types of audiences covered (user interests, remarketing, custom audiences, etc.). This clearly differentiates it from sibling targeting-list tools like google_ads_location_targeting_list or google_ads_demographic_targeting_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to audit which audience segments an ad group targets or excludes before proposing targeting changes.' It also explains how to scope results (by ad_group_id and/or campaign_id, or omit for whole account). It does not explicitly name alternative tools for non-audience targeting, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: read-only, per-campaign data sourced from get_performance_report, silent failure handling as zero, and verdict thresholds. It does not mention auth requirements or edge cases like zero enabled campaigns, but it goes well beyond a basic action statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then compacts return structure, failure handling, read-only status, and alternatives into a dense but efficient text. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The return object is fully specified, including exact field names and verdict logic, along with data source, failure handling, and read-only nature. Minor gaps exist (e.g., behavior when no campaigns are enabled), but for a read-only analysis tool with no annotations or output schema, this is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are thoroughly described in the schema (period default and use cases, customer_id format and fallback). The description itself adds no extra parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Score') and resource ('budget allocation efficiency across every ENABLED Google Ads campaign'), clearly distinguishing this from sibling tools like google_ads_budget_reallocation and google_ads_budget_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'For a concrete DECREASE/INCREASE reallocation plan use google_ads_budget_reallocation; to change a single budget use google_ads_budget_update.' The schema also advises on period selection for different diagnostic needs, so the tool can be used correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though no annotations are provided, the description explicitly states 'Read-only' and explains the return field set relative to campaigns.list. It doesn't detail error behavior or rate limits, but for a read-only get operation, this is adequate behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the main purpose, adds return field details, and closes with usage guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with no output schema, the description is fairly complete. It specifies the additional fields over campaigns.list, notes read-only behavior, and gives usage context. Minor gap: it doesn't list all fields from campaigns.list, but leveraging sibling knowledge is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already fully described. The description repeats some of that information (e.g., campaign_id from campaigns.list, customer_id fallback) but doesn't add significant new meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Fetches the full detail record for a single campaign by ID.' It also distinguishes itself from sibling tools by listing additional fields returned and explicitly contrasting with google_ads_campaigns_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this when you already have a campaign_id; for discovery use google_ads_campaigns_list.' This clearly indicates when to use this tool vs the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states 'Read-only,' which is a critical safety indicator, and describes the exact return shape including fields like id, name, type, file_size, mime_type, dimensions, and URL. While it doesn't discuss pagination or error cases, the core behavior is transparent and enriched beyond a simple 'lists assets' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, but the first sentence is dense with an inline object shape. The information is well-organized and every part earns its place, including the explicit read-only flag and usage guidance. It is not overly verbose, though the embedded object could be slightly more readable. Overall, it is an efficient and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with 2 optional parameters and no output schema, the description is complete. It covers purpose, output shape, read-only nature, and use cases. The absence of an output schema is compensated by the explicit return structure, and the limit parameter's behavior is documented in the schema. No critical information is missing for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning both parameters (limit, customer_id) already have descriptions in the schema. The tool description does not add additional meaning beyond what the schema provides, so the baseline of 3 applies. It mentions dimensions in the output but does not discuss parameter syntax or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it 'Lists image assets in the Google Ads account with their names and dimensions,' which is a specific verb+resource combination. It clearly distinguishes from sibling tools like google_ads_ads_list (lists ads) and google_ads_assets_upload_image (uploads assets) by focusing on image assets and mentioning 'instead of re-uploading duplicates via google_ads_assets_upload_image.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases: 'Use this to find an existing asset id/name before referencing it in a Responsive Display Ad, or to audit what imagery the account already has.' It also names the alternative tool (google_ads_assets_upload_image) and when to avoid it ('instead of re-uploading duplicates'), 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so admirably. It explicitly states 'Read-only — recommendations are not applied,' which is a critical behavioral disclosure. It also reveals the structure of the return (grouped recommendations with specific fields like criterion_id, text, spend, conversions, reason), going beyond mere read-only to explain what the user can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, consisting of four sentences that each serve a distinct purpose: what the tool does, what the output contains, read-only nature, and how to act on results. It is front-loaded with the core purpose, uses minimal fluff, and avoids repeating schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description appropriately explains the return value: grouped recommendations and item fields. It gives enough detail for an agent to understand the shape and purpose of the result. However, it does not mention potential edge cases like empty results, limits on the number of recommendations, or whether all groups are always present, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage, describing each parameter (campaign_id, period, target_cpa, customer_id) with defaults and fallback behavior. The description adds no additional meaning about parameters beyond what the schema provides; it only references 'target_cpa' in passing, which is already described. The baseline of 3 is correct because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('runs a holistic keyword-portfolio audit') and clearly identifies the resource and outcome ('returns grouped recommendations'). It enumerates distinct recommendation types (pause, bid-raise, match-type-tighten, unused planner ideas), which distinguishes it from sibling tools like google_ads_keywords_diagnose or google_ads_keywords_suggest.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is an audit tool meant to generate recommendations, not apply them. It explicitly directs the user to materialize accepted recommendations via other tools (google_ads_keywords_pause, add, negative_keywords.add), implying when this tool should be used (before applying changes). However, it does not explicitly name alternative audit tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden, and it explicitly discloses the key trait: 'Read-only — produces ideas but does not add anything to the account.' It also lists the return fields, which is useful. It does not mention potential rate limits or auth requirements, but the most important non-obvious behavior (no side effects) is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding distinct value: what the tool does, what it returns, and important behavioral/alternative guidance. No unnecessary words or repetition; it is well-structured and front-loaded with the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the essential context: it names the API, lists return fields, and states the read-only nature. Since there is no output schema, the return-field list is helpful. It does not mention result count limits or pagination, but these are not critical for a suggestion tool. Overall, it is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add meaning beyond the schema: it mentions 'seed terms' but does not elaborate on parameter formats, defaults, or constraints beyond what is already in the input schema. No compensation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Generates new keyword ideas from seed terms using the Google Ads Keyword Planner API.' It uses a specific verb ('generates') and resource ('keyword ideas'), and distinguishes itself from siblings like google_ads_keywords_add and google_ads_keywords_list by explaining it only produces ideas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use this tool versus alternatives: 'Read-only — produces ideas but does not add anything to the account. Use google_ads_keywords_add to materialize the ones you want.' This directly names the sibling tool for the follow-up action and clarifies the read-only nature, providing clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden. It discloses that the operation is mutating, not automatically reversible, and advises recording prior state for rollback. It also mentions the return value. This is strong for a mutation tool, though it omits specifics like required permissions or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core action, and every sentence adds unique value (scope, return, rollback, preference). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple add operation with no output schema, the description covers essential context: scope, return value, mutation warning, and rollback guidance. It lacks nothing critical for an agent to decide and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no new parameter-level details beyond what is already in the schema, but that is acceptable since the schema is fully self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Adds one or more ad group-level negative keywords.' It distinguishes from campaign-level negatives and references the sibling tool by name, making the resource and scope explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit decision guidance: 'Prefer this over google_ads_negative_keywords_add when the exclusion is only wrong in one ad group's context.' Also states the scope is narrower than campaign-level negatives, helping with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It declares the operation as read-only and outlines the returned fields, while also clarifying the scope limitation. It lacks details about pagination or edge cases, but for a simple list operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: first states the action and scope, second lists return fields, third clarifies an important exclusion. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 states the return fields. Combined with complete parameter schema and clear scope, this covers all essential context for a list tool. Slight gaps remain about fallback behavior for customer_id and empty-result handling, but these are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters include descriptions in the schema. The tool description does not add additional semantic context for the parameters, relying fully on the schema definitions. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Lists') and resource ('campaign-level negative keyword criteria for a single campaign'), and explicitly distinguishes itself from ad group-level negatives. It also enumerates the returned fields, making its function unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly states it applies to a single campaign and explicitly excludes ad group-level negatives, directing users to the appropriate sibling tool (google_ads_negative_keywords_add_to_ad_group). 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses mutation, non-reversibility, and suggests recording before-state with mureo_state_action_log_append. It also reveals the default initial status and return value. However, it does not mention error behavior or permission requirements, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover purpose, return value, mutation warning, default status, and creative prerequisite. It is front-loaded with the primary action and efficient with no redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5-parameter create operation, no output schema, and no annotations, the description covers the key aspects: what it does, prerequisites, return value, and mutation implications. It lacks some operational details like failure handling, but is complete enough for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are already well-documented. The description adds context about the creative prerequisite and default status, but mostly reinforces schema details rather than introducing new semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new ad inside an existing ad set and binds it to a pre-existing creative, returning the new ad id. This specific verb+resource+scope distinguishes it from sibling creation tools like meta_ads_campaigns_create and meta_ads_creatives_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the user to first create a creative using meta_ads_creatives_create or sibling constructors, establishing a clear prerequisite and alternative. It also notes the default PAUSED status, giving contextual guidance on when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses that the operation is mutating and not automatically reversible, advises logging for rollback, and clarifies the default initial status (PAUSED) and when ACTIVE is allowed. This goes beyond the schema and informs the agent of important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, front-loaded with the core action and return value, followed by the mutation warning, targeting requirement, status default, and next step. Each sentence contributes distinct, useful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 12 parameters and no annotations or output schema, the description provides a complete high-level picture: creates an ad set in an existing campaign, requires key targeting fields, default status behavior, rollback guidance, and the follow-up step. It doesn't enumerate every parameter interaction, but the schema already does that, so the description fills the contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with rich descriptions, so baseline is 3. The description adds meaningful extra guidance by stating that targeting must include at least geo_locations and age bounds, and by explaining the default status behavior. This is sufficient to elevate the score above the schema-only baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action with verb and resource: 'Creates a new ad set inside an existing campaign' and specifies the return value ('Returns the new ad_set id'). It differentiates from sibling tools like meta_ads_ad_sets_update and meta_ads_ads_create by focusing on creation and noting the follow-up to attach ads with meta_ads_ads_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear workflow context: when creating an ad set in an existing campaign, default status is PAUSED, and then attach ads with meta_ads_ads_create. It also advises recording before-state with mureo_state_action_log_append for rollback. However, it does not explicitly contrast with meta_ads_ad_sets_update or list when-not conditions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses read-only behavior, lists returned fields, and explains that issues_info is non-empty when the ad set is not delivering. This is useful behavioral context, though it omits error handling or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first front-loads the purpose and returns a comprehensive field list; the second gives actionable usage guidance. Zero filler, perfect structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by enumerating return fields and explaining the special meaning of issues_info. It also provides workflow context with the update tool. Slightly incomplete regarding error scenarios, but for a read-only get operation this is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions for ad_set_id and account_id (including format and fallback). The description adds no parameter-specific meaning, but none is needed given the schema's completeness. Meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetches the full detail record for a single ad set' with a specific verb and resource, enumerating key fields. This distinguishes it from sibling tools like meta_ads_ad_sets_list, meta_ads_ad_sets_update, and pause/enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this before meta_ads_ad_sets_update when modifying targeting, providing rationale (merge instead of overwrite). Names the alternative tool and specifies the context, going beyond generic 'use when you need details'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full transparency burden. It discloses read-only nature, explains the semantics of 'status' vs 'effective_status' (including pausing applied outside mureo or inherited), and clarifies that missing issues_info means nothing reported, not a cleared check. This is strong behavioral context, though it omits details like pagination behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense but well-structured block; each sentence adds value—list scope, return fields, status semantics, read-only note, and usage guidance. It is longer than the minimal viable description but avoids fluff and front-loads the core purpose. Slight over-packing prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values, which it does thoroughly: lists returned fields, distinguishes status from effective_status, and clarifies issues_info/ad_review_feedback semantics. It also covers the optional scoping and provides next-step tools, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description reinforces the optionality of ad_set_id and the fallback behavior of account_id, but does not add substantial meaning beyond the schema's own parameter descriptions. The 'limit' parameter is explained in the schema with defaults and caps, and the description adds no new syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb-resource pair ('Lists ads in a Meta Ads account') and clearly distinguishes from siblings by noting optional scoping to one ad set and by directing users to meta_ads_creatives_list for creative details. It also differentiates the list behavior from ad-specific tools like update/pause/get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool: 'Use this to find an ad_id before calling ads.update / pause / enable, or to audit which creatives are in flight.' It also provides an alternative for creative content ('For the creative itself... follow up with meta_ads_creatives_list'), making the usage context and exclusions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Read-only,' which is a key behavioral trait, and describes the output shape: rows per age_range × gender with spend/conversions/CPA and recommendations array with example. It doesn't mention potential data-quality caveats or that it may return empty results for small campaigns, but the read-only declaration and output details provide solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tight and well-structured: it opens with the core purpose, lists the output metrics and recommendations example, states read-only status, and ends with usage guidance and a named alternative. Every sentence adds value; no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool with no output schema, the description explains what the return data contains (rows, fields, relative_score, recommendations) and includes a concrete example. It also contextualizes when to use it (before targeting adjustments). It could mention limitations (e.g., requires enough delivery data) but is complete enough for typical selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, including period formats, account_id fallback, and required campaign_id. The description adds no additional parameter-specific semantics beyond what the schema already provides. Baseline of 3 is appropriate since the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'Scores delivery efficiency across age × gender segments and flags the best and worst performing buckets.' It names the specific analysis dimension (age×gender), the comparison metric (relative_score vs campaign average), and produces a recommendation array. This is distinct from sibling tools like meta_ads_insights_breakdown, which provides raw numbers, and other analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use before adjusting targeting' and directly names the alternative 'for raw breakdown numbers use meta_ads_insights_breakdown with breakdown="age,gender".' This clearly tells the agent when to choose this tool and when to choose another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and discloses that the tool is read-only, which is a key safety trait. It also describes specific return field additions and the behavior of issues_info (non-empty when status is WITH_ISSUES), adding meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, return differences, read-only nature, and usage guidance without redundant filler. All sentences carry substantive value and are front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-record fetch tool, the description sufficiently explains what is returned (same fields as list plus specified extras) and when to use it. It does not enumerate all list fields, but references campaigns.list, and the lack of an output schema is partially compensated by this cross-reference. Minor omissions like error behavior are acceptable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage, with both parameters (campaign_id and account_id) fully documented, including format and fallback behavior. The description adds minimal new parameter-specific info; it references campaign_id being 'already known' but does not expand beyond the schema's existing detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Fetches the full detail record for a single campaign by ID', specifying both the action and resource. It distinguishes itself from list tools by noting it returns additional fields beyond campaigns.list, and names the specific sibling meta_ads_campaigns_list for discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides usage direction: 'Use this when a campaign_id is already known; for discovery use meta_ads_campaigns_list.' This directly tells the agent when to choose this tool over the list alternative, satisfying the when/when-not criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses mutating behavior, non-reversibility, and suggests mureo_state_action_log_append for rollback. It also explains partial update and return value. Lacks permission/rate-limit details, but covers the core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, each earns its place: purpose, partial update, return value, mutation warning with rollback suggestion, and sibling alternatives. Zero redundancy and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Combined with the schema, the description covers purpose, mutation, rollback, alternatives, and return value. It doesn't mention error cases or permissions, but the schema thoroughly documents parameters and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters have schema descriptions (100% coverage). The description adds only general partial-update semantics already implied by the schema, so no additional parameter-level value; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates fields on an existing campaign', giving a specific verb and resource. It also distinguishes from sibling tools by noting partial update behavior and explicitly directing status-only transitions to meta_ads_campaigns_pause/enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance (updating fields) and when-not-to-use (status-only transitions prefer pause/enable tools). It also advises recording before-state for rollback, offering clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only,' which is a key behavioral trait, and describes the return payload (id, name, product_count, vertical, feed_count). However, it does not mention pagination, rate limits, permission requirements, or error behavior, which would provide fuller transparency for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of two sentences. The first sentence states the action and return fields; the second provides usage context. Every word adds value, and the structure is front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema, no annotations), the description covers the essential aspects: what it lists, what it returns, and when to use it. It could benefit from a mention of pagination or limits, but it is sufficiently complete for a straightforward list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters documented in detail (e.g., account_id format and fallback, business_id ownership). The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Lists'), the resource ('Meta Commerce Catalogs'), and the scope ('owned by a Business'). It also distinguishes itself from sibling tools by explicitly mentioning its role in finding a catalog_id before calling meta_ads_catalogs_get / delete or managing products/feeds, 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.
Usage Guidelines5/5
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 to find a catalog_id before calling meta_ads_catalogs_get / delete or managing products / feeds underneath.' It also labels the tool as 'Read-only,' implying it should not be used for mutations. This clearly frames its place among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly notes 'Mutating on Meta's side — events become part of the pixel's attribution stream' and describes the return format ('events_received and messages'). This transparently conveys the side effects of the mutation, though it could mention permission requirements or rate limits, which are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and includes essential guidance (alternatives, mutation, response). Every sentence earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (batch events, nested objects) and no output schema, the description effectively covers purpose, usage guidance, mutation side effects, and return values. It lacks explicit error-handling details or auth requirements, but the rich input schema compensates for parameter-level completeness, and the overall context is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds high-level context about using the tool for arbitrary event names and mentions the response structure, but it does not add param-level semantics beyond the schema. It correctly avoids redundant repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Sends a batch of arbitrary conversion events to the Meta Conversions API' with a specific verb and resource. It distinguishes itself from sibling tools by explicitly naming dedicated helpers (meta_ads_conversions_send_purchase, send_lead) for common event types, making its purpose as a generic fallback unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'For common event types prefer the dedicated meta_ads_conversions_send_purchase or send_lead helpers... For other event names (AddToCart, InitiateCheckout, CompleteRegistration, custom events) use this generic tool.' This clearly states when to use this tool versus alternatives, with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly discloses that the tool is 'Mutating on Meta's side' and states the return value: 'Returns Meta's events_received acknowledgement.' This is solid transparency, though it doesn't cover rate limits, idempotency, or auth prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with action and return value, then usage context, then sibling differentiation. Every sentence earns its place with zero redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential context: what it does, that it's mutating, what it returns, when to use it, and how it differs from related tools. No output schema exists, but the return value is described. Some minor aspects like error handling or rate limits are absent, but overall it's sufficiently complete given the rich schema and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with rich per-parameter details (e.g., hashing behavior in user_data, act_ prefix requirement for account_id). The description itself adds no parameter semantics beyond what's in the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Sends a single Lead event via the Meta Conversions API') and clearly distinguishes from siblings by mentioning meta_ads_conversions_send_purchase and meta_ads_conversions_send for other event types. This leaves no ambiguity about the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('form submissions, trial signups, demo requests') and explicitly redirects to alternatives: 'For money-moving events use meta_ads_conversions_send_purchase. For non-standard event names use meta_ads_conversions_send.' This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly and explicitly discloses that the operation is 'Mutating on Meta's side' and describes the return value as 'Meta's events_received acknowledgement.' It also discloses important client-side behavior: mureo hashes PII fields with SHA-256 before sending and instructs users not to pre-hash. This goes beyond typical descriptions, though it omits details like error handling 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose + return value, mutation statement, and alternative guidance. No filler, front-loaded, and highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 9 parameters and no output schema, the description covers the core return acknowledgement, mutation type, and sibling differentiation. The detailed schema descriptions handle parameter semantics, making the overall package complete for an agent to select and invoke the tool correctly. A small gap is the absence of explicit error handling or fallback behavior, but this does not compromise primary usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already provides full semantics for all 9 parameters. The description adds no additional parameter-level meaning beyond a general note that 'required fields model a typical purchase' and that user identifiers are hashed (which is also in the schema). This meets the baseline for schema-rich tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Sends a single Purchase event via the Meta Conversions API.' It also distinguishes itself from siblings by naming meta_ads_conversions_send_lead and meta_ads_conversions_send for other event types, making its scoped purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames when to use this tool ('the most common CAPI use case') and provides clear when-not guidance: 'For other event types use meta_ads_conversions_send_lead (leads) or the generic meta_ads_conversions_send (AddToCart / custom events / batching multiple events).' This is an explicit alternative recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only', which is a key behavioral trait, and describes the return structure (rows with specific metrics). It does not disclose quota usage or error behavior, but the schema covers quota notes. It adds enough beyond a bare description to be transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by return details and a clear usage/caveat note. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explicitly lists the return metrics and aggregation levels, giving the agent a solid understanding of what to expect. It also provides usage context and a sibling alternative. It is slightly thin on input edge cases (e.g., defaults for period), but the schema covers those. Overall, it is well-rounded for a reporting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add significant new parameter semantics beyond the schema; it restates the aggregation level and the one-campaign/whole-account choice, both already in the schema. No additional syntax or format details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it pulls raw delivery metrics from Meta Graph API Insights for one campaign or the whole account. It specifies the exact metrics returned and the aggregation levels, and explicitly distinguishes itself from the sibling tool meta_ads_analysis_performance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance: 'Use this when you need raw metrics' and contrasts with the alternative 'for interpreted findings... use meta_ads_analysis_performance instead.' This clearly directs the agent to the appropriate tool for different needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description states 'Read-only' to disclose the safety profile and lists the exact return fields. While it doesn't cover auth, rate limits, or edge cases, the read-only note and field list offer meaningful behavioral transparency beyond structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, then lists returns and usage. Every clause earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers purpose, return fields, and usage flow in sequence. The only minor gap is the vague '.boost' reference instead of the full sibling name 'meta_ads_instagram_boost', but the context is still understandable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter (account_id) with format, example, and fallback behavior at 100% coverage. The description adds no parameter-level detail beyond what the schema provides, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb and resource: 'Lists Instagram Business / Creator accounts linked to the ad account via Meta Business.' It also differentiates from siblings by focusing on account discovery rather than media or boosting, and explicitly mentions the returned fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this to find an ig_user_id before calling meta_ads_instagram_media or .boost.' This names the alternatives and gives a clear sequencing directive, distinguishing it from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states 'Read-only' and discloses the 90-day data retention policy, adding valuable behavioral context beyond the schema. It lacks details on pagination or rate limits, but for a simple read tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: main action, return fields, usage guidance, alternative, and a retention warning. Every sentence contributes value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description lists the key return fields and explains the field_data structure. It covers purpose, usage, alternatives, and a caveat. Minor gaps remain around pagination behavior, but the limit parameter is documented, making it complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters, so the description does not need to explain them. The tool description adds no parameter-specific semantics, and the baseline of 3 is appropriate since the schema already handles it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves submitted leads for a single form, with a specific verb and resource. It lists the return fields and explicitly distinguishes it from the sibling tool meta_ads_leads_get_by_ad, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this for batch CRM sync or retrospective analysis' and names an alternative tool for ad-filtered leads. The 90-day retention warning also informs when to use it regularly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It explicitly states 'Read-only' and clarifies the return shape ('same lead record shape as meta_ads_leads_get'). It does not discuss pagination or rate limits, but the schema already describes limit behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: first states the action and scope, second asserts read-only safety, third gives use case and alternative. Every sentence adds value and the key verb is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by referencing meta_ads_leads_get for the record shape. The param schema is complete, and the use case is explicit. It could mention pagination explicitly, but this is a minor gap for a straightforward read-only fetcher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for ad_id, limit, and account_id. The description adds only contextual reinforcement ('specific ad', 'ad ID') and does not provide additional parameter semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Retrieves leads' with a specific resource ('a specific ad') and scoping ('regardless of which form they used'). Explicitly distinguishes itself from meta_ads_leads_get by contrasting per-ad vs cross-ad lead pulls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'measure lead volume of a particular creative / ad ID when ranking winners.' Also names the alternative meta_ads_leads_get for 'full form-based lead pulls (cross-ad)', giving clear exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses that the tool is mutating, not automatically reversible, recommends recording before-state, and clarifies that it only attaches the post as creative. This goes beyond typical descriptions, though it omits authentication requirements or potential errors, so not a perfect 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary action, and each sentence adds unique value (returns ad_id, mutation warning, prerequisite, alternative). No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the return value (ad_id), mutation side effects, rollback suggestion, prerequisites, and alternative tool. It does not cover failure modes or required permissions, but for this complexity the description is quite complete. A 5 would require more on error conditions or authentication.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all 5 parameters, so the description adds limited new meaning. It does add context for ad_set_id (must already exist, budget/targeting configured) and clarifies that the tool only attaches creative, but these are more usage context than parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Boosts an existing Facebook Page post by creating a paid ad that uses the post as its creative.' It specifies the resource (existing post), the mechanism (creating a paid ad), and differentiates from siblings by directing new-creative use to meta_ads_ads_create. This exceeds simple restatement and provides precise, distinguishable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: when boosting an existing post, and explicitly states the prerequisite that the parent ad_set_id must already exist with budget and targeting configured. It also names the alternative for new-creative ads, meta_ads_ads_create. This gives clear context and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and explicitly declares 'Read-only.' It also describes return fields and the 'sample payloads' nature. However, 'recently' is vague and it does not mention potential constraints like time window limits, pagination, or auth requirements, leaving some behavioral traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, return fields, read-only declaration, usage scenario, and alternative. It is front-loaded with the main action and not padded with redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by detailing the return fields and the purpose. It also provides guidance on when to use and what to do with the data. However, it leaves 'recently' undefined and does not mention any runtime limitations, which is a minor gap but not critical for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both pixel_id and account_id are already described in the schema. The description does not add further meaning to the parameters, so the baseline of 3 applies, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'distinct event types the pixel has received recently, with sample payloads.' It precisely lists the returned fields and distinguishes itself from meta_ads_pixels_stats by mentioning aggregate volume over time, making it unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use case is provided: 'Use this to audit which standard events ... and custom events are firing, and to inspect parameter names before building conversion rules or audience definitions.' It also gives an alternative for different needs: 'For aggregate volume over time use meta_ads_pixels_stats.' This fully guides the agent on when to use this tool vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only' and lists the exact return fields, which is substantial for a list operation. However, it does not mention pagination behavior or potential rate limits, which are common for list endpoints, so it lacks complete transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences: first states the core action, second lists return fields, third gives concrete use cases. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description usefully enumerates the return fields and explicitly states read-only behavior. It also provides downstream usage context. However, it does not address pagination, error scenarios, or authentication requirements, which would be valuable for complete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (limit and account_id), with well-written descriptions including defaults, maximums, and required format. The tool description adds nothing beyond the schema for parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' with the resource 'Meta Pixels' and scope 'available in the ad account', clearly distinguishing it from sibling tools like get, create, stats, and events. The return fields are enumerated, leaving no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to find a pixel_id before creating a WEBSITE audience (meta_ads_audiences_create) or fetching event statistics (meta_ads_pixels_stats / events). It names specific alternative tools, providing clear usage context without needing further inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently describes the return shape (one entry per platform with capabilities), the canonical platform key format (including plugin-specific composite keys), and the relationship between registry_name and source_distribution. This covers key interpretive behavior, though it doesn't discuss error conditions or auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that front-loads the purpose and returns shape, then explains key semantics. While not terse, every sentence serves a purpose, detailing capabilities, usage, key format, and field roles. The structure is logical, though the long parentheticals could be slightly better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input schema and no output schema, the description must fully explain both inputs and outputs. It adequately covers output shape (one entry per platform, capabilities list), the canonical key format, built-in vs plugin modules, and the meaning of registry_name and source_distribution. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the input schema is empty. Per the rubric, 0 params receives a baseline of 4. The description adds value by explaining the semantics of the output fields (platform, registry_name, source_distribution) that the parameterless invocation will return.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List analytics modules registered for each integrated platform,' specifying the action, resource, and scope. It also differentiates from sibling tools by explaining this is a registry lookup consulted by workflow skills, distinctly separate from tools that run analytics or manage state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Workflow skills consult this to decide whether to run deep analytics for a platform or honestly report analytics_not_available_for_<platform>.' It also explains the difference between built-in and plugin-supplied modules. However, it doesn't explicitly mention when not to use this tool or name alternative tools for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 side effects (every action_log entry tagged with batch_id), statefulness (refused if a batch is already open), and the rollback relationship. It also mentions cross-platform scope (native, hosted connector, bridged/plugin) and the batch lifecycle, providing rich behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, tagging behavior, usage timing with examples, and a refusal condition. It is front-loaded with the primary function and contains no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the key output concept (returned batch_id) and its downstream use with rollback_plan_get. It covers lifecycle, constraints, and platform scope. However, it does not describe the exact return format or any error conditions beyond the open-batch refusal, leaving a minor gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 itself does not add significant meaning beyond the schema for the parameters. It references the returned batch_id but does not elaborate on parameter usage or format, so it neither compensates nor adds extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Declare the start of a bulk change so it can be reviewed and reversed as ONE unit.' It uses a specific verb ('Declare the start') and resource ('bulk change'), and distinguishes itself from siblings like mureo_batch_end and mureo_batch_status by mentioning batch_id and rollback integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it: 'Call this BEFORE a multi-entity pass' with examples. It also points to a follow-up alternative: 'afterwards, rollback_plan_get with that batch_id reports what can and cannot be reversed.' However, it does not explicitly state when not to use it beyond the runtime refusal if a batch is already open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses atomic replacement, parsing via parse_strategy() to ensure well-formedness, and that malformed input raises rather than corrupts the file, providing strong behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The primary action is front-loaded, and each clause adds value: what it does, validation, error behavior, and use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple write tool with a complete schema and no output schema, the description covers the core aspects: operation, validation, error handling, and typical use case. It lacks return-value details but that is not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers both parameters at 100%, but the description adds meaning by requiring markdown to be parseable by parse_strategy() and explaining the atomic replacement behavior. This goes beyond the schema's basic param descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'replace' with the resource 'STRATEGY.md', clearly stating the operation. It distinctively positions itself as the write counterpart to sibling 'mureo_strategy_get'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Use this to update goals, constraints, or operation mode from a chat-only host', providing clear context for when to use. It doesn't explicitly name alternatives, but the sibling list makes the read/write distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does it well. It explicitly discloses read-only behavior ('Read-only; reaches no platform API'), the shape of findings (severity, delivery_state, ad ids, evidence), the types of violations detected, the pre-flight mode behavior, default recognition of utm_* parameters, and the ads_without_readable_url 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each carrying distinct information: purpose+outputs, violation categories, read-only+API note, pre-flight usage, and parameter/edge-case behavior. It's appropriately sized for a complex tool but not as minimal as the calibrating example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given rich input schema descriptions and no output schema, the description still explains the return fields and covers edge cases. It could mention that comparisons never cross platforms and that ads are grouped by campaign_id, but those are already in the schema. Overall it's sufficient for an agent to decide to use it and understand what it will get.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaning by explaining that planned_ads toggles pre-flight reporting and that utm_* parameters are recognized unless the convention declares more — details not in the schema. However, most parameter behavior is already well-documented in the schema, so it doesn't need to compensate much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Audit') and resource ('final-URL tracking parameters across ad records you pass in') plus platform scope, and enumerates what findings it returns. It clearly distinguishes itself from platform-specific list/update siblings and other analysis_* tools by focusing on tracking-parameter consistency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete when-to-use trigger: 'Pass planned_ads to pre-flight ads before creating them — then only the new ads are reported.' It also states the tool is read-only and reaches no platform API, implying it can be used without side effects. However, it doesn't name specific alternatives or explicitly say when NOT to use it, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses the automatic no-text constraint, writes to a new run directory with a provenance manifest.json, and specifies return values including run id, directory, file paths with SHA-256, and manifest path. This exceeds basic expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences convey purpose, constraints, file output, return payload, and provider behavior without any filler. The structure is front-loaded with the core action and progresses logically through output and usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no output schema, the description covers return values, side effects (file writing), provider behavior, and template-specific prompt modifications. It also acknowledges the typography pipeline context, making it complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter (n, aspect, prompt, provider, template) documented. The description adds emphasis on the prompt being visual-only and the template's negative-space behavior, but these are largely redundant with the schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Generate text-free key-visual PNGs for an ad creative.' It clearly differentiates from siblings like creative_studio_edit_visual by noting text is added later by the typography layer, and it explains the tool's role in the pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (creating text-free key visuals) and describes provider selection, including the 'all' fan-out option. It does not explicitly name alternatives like creative_studio_edit_visual or creative_studio_compose, but the usage context is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only' and describes the output structure ('one row per accessible customer with id (10-digit), descriptive_name, currency_code, time_zone, and manager flag'). With no annotations available, this provides important behavioral insight, though it does not mention pagination, rate limits, or error cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the core purpose, followed by output details and usage guidance. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with one optional parameter and no output schema, the description is complete: it explains what is listed, the fields returned, and how to use it in the broader session. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full coverage (100%) with a clear description of the optional customer_id parameter, including format and fallback behavior. The tool description adds no additional parameter semantics beyond reinforcing the usage context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific action and resource: 'Lists all Google Ads accounts accessible under the configured manager (MCC) account or directly under the authenticated user.' It clearly differentiates this tool from sibling tools that list campaigns, ad groups, or ads by focusing on accounts/customers and mentioning the returned fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool: 'Use this at the start of a session to choose which customer_id to pass into subsequent calls.' It also explains the fallback behavior of other tools, helping the agent understand when this tool is needed and how it relates to the broader workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is mutating, not automatically reversible, suggests rollback via mureo_state_action_log_append, and states the campaign status precondition. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, then returns, mutation warning, precondition, and next steps. Every sentence carries essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with no output schema and no annotations, the description covers creation, return values, mutation risk, rollback guidance, preconditions, and subsequent workflow. It is remarkably complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are already well-documented. The description does not add new parameter-level details beyond reinforcing that the parent campaign must be active, which is already implied by the campaign_id schema description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a new ad group inside an existing campaign' with a specific verb and resource, distinguishing it from update/list siblings. It also mentions the return values, further clarifying its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for usage: parent campaign must be ENABLED or PAUSED, and it recommends follow-up actions (add ads, keywords). However, it does not explicitly contrast with alternatives like google_ads_ad_groups_update, so a perfect score is not warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only' and lists the returned fields (id, ad_group_id, status, type, final_urls, approval_status, creative summary), providing transparency about its behavior and output. It lacks deeper details on edge cases or pagination, but with no annotations provided, it carries the transparency burden well and does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: the first sentence states the main action and optional filters, the second details the return fields, and the third provides usage context and related tools. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A list tool with no output schema, but the description compensates by enumerating the returned fields and including a creative summary. It also provides usage context, relationship to sibling tools (update, policy_details), and clarifies the read-only nature. This makes it complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with clear descriptions for all three parameters (ad_group_id, customer_id, status_filter). The description mentions 'scoped to one ad group and/or filtered by status', which summarizes the parameters but does not add new semantic meaning beyond what the schema provides. Baseline of 3 is appropriate given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Lists ads in a Google Ads account' with optional scoping and filtering. It distinguishes itself from siblings by explicitly referencing ads.update/update_status for ad_id lookup and pointing to policy_details for disapproval details, making it distinct from update and policy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this to find an ad_id before calling ads.update / update_status or to audit creative inventory. For disapproval details, follow up with google_ads_ads_policy_details.' This clearly indicates when to use this tool and which alternatives to choose for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It clearly declares 'Read-only', which is critical for side-effect awareness, and details the returned statuses and topics. However, it does not disclose error behavior (e.g., ad not found), rate limits, or required permissions. Still, the safety profile is sufficiently transparent for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are used, each earning its place. The first sentence communicates the action and output, the second provides usage guidance. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by listing the key return fields (approval_status, policy_topic_entries, evidence, appeal eligibility). It also provides the integration context with google_ads_ads_list. The tool is simple and the description is complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers 100% of parameters with clear descriptions (ad_id, ad_group_id, customer_id with fallback behavior). The description does not add any additional parameter semantics, making the schema the primary source. Baseline 3 applies because the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetches') and resource ('Google Ads policy review result for a single ad'), and enumerates key return fields (approval_status, policy_topic_entries, appeal eligibility flag). It clearly distinguishes from sibling tools like google_ads_ads_list by focusing on a single ad's policy review.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Call this after google_ads_ads_list surfaces a non-APPROVED ad'. Provides the exact trigger condition and purpose, effectively guiding the agent to the appropriate context without needing to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations are absent, the description explicitly says 'Read-only' and discloses important nuances like shared budgets and that total_budget is null unless CUSTOM_PERIOD. This fully offsets the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences but packed with value: first defines the action and lists return fields, second gives a safety warning. No fluff, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully enumerates return fields and edge cases (null total_budget, shared budgets). It also supplies the read-only safety context and a pointer to the update tool, making it self-sufficient for a get operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters already explained (including customer_id fallback). The description adds no further parameter-level detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetches the campaign-budget record attached to a campaign.' It clearly distinguishes from sibling tools like google_ads_budget_update and google_ads_budget_create by focusing on retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context by advising to check reference_count before calling google_ads_budget_update, implying this tool is for pre-update verification. It doesn't explicitly state when not to use it or name alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explicitly states the destructive nature: 'Destructive — the callout stops serving on the campaign but the Asset row itself is not deleted.' It also mentions the return value and the re-enabling path, providing substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: action, return value, destruction semantics, and sibling guidance. Front-loaded with the action verb, no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a removal tool with no output schema and moderate parameter count, the description covers the action, effect, re-enabling, and sibling alternative. The return format is disclosed. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter already described (source, format, fallback). The description itself adds no parameter-specific detail beyond the notion of a CampaignAsset link, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Detach a callout asset from a Google Ads campaign by removing the CampaignAsset link.' This clearly distinguishes it from sibling tools like google_ads_callouts_list and google_ads_callouts_create. The return value ({resource_name}) is also stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly points to the sibling list operation ('For the sibling list operation use google_ads_callouts_list') and notes re-enabling requires the create tool. It implies when to use this tool (when detaching a callout) but does not give an explicit when-not-to-use beyond the list alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explicitly states 'Read-only' and describes the row-per-campaign return format including the specific fields returned. While it doesn't mention pagination or rate limits, the read-only nature and return shape are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: first states the action, second describes output and read-only nature, third provides usage and alternative tool. Every sentence adds value, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is complete: it covers what it returns, when to use it, the read-only aspect, and the alternative for single-campaign details. The schema provides parameter details, and no output schema is needed since the return fields are enumerated in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with descriptions and enums (100% coverage). The description adds no extra parameter information beyond referencing 'optional status filtering', so a baseline score of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists campaigns in a Google Ads account with optional status filtering, distinguishing it from the sibling google_ads_campaigns_get which returns full details for a single campaign. It also specifies the exact output shape (id, name, status, etc.), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this tool to audit account structure or find a campaign_id before calling campaigns.get/update/update_status, and directs users to google_ads_campaigns_get for single-campaign details. This provides clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 that the operation is read-only, describes the return shape in detail, and documents an important edge case (empty list for UPLOAD_CLICKS actions). It could mention auth/error conditions, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient: it opens with an action, explains the output format, gives a concrete edge case, states read-only behavior, and names the alternative tool. Every sentence earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only snippet-fetch tool with only 2 parameters, the description is complete. It covers purpose, return shape, the empty-list edge case, read-only status, and the relevant alternative. The lack of an output schema is compensated by the explicit return description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 itself does not add parameter-level detail beyond what the schema already provides; the schema already explains the customer_id fallback and how to obtain conversion_action_id. Thus no additional semantic value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Fetch the HTML/JavaScript tag snippets for a Google Ads conversion action'. It clearly distinguishes itself from the metadata-focused sibling google_ads_conversions_get by explicitly pointing to that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the practical use case (install snippets on the advertiser's site) and explicitly names google_ads_conversions_get as the tool for configuration metadata. This gives clear guidance on when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It clearly declares 'Read-only', covering the main safety aspect, and describes output fields including the 'if overridden' caveat for cpc_bid_micros. However, it omits operational details such as pagination or rate limits, so it isn't 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the action and resource. Each sentence adds value: scope, return fields, read-only, and use cases. No redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with optional parameters and no output schema, the description covers purpose, filtering, return fields, side-effect safety, and use cases. It even notes the subscription of cpc_bid_micros and provides a sibling alternative, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers all four parameters with descriptions, so baseline is 3. The description adds 'optionally scoped to a campaign and/or ad group and filtered by status', which restates schema semantics without adding new format or behavioral detail. It doesn't compensate for any gaps because there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Lists keyword criteria' — a specific verb and resource. It distinguishes from siblings by detailing the returned fields and explicitly pointing to google_ads_keywords_diagnose for quality-score diagnostics, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States concrete use cases: locating a criterion_id before pause/remove and auditing keyword coverage. It explicitly names an alternative (google_ads_keywords_diagnose) for quality-score diagnostics, establishing when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It openly states 'Read-only' and describes the exact return shape: 'Returns [{criterion_id, geo_target_constant (resource path, e.g. 'geoTargetConstants/2392' for Japan), bid_modifier (float or null)}].' It adds context about geo target constant IDs. It does not mention pagination or potential large result sets, but for a simple list tool, this is adequate. A 4 reflects strong transparency without going into every possible edge case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the primary purpose, the second describes the return format, and the third adds geo constant context and sibling alternatives. Every sentence earns its place without fluff or redundancy. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple 2-parameter list tool with no output schema. The description covers the core purpose, the return structure, the read-only nature, and even provides a useful note about geo target constants. The context is sufficient for an agent to invoke the tool and interpret results. No missing critical information for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage of parameters, with clear descriptions for both campaign_id and customer_id. The tool description does not add any parameter-specific semantics beyond what the schema already states. Per the rubric, when schema coverage is high, the baseline is 3, and no extra parameter insight is given, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List every LOCATION campaign_criterion on a Google Ads campaign.' It uses a specific verb and resource, and explicitly distinguishes from sibling tools by noting 'For adding or removing locations use google_ads_location_targeting_update; for schedule-based targeting use google_ads_schedule_targeting_list.' This makes the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by naming alternatives: 'For adding or removing locations use google_ads_location_targeting_update; for schedule-based targeting use google_ads_schedule_targeting_list.' It also frames the tool as read-only, implying it is for listing/checking, not modifying. This is 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool is read-only and capped at 1000 rows per level, which are meaningful behavioral traits. It does not describe every possible edge case, but for a read-only listing tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core function, then lists return fields, then provides usage context and an alternative. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers what the tool returns, its limitations (read-only, cap), use cases, and relationship to sibling tools. The schema covers parameters, and no output schema exists, so this description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, and each parameter (ad_group_id, campaign_id, customer_id) has a clear description. The tool description does not add further parameter explanation, but the schema already does the heavy lifting, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists delivery-surface exclusions (websites, apps, app categories) at campaign and ad group level, and names the returned fields. It explicitly distinguishes itself from the sibling google_ads_negative_keywords_list, so the purpose is unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: to get criterion_id for google_ads_negative_placements_remove or to diagnose delivery collapse after a bulk exclusion pass. It also directly names the alternative for excluded search terms (google_ads_negative_keywords_list), offering clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosing behavior. It explicitly states that the operation is mutating ('lifting an exclusion lets the placement serve again'), describes the safety verification ('Ids are verified against the live criteria first'), and clarifies that invalid IDs are skipped, never removed. It also documents the return structure (removed, removed_count, skipped entries with reasons).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary action. Every sentence contributes unique value: purpose, return values, mutating effect, safety verification, and ID source. It is concise enough despite being longer than one sentence, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete given the moderate complexity and lack of an output schema. It covers the operation's purpose, the exact return data, the mutation warning, the validation/skip behavior, and how to obtain valid IDs. It provides enough context for an agent to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with detailed descriptions for all four parameters, including the relationship between campaign_id and ad_group_id and the source of criterion_ids. The description adds almost no new parameter-level semantics beyond what the schema already states; it reinforces the batch/verification behavior but that is more about tool behavior than parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Lifts delivery-surface exclusions by criterion_id, in one batch'), the resource (negative placements), and the specific use case ('a bad exclusion pass can be reverted in a single call'). It distinguishes itself from sibling tools like google_ads_negative_placements_add and google_ads_negative_placements_list by focusing on removal/reversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (reverting exclusions, batch removal) and directs users to google_ads_negative_placements_list for obtaining IDs. However, it does not explicitly mention alternative tools or when not to use this tool, such as distinguishing from negative keyword removal tools, though the name and scope make the intended use fairly obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full weight. It discloses key behaviors: merging campaign/account-level entries, deduplication by id, read-only nature, and the exact return structure. Minor omissions like pagination and error handling are not critical for a simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, then return format, then usage guidance. Every sentence adds value with no redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool, the description provides purpose, merging/dedup behavior, return structure, and usage context. The return format is explicitly defined, compensating for the absent output schema. It's complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters already have detailed descriptions in the schema. The description adds no new parameter-level information beyond referencing campaign context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List sitelink assets attached to a Google Ads campaign, merging campaign-level and account-level entries.' This clearly distinguishes it from sibling tools like google_ads_sitelinks_create and google_ads_callouts_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use this to audit extensions before calling google_ads_sitelinks_create (20 per-campaign limit) or google_ads_sitelinks_remove. For callouts use google_ads_callouts_list.' This gives direct context and names alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly says 'Destructive', explains that it only unlinks the asset without deleting the underlying Asset row, and notes the return value. This is highly transparent about consequences and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Each sentence provides essential information: the operation, the return value, the destructive nature, and related actions. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple detach operation with no output schema, the description is complete. It covers the return value, side effects (does not delete the Asset row), and how to undo (re-link via create). It also tells users how to list existing sitelinks, providing full contextual coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for all parameters, so the description does not need to add parameter semantics. It adds no additional parameter information, but the baseline of 3 is appropriate given the schema's thoroughness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Detach a sitelink asset from a Google Ads campaign by removing the CampaignAsset link.' It uses a specific verb, names the resource, and distinguishes itself from sibling tools like google_ads_sitelinks_list and google_ads_sitelinks_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: it says re-linking requires google_ads_sitelinks_create and lists sitelinks via google_ads_sitelinks_list. It does not explicitly state when not to use this tool, but the destructive warning and alternatives make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It states 'Read-only', which is a key safety trait, and lists the return fields, giving a clear picture of what the tool does. It does not mention error cases or auth, but for a read-only get operation, this is sufficient and adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences that are front-loaded with the primary action, followed by return value details and usage guidance. Every sentence provides useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (a get operation with two well-described parameters), the description is contextually complete. It explains the return values since there is no output schema, states the read-only nature, and gives usage context for a common workflow with meta_ads_ad_rules_update.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add extra semantic detail about parameters beyond what the schema already provides, but it doesn't need to because the schema is comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches the full detail record for a single Automated Rule, specifying the verb 'Fetches' and the resource. It also distinguishes itself from sibling tools like meta_ads_ad_rules_list by focusing on a single rule and from meta_ads_ad_rules_update by serving as a pre-update fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call this before meta_ads_ad_rules_update to merge incremental changes instead of overwriting the whole spec. This provides clear when-to-use guidance and an explicit alternative, making it highly actionable for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses the status change, the dependency on the parent campaign, that paused ads underneath will not auto-resume, the return value, and reversibility. This is comprehensive behavioral information beyond what a minimal description would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and every sentence adds value: it explains the action, prerequisites, side effects, return value, and reversibility. No redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description is thorough: it covers the action, conditions, impact on child entities, return value, and reversal path. It provides all necessary context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions (e.g., ad_set_id as 'Ad set ID to activate' and account_id with format and fallback). The description does not add parameter-specific details beyond the schema, but it confirms the action's effect on the ad set. This aligns with the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Resumes a paused ad set by setting its status to ACTIVE.' It specifies the resource (ad set) and the operation (enable/resume), distinguishing it from sibling tools like meta_ads_ad_sets_pause and meta_ads_ad_sets_update. The added context about parent campaign and ad status further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when an ad set is paused and needs resuming) and provides important prerequisite context (parent campaign must be ACTIVE). It also names reversal options (rollback_apply or meta_ads_ad_sets_pause), but doesn't explicitly contrast with other tools like meta_ads_ad_sets_update or mention scenarios where this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the behavioral impact: status change to PAUSED, ads under it stop serving even if ACTIVE, reversibility, return value, and lack of effect on siblings. This is rich context beyond the schema, covering the essence of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary action, followed by behavioral nuances and reversibility. Every sentence provides useful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is remarkably complete. It covers purpose, effect, reversibility, return value, and scope. It does not explain permission requirements, but for a straightforward pause operation, the given context is sufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 ad_set_id and account_id. The description does not add parameter-specific semantics beyond what the schema provides, though it does mention the return value which indirectly references ad_set_id. This aligns with the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pauses a single ad set by setting its status to PAUSED, which is a specific verb+resource. It distinguishes from siblings by emphasizing 'single ad set' and 'does not affect sibling ad sets,' and clarifies the cascading effect on ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning it is lightweight and reversible via rollback_apply or meta_ads_ad_sets_enable, and contrasts with sibling ad sets. However, it does not explicitly enumerate when to use this tool versus enabling or updating ad sets, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explicitly states 'Read-only' and describes what it returns (current/prior metrics, delta %, callouts), giving useful behavioral context beyond just the tool name. It lacks details on failure modes, but the read-only and output characteristics are well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences in a logical order: purpose first, then output details, then usage guidance. No wasted words, and the callout examples make the output concrete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description explains what is returned (metrics, deltas, callouts), the period comparison logic, read-only nature, and when to use it. It is self-contained and complements the rich sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 period, account_id, and campaign_id clearly. The description adds minimal extra parameter meaning (e.g., 'or the whole account' implies omitting campaign_id), so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Produces an operator-ready performance review' with a specific verb and resource, and distinguishes itself from raw insights tools by focusing on 'period-over-period comparison' and callouts. This differentiates it from sibling tools like meta_ads_insights_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this at the start of an audit' and directs to meta_ads_insights_report for raw insights, providing clear when-to-use and an alternative. This is strong usage guidance for an audit workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only' and details the output format, which is the key behavioral trait. With no annotations provided, this disclosure carries full weight. It could have also mentioned quota costs, but the schema's period description covers that. Overall it's transparent for a read-only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, all in service of the purpose. It front-loads the verb and resource, then provides output details, read-only note, use case, and alternative. No waste, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by fully describing the return value ('rows per placement with spend, conversions, CPA, ctr, and a recommendation'). It also covers usage, read-only, and the alternative tool. The description is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains all parameters. The description adds context by mentioning 'campaign' in the usage scenario, but it does not add significant parameter semantics beyond what's in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Scores delivery efficiency across Meta placements' and lists the specific output (rows per placement with metrics, recommendation). It distinguishes itself from the raw-data sibling by explicitly naming meta_ads_insights_breakdown as an alternative for raw numbers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Call this when CPA drifts on a campaign' and names the exact alternative for raw numbers ('use meta_ads_insights_breakdown with breakdown="placement"'). This clearly tells when to use this tool vs another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the operation is 'Mutating — not automatically reversible' and advises recording before-state with mureo_state_action_log_append for rollback. It also discloses the return value and notes that the customer list upload path is handled out-of-band. It does not mention auth needs or rate limits, but the side-effect and rollback disclosure is substantial for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with purpose and return value. Every sentence adds meaningful information: mutation warning, subtype behavior, lookalike alternative. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with 100% schema coverage and nested objects, the description covers the essential operational context: what it does, what it returns, that it mutates, how subtypes alter behavior, and which alternative to use for lookalike. No output schema exists, but the return value is stated. The description plus schema are sufficient to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to repeat parameter documentation. It does add some contextual glue to subtype behavior (e.g., WEBSITE auto-generates a PageView rule, CUSTOM accepts list upload) that goes slightly beyond the schema, but most parameter semantics are already well-covered by the schema. This meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Creates a Custom Audience in a Meta Ads account.' It also states the key return value ('Returns the new audience_id') and distinguishes itself from the lookalike sibling by explicitly naming meta_ads_audiences_create_lookalike for similarity-expanded reach. This makes the tool's purpose unmistakable and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus the lookalike alternative: 'For similarity-expanded reach use meta_ads_audiences_create_lookalike on top of this audience.' It also explains subtype-specific requirements (WEBSITE needs pixel_id+rule, CUSTOM accepts rule or list upload), giving clear direction on parameter usage. This qualifies as explicit when/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavioral traits. It states 'Read-only' and describes exactly what fields are returned. It doesn't mention pagination behavior or auth requirements, but for a read-only list tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and every sentence adds value: what it does, what it returns, read-only nature, and alternatives. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with full schema coverage and no output schema, the description is complete: it explains purpose, return fields, read-only nature, and gives clear context on when to use it vs. alternatives. There are no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has detailed descriptions including formats and defaults. The description adds no new semantic information beyond 'optional status filtering' which is already in the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists campaigns in a Meta Ads account with optional status filtering, and enumerates the return fields. It distinguishes itself from siblings by explicitly directing users to meta_ads_campaigns_get for a single campaign's full detail record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use this to find a campaign_id before calling campaigns.get or pause/enable helpers, and for full detail use meta_ads_campaigns_get. This tells the agent when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the cascading effect on ad sets and ads, reversibility, and the return value. It does not cover permissions or API rate limits, but the core side effects and recovery paths are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the primary action, followed by the cascade behavior, reversibility, return value, and usage alternatives. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (two params, one required) and has no output schema, but the description covers what happens on execution, what is returned, how to reverse it, and when to use it versus the alternative. The context is complete for an agent to select and invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters, including a detailed account_id description. The tool description adds no extra parameter-level detail beyond the fact that campaign_id is the target, so the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Pauses'), the resource ('a single campaign'), and the exact mechanism ('setting its status to PAUSED'). It also distinguishes itself from sibling tools by noting the cascade to ad sets and ads and by contrasting with the soft-delete alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use for immediate stop-spend situations' and recommends meta_ads_campaigns_update with status='DELETED' for soft-deletion. It also names reversible paths (rollback_apply or meta_ads_campaigns_enable), giving the agent 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive nature, cascading effects on products and DPA campaigns, non-reversibility, and the need for rollback logging. This goes far beyond a simple delete and provides critical safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each delivering essential information: the action, the return value, the destructive consequences, and the prerequisite/rollback guidance. It is front-loaded with the purpose and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no output schema and no annotations, this description covers purpose, effects, prerequisites, and rollback. It is remarkably complete for its length, addressing all critical decision-making needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add specific semantics for account_id or catalog_id beyond the schema, but the schema already documents them thoroughly, so no penalty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Deletes a Product Catalog' with a specific verb and resource, and mentions the success flag. The name meta_ads_catalogs_delete further distinguishes it from sibling tools like create/get/list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides an explicit precondition: 'Always call meta_ads_catalogs_get first to check product_count and operator-confirm before calling this.' It also mentions using mureo_state_action_log_append for rollback, which gives context on when additional steps are needed. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden of behavioral disclosure. It clearly states the mutation side-effect ('Mutating — the image is persisted in the account library') and important fetch behavior ('Meta fetches it once at upload time — subsequent changes to the source URL do not affect the stored asset'). While it doesn't cover error handling or authorization, it provides solid transparency for a straightforward tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding critical information: the action, the return value and usage, and the mutation side-effect with an alternative. It is front-loaded with the primary action and avoids extraneous detail, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters, a simple URL-fetching operation, and no output schema, the description covers all necessary context: what it does, what it returns, how to use the result, the side-effect, and a clear alternative. It leaves no major gaps for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters, including a detailed explanation of image_url and account_id. The description reinforces the URL-fetching nature but adds no additional parameter-specific meaning beyond what the schema documents. Hence the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: uploading an image to the Meta Ads account from a public HTTPS URL. It also specifies the output (image_hash) and references the exact downstream tools (meta_ads_creatives_create / create_dynamic / create_carousel), making the purpose unambiguous and distinguishing it from sibling upload tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: it explicitly names meta_ads_images_upload_file for local file uploads, and implicitly recommends this tool for URL-based uploads. It also clarifies the purpose of the returned hash for use in creative creation tools, giving clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description takes on the burden. It discloses read-only nature, exact return fields, and that unset facets are reported as empty arrays. It doesn't cover error scenarios or authorization requirements, but for a simple read operation this is strong coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, followed by return-value details and usage guidance. Every sentence is functional, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description fully covers what the agent needs: what it returns, how unset fields are presented, when to use, and how it relates to sibling operations. The schema covers parameters competently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with detailed descriptions for both ad_set_id and account_id, including example format and fallback behavior. The tool description itself adds no extra parameter-level information, staying at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Reads' and identifies resource 'one ad set's delivery-surface exclusions from its targeting spec.' It also distinguishes from sibling tools by explicitly naming meta_ads_excluded_placements_set and meta_ads_analysis_placements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before meta_ads_excluded_placements_set to understand replace vs append, or to check if exclusion change explains delivery drop. Also directs users to meta_ads_analysis_placements when they need actual delivery information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly states the tool is mutating, not automatically reversible, and recommends recording before-state for rollback. It also explains automatic scheduling and supported feed formats. Minor gaps include lack of failure/retry behavior, but overall strong transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Every sentence adds value: purpose, return value, mutability warning, schedule behavior, alternative tool, and supported formats. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create operation with no output schema, the description provides all essential context: what it does, what it returns (feed_id), safety/rollback guidance, scheduling implications, and an explicit alternative for one-off cases. It is complete for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds context about feed formats and scheduling behavior but does not meaningfully enhance parameter-level semantics beyond the schema's detailed field descriptions. This meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and clearly identifies the resource ('scheduled product feed') and its purpose ('imports products into a catalog from a URL'). It also distinguishes itself from the sibling meta_ads_products_add by noting feeds are for ongoing bulk sync, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('ongoing bulk sync') and when not to ('For one-off product adds use meta_ads_products_add'). Also provides important operational context about automatic scheduling and first-run timing, giving clear guidance on expected usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the operation is mutating ('Mutating — the asset is persisted') and describes the return value. However, it does not mention permissions, errors, or other edge cases, which would make it richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. The first sentence states the action, the second explains the return value, and the third gives usage guidance. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple file upload tool, the description covers what it does, when to use it, the mutation behavior, and the return value. It is complete given the absence of an output schema and the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions (100% coverage), so the description does not need to add param details. It does mention the return value, but that is not parameter semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Uploads an image from a local file path to the Meta Ads account library.' It also specifies the return value (image_hash) and distinguishes from the sibling tool by noting local file vs public URL upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: 'Use this when the image lives on the agent's local disk; for public-URL uploads use meta_ads_creatives_upload_image instead.' This directly names the alternative and clarifies the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It states 'Read-only' and explicitly lists the returned row contents (breakdown key plus impressions, clicks, spend, cpc, ctr, conversions, cost_per_conversion), providing useful behavioral context beyond the schema. However, it does not mention pagination, rate limits, or error behavior, so it isn't fully exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (two sentences) and front-loaded: the first sentence states the action and included metrics, the second provides usage guidance with alternatives. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description compensates by explicitly listing the returned metrics and read-only nature. It also references relevant sibling tools for different use cases. The schema covers parameter details, making the overall tool definition complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with detailed descriptions for all four parameters (period formats, breakdown enum, account_id format, campaign_id). The description adds minimal new parameter information beyond the schema, aligning with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Pulls delivery metrics for a campaign broken down along one dimension'), names the resource (delivery metrics for a campaign), and lists example dimensions and metrics. It distinguishes from siblings by naming meta_ads_analysis_audience and meta_ads_analysis_placements as pre-packaged alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this for ad-hoc slicing; for pre-packaged splits use the dedicated meta_ads_analysis_audience (age/gender) or meta_ads_analysis_placements tools, which add interpretation.' This clearly indicates when to use this tool and when to choose alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description states 'Read-only' (crucial behavioral trait given no annotations), lists exact return fields, and implies no side effects. It does not mention rate limits or pagination behavior, but for a simple listing tool it covers the core behavioral surface.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and return fields, second notes read-only and usage context. Every sentence earns its place; front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Schema fully documents parameters, description documents return fields and read-only nature, and explicitly ties to the boosting workflow via the sibling tool. For a list operation of this complexity, nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all three parameters (100% coverage), so the description does not need to repeat parameter semantics. It adds context around the media_id purpose for boosting but doesn't deepen semantics beyond the schema's existing parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Lists' and identifies resource 'recent media (posts, reels, carousels) for a linked Instagram account.' It also enumerates return fields and distinguishes itself from sibling tools like meta_ads_instagram_boost by specifying the read-only nature and the downstream use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this to find a media_id before boosting via meta_ads_instagram_boost,' naming the exact downstream use case and alternative tool. This provides clear decision guidance for when to use this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it excellently discloses behavior: it fetches specific fields, normalizes context_card (with a detailed quirk), fails fast on missing required data, returns the new form's id, leaves the source untouched, is mutating, reversible via an update call, and is lossy for certain fields. This is exceptional transparency beyond what one would expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence adds value. It logically flows from purpose, to mechanics, to failure mode, to return value, to side effects, and to limitations. There is no fluff or repetition; the length is justified by the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fully covers return value (new form id). It addresses edge cases (missing required fields, lossy fields), side effects (source untouched, mutation), and reversibility. For a tool with this complexity, the description is remarkably complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear explanations for form_id, page_id, new_name, and account_id. The description does not add significant parameter-specific meaning; it focuses more on source-field copying and behavior. Since the schema already documents parameters well, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource combination: 'Duplicates a lead form under the same (or another) Page.' This clearly distinguishes it from siblings like create, update, list, and get. It also explains the underlying reason (no native copy endpoint) and lists source fields copied, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use this tool (to duplicate a lead form), including prerequisites (source must have follow_up_action_url and privacy_policy.url) and failure behavior (fails fast with ValueError). It also warns about lossy fields and suggests recreating them manually, implying alternatives like update. However, it does not explicitly name an alternative tool or state when NOT to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses return fields, nested structure, a field naming mismatch (context_card cover_photo vs cover_photo_id), a known Meta API rejection, and explicitly states 'Read-only.' This goes far beyond a basic summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence earns its place: field enumeration, a critical caveat, and a practical use case. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values. It thoroughly documents the return structure including nested questions/context_card, the legacy privacy_policy_url, and a known pitfall. This gives the agent everything needed to invoke the tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add any parameter-specific semantics beyond what the schema already provides, such as form_id source or account_id fallback.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fetches the full detail record for a single lead form' clearly identifies the verb and resource, and explicitly distinguishes from listing tools by emphasizing 'single' and 'full detail record.' It also names the sibling list tool implicitly by scoping to one lead form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Call this before designing downstream CRM sync so you know the exact field keys to map.' This implies when to use the tool. However, it does not explicitly mention alternatives (like meta_ads_lead_forms_list) or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It declares 'Read-only' and lists the exact return fields. It does not mention pagination or error handling, but for a simple list operation this is sufficient coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. Each sentence adds value: purpose, return fields, read-only status, and usage guidance. No redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description names the exact return fields. It provides clear usage context in the broader Meta Ads toolset, clarifies the page-vs-ad-account ownership, and mentions downstream tools. For a low-complexity list operation, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for limit, page_id, and account_id. The description reinforces that page_id must reference a Page rather than an ad account, but adds minimal information beyond the schema. Baseline 3 applies because the schema handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Lists' and identifies the resource as 'lead forms configured for a Facebook Page.' It distinguishes from sibling tools by noting that lead forms belong to Pages, not ad accounts, and enumerates the returned fields (id, name, status, leads_count, locale, created_time).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'use this to find a form_id before attaching it to a Lead Ads creative or before pulling submitted lead data via meta_ads_leads_get.' Also clarifies ownership with 'Lead forms belong to Pages, not ad accounts,' which indicates the correct scope and helps avoid incorrect parameter usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explicitly states 'Read-only' and clarifies it only lists published posts, which are key safety and scope traits. However, it does not describe pagination behavior beyond the limit parameter or mention potential ordering, leaving minor ambiguity about how many posts are returned and in what order.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and resource, followed by a compact list of returns, then a clear read-only indicator, and finally a practical use case. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a listing tool with well-documented parameters. It enumerates the return fields (compensating for the lack of an output schema), explains the read-only nature, and provides context for its use in boosting workflows. It also names the exact companion tool, making the operational context fully clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter (limit, page_id, account_id) has a detailed description including defaults, formats, and required access. The tool description adds no extra parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists published posts on a Facebook Page' with a specific verb and resource, and enumerates the exact return fields. It also distinguishes itself from sibling tools by explicitly mentioning meta_ads_page_posts_boost, making its purpose unique and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: 'Use this to find organic posts to boost via meta_ads_page_posts_boost' and provides a rationale (boosting organic high-performers is cheaper). This clearly guides when to use this tool versus alternatives like running a new ad, effectively serving as a decision rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explicitly discloses destructive behavior ('Destructive — no further data accrues'), potential null field ('winner_cell_id may be null'), and irreversibility ('Not automatically reversible'), plus mitigation guidance. This goes well beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: action, return value, and risk/rollback. No filler, front-loaded with the core operation. Well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive action with no output schema and no annotations, the description covers key aspects: return value, data accrual cessation, null winner case, and rollback guidance. Given only two well-documented params, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters. The description adds no extra semantic detail beyond the schema's straightforward definitions. Baseline 3 is appropriate since the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Ends a running Split Test immediately'. It clearly distinguishes from sibling tools like meta_ads_split_tests_create, meta_ads_split_tests_list, and meta_ads_split_tests_get by focusing on the termination act, not creation, listing, or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for use: 'before its scheduled end_time' indicates the tool is for early termination. It doesn't explicitly name alternatives or exclusions, but with no direct 'end' sibling and clear purpose, the usage scenario is evident. The rollback suggestion with mureo_state_action_log_append adds practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses read-only behavior, the conditionality of certain fields (when test concluded, when winner determined), and lists return fields. It could add error/rate-limit context, but the core behavioral traits are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the core purpose, usage timing, return structure, sibling alternative, and read-only status without wasted words. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, when to use it, what it returns (explicit field list), and how it differs from siblings. For a simple get-by-id tool with complete schema, this is fully sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and both parameters (study_id, account_id) are already well documented with format and fallback behavior. The description adds nothing beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetches') and resource ('full detail record for a single Split Test'), and clearly distinguishes itself from the sibling list tool by emphasizing per-cell results and the winner read use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('after a test ends to read the winner') and points to the alternative for raw listing ('use meta_ads_split_tests_list'). This is direct, actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It states the tool is read-only and lists the exact fields returned, including the note about internal naming ('Studies'). It lacks details on pagination or default behavior over all studies, but for a list operation the provided transparency is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with a clear progression: purpose, output fields, and usage guidance. It is front-loaded with the primary action, contains no filler, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two well-documented parameters and no output schema, the description covers the essential context: what it lists, what it returns, that it's read-only, and how it fits into the broader workflow. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage for both limit and account_id, including format, defaults, and constraints. The description does not add parameter semantics beyond the schema, but the baseline is 3 given the high schema coverage, so no penalty or bonus is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Split Tests, defines the domain (A/B Tests, internally Studies), specifies the returned fields (id, name, status, dates, cell summary), and explicitly distinguishes it from sibling tools (meta_ads_split_tests_get, meta_ads_split_tests_end). This is a specific verb+resource with clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use this to find a study_id before pulling detailed results via meta_ads_split_tests_get or ending via meta_ads_split_tests_end.' It also marks the operation as read-only, giving clear context on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly says 'Read-only' and lists the exact return fields (id, name, audience_size bounds, path, topic). However, it does not disclose error behavior or pagination details, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and information-dense. It front-loads the main purpose, then covers return fields, read-only safety, usage context, and an alternative in a compact paragraph. Every sentence serves a clear function without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by enumerating the return fields. It also situates the tool in the ad-set creation workflow and provides an explicit alternative for other targeting types, making the scope and purpose fully clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with clear descriptions for all four parameters. The description adds little beyond reinforcing that the search is by keyword (query). It does not explain limit, locale, or account_id beyond what the schema states, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it searches Meta's interest-targeting catalogue by keyword and resolves interest names to internal IDs. It also distinguishes it from the sibling tool meta_ads_targeting_categories by noting that behaviors/demographics are not covered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use this tool before meta_ads_ad_sets_create/update, stating that agents cannot invent interest IDs. It also provides a direct alternative for behaviors/demographics: use meta_ads_targeting_categories instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the key behavioral trait: 'Closing is FINAL: no later entry can join, so the member count stays true.' It also explains the return value and the refused condition, providing transparency beyond what structured data alone would offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded. Four sentences each add distinct value: action/outcome, user guidance, finality warning, and precondition. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), and the description adequately explains the return value, finality, and refusal condition. It provides enough context for an agent to invoke it correctly without needing extra documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 tool description adds no additional parameter meaning beyond what the schema already provides for the optional 'path' parameter. It does not describe the parameter or its constraints, but that is already covered in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Close the open batch' and specifies the outcome: 'return its exact membership: the action_log indices it collected and the platforms they span.' This distinguishes it from siblings like mureo_batch_begin and mureo_batch_status, which handle starting or checking status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: after collecting changes and wanting to finalize the batch. It also notes a when-not condition: 'Refused if no batch is open.' However, it does not explicitly mention alternatives, relying on sibling names to convey their roles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only; mureo never closes a batch on your behalf,' which is critical for a status tool and prevents the agent from expecting side effects. It also discloses the warning condition for unusually long-open batches, adding valuable behavioral context beyond a bare listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, with no filler or redundancy. It front-loads the core reporting functionality first, then adds the warning behavior and the read-only guarantee. Every sentence contributes useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only status tool with one optional parameter and no output schema. The description adequately covers the purpose, the exact data returned (batch, members, platforms, warning), the edge case of no batch (null), and the safety guarantee. No additional information is necessary for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the single 'path' parameter includes a full description ('Optional path to STATE.json. Defaults to STATE.json in the MCP server's current working directory. Paths outside it are refused.'). The tool description does not add any information about the parameter, but at this coverage level the schema already provides sufficient semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Report which batch is currently collecting action_log entries (null when none is), how many members it holds so far, and which platforms they span.' This uses a specific verb ('report'), specifies the resource, and distinguishes it from sibling tools like mureo_batch_begin and mureo_batch_end by focusing on status rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool (to inspect the current batch, its size, and platform coverage, and to detect a long-open batch). It also implies a separation of concerns by stating 'Read-only; mureo never closes a batch on your behalf,' indicating that closing is handled elsewhere. However, it does not explicitly name alternative tools or provide when-not-to-use guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses substantial behavioral traits: enrichment with local campaign state (metrics, action log, STRATEGY.md), forwarding to every server configured in ~/.mureo/insight_sources.json, top-k snippet returns with similarity scores, untrusted external content warning, and a fallback return of a guidance string when no sources are configured. It also specifies safety constraints (ignore embedded instructions, don't override STRATEGY.md, don't exfiltrate state).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical, but every sentence earns its place: it covers purpose, context, process, security warning, usage timing, and fallback. There is no redundancy or fluff; it is information-dense and well-structured, front-loading the purpose and following with essential operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description compensates by explaining return behavior ('Each server returns top-k snippets with similarity scores') and the no-sources fallback ('Returns a guidance string when no sources are configured'). It also covers configuration, enrichment process, and trust boundary, making it complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already provides detailed parameter descriptions (e.g., 'question' advises concrete over generic, 'campaign_id' attaches campaign details). The main description adds context about enriching the question with local state, which aligns with campaign_id, but does not add per-parameter meaning beyond the schema. Per the baseline rule, score is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Consult') and resource ('external advisor MCP servers (vector search)'), and enumerates the types of knowledge sought (platform-specific quirks, current algorithm behaviour, CPA/CTR benchmarks, operational playbooks, platform updates). It clearly distinguishes this tool from all sibling tools, which are state management, reporting, or platform-specific actions; this is the sole external consultation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call this tool 'PROACTIVELY and EARLY in any ad-ops reasoning where operational know-how matters — not just when stuck', giving clear timing and context. It also defines the kind of questions to ask (diagnostic) and positions itself as the primary external channel for operational expertise. It does not name alternative tools, but no direct alternative exists among the siblings for external knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states 'Read-only — it changes nothing and calls no platform API', which is a critical behavioral disclosure. It also explains the meaning of 'unknown' values, ensuring the agent doesn't misinterpret them as safe. This exceeds what annotations would typically provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured: front-loaded with the main purpose, followed by read-only status, return items, when to call, and crucial caveats. Every sentence contributes value, though the length is slightly above average for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description covers the tool's purpose, usage, behavior, and parameter semantics comprehensively. It describes what is returned (three items), the source of data (STATE.json, STRATEGY.md), and edge cases (unknown values). Minor omissions include exact return format or error handling, but these are not critical for this preflight tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant meaning beyond the schema. It explains why 'arguments' is needed (same tool can behave differently based on arguments) and when 'campaign_id' is optional. This contextualizes the parameters in a way the schema alone cannot.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Pre-flight') and resource ('a pending ad-platform change against the target campaign's learning period'). It distinguishes itself from siblings by focusing on pre-flight checks before modifications, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Call this BEFORE a bid-strategy, budget, conversion-setting, keyword or re-enable change'. It also instructs to show the operator the answer in the confirmation step. While it doesn't explicitly state when not to use it or name alternatives, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: absent file returns empty markdown (not an error), server_now is the authoritative current date, and raw markdown is returned. It also implies reading (no mutation) through the verb 'Read'. This is rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action. Each sentence adds value: return contents, absent-file semantics, when to use, and server_now guidance. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional param and no output schema, the description covers the return fields, edge cases (missing file), and time-consistency guidance. It is sufficiently complete for an agent to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single optional 'path' parameter 100% with a clear description (defaults, cwd restriction). The tool description does not add further parameter-level details, so the baseline of 3 applies. The slight mismatch between path default mentioning both STRATEGY.md and STATE.json while the description only mentions STRATEGY.md creates minor ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Read STRATEGY.md') and the precise return payload (raw markdown, exists flag, server_now). It is clearly distinct from sibling tools like mureo_state_get and mureo_strategy_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly provides a when-to-use condition: 'Use this when the host has no direct filesystem access'. It also gives handling guidance for absent files and server_now. However, it does not mention when not to use it or alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states the tool is read-only ('nothing is executed'), describes the nature of the returned data (statuses, coverage, caveats), and notes that partial coverage is determinable beforehand. It does not cover error conditions or edge cases like missing STATE.json, but the core safety profile is well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: a one-sentence purpose, then a clear split for the two modes, and a concluding read-only note. Every sentence adds value and there is no redundant phrasing. The use of code formatting for parameters improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description thoroughly explains the return information for both modes (planner status, operation, parameters, caveats; member verdicts and coverage). It also provides the key context that this is a pre-application planning tool, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics by explaining that index targets a single entry and batch_id covers a whole bulk change with per-member and per-platform coverage, going beyond the schema's brief descriptions. It does not mention state_file in the description, but the schema already explains its default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect the reversal plan') and identifies the resource ('recorded action_log entries in STATE.json'). It clearly distinguishes two invocation modes (index vs batch_id) and differentiates this inspection tool from the sibling rollback_apply by emphasizing it is read-only and does not execute anything.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use index versus batch_id, including the source of batch_id (mureo_batch_begin). It implies this tool should be used before applying a rollback ('partial coverage is known BEFORE anything is applied'), but it does not explicitly name rollback_apply as an alternative or state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 read-only nature of the operation and gives a detailed return structure, including the raw Webmasters sitemap array with field names and types. However, it does not cover potential error conditions, rate limits, or auth requirements, which would push it to 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the purpose and then providing essential return details and usage alternatives. Every sentence adds value, and the formatting of the return array is clear and readable. It is neither overly verbose nor under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description compensates thoroughly by fully specifying the return structure, read-only nature, and alternative for submission. For a simple list operation with one parameter, this is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the site_url parameter fully described in the input schema. The description does not add extra semantic detail beyond referring to 'a Search Console property', so the baseline of 3 is appropriate. The schema already provides the necessary meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'List every sitemap registered against a Search Console property, with their most recent crawl status.' It uses a specific verb and resource, and distinguishes itself from the sibling search_console_sitemaps_submit by explicitly pointing to that tool for submission actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (to list sitemaps and their crawl status) and explicitly names an alternative for a different action: 'For submitting or resubmitting a sitemap use search_console_sitemaps_submit.' This clear differentiation helps the agent select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and delivers: it declares 'Read-only', explains the same-weekday median baseline to prevent weekend false positives, states the current partial day is always excluded, notes it never reads action_log, and cites STRATEGY.md guardrail thresholds with defaults. This goes well beyond a typical one-line tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense and front-loaded with the core action. Every clause earns its place (baseline weekday logic, action_log independence, current-day exclusion, threshold defaults, read-only), and the final 'Read-only' is a clear safety capstone.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the algorithm's complexity and the absence of an output schema, the description thoroughly covers input requirements, interpretation rules, and configuration sources. The one gap is the return shape — it does not describe what a result/signal looks like — but the detection semantics, platform-agnostic intent, and edge-case handling are complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich per-field descriptions, so the baseline is 3. The tool description adds beyond-schema value by explaining the ~30+ day row requirement, baseline algorithm, threshold parameter names/defaults, and that the current day is excluded — all helpful context for choosing and populating rows/as_of. It does not duplicate the schema's per-field semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The opening 'Detect delivery collapse: campaigns whose impressions fell off a cliff while their status still says they should be serving' gives a specific verb, resource, and precise definition. It explicitly separates itself from google_ads_cost_increase_investigate ('inverse of'), making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use it ('scheduled detector /daily-check runs'), what input to feed ('day-grain delivery report... for ANY platform'), and names a related tool it contrasts with. It does not explicitly exclude alternative analyze/diagnose siblings or state when NOT to use it, so usage direction is strong but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently discloses that the tool is read-only, may return most_likely_cause=null when no cause is implicated, always reports open questions and limitations, and shares a concrete incident where every check passed yet the cause was never found. This is unusually honest and complete for behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than two sentences but every sentence adds value: purpose, method, outputs, behavioral caveats, and next steps. It is front-loaded with the main action. A slightly tighter structure could be imagined, but the density is warranted for a complex diagnosis tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (timeline, changes, checks, cause with evidence, open questions, limitations). It also situates the tool across platforms and explains how to use follow-up evidence tools. This is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds workflow context by explaining how the evidence parameter maps to elimination-ladder checks, how changes overlays delivery, and how timeline_days/change_lookback_days control the analysis window. This goes beyond pure schema definitions, justifying a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Diagnose one collapsed campaign.' It clearly defines the method (overlay change feed on delivery, fold in elimination-ladder evidence) and distinguishes itself from siblings like analysis_delivery_collapse_check by focusing on diagnosis of a single campaign with a causal analysis approach.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use after gathering elimination-ladder evidence, and calls for read-only diagnosis. It explicitly instructs to 'gather evidence with the per-platform tools it names in next_checks and call it again.' However, it does not explicitly mention when not to use it or contrast with sibling diagnostic tools like analysis_delivery_collapse_check, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly declares 'Read-only,' explains the API v23 removal of competitor-level auction insight, and details the exact return structure, value ranges (percentages or None), and threshold logic. This goes far beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver dense, relevant information: purpose, return shape, thresholds, read-only status, API limitation, and sibling alternative. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even without an output schema, the description provides a detailed return skeleton and threshold rules. It covers read-only behavior, API version context, and alternative tools. It omits error handling or edge cases (e.g., all metrics null), but for a read-only analysis tool this is acceptable and the overall context is thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides thorough descriptions for all three parameters, including defaults, examples, and fallback behavior. The description adds context about thresholds and return formats but does not add parameter-specific meaning beyond the schema. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-object pair: 'Interpret a campaign's impression-share metrics and surface human-readable insights about competitive position.' It clearly distinguishes from the sibling google_ads_auction_insights_get by contrasting raw metrics vs. insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'For the raw metrics without insights use google_ads_auction_insights_get.' Also notes that full competitor data is only available in the Google Ads UI, and provides concrete threshold conditions (IS < 50/70%, rank-lost > 20%, etc.) that trigger insights, guiding appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states the tool is read-only, discloses the hardcoded 7-day comparison window, and lists the detailed return structure including change history events and negative keyword candidates. This goes beyond minimal disclosure and sets clear expectations for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded with the purpose and method. The long enumeration of return fields is necessary because there is no output schema, but it could be slightly overwhelming. Overall it is efficiently structured with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex investigative tool with no output schema, the description is remarkably complete. It details the return object, the hardcoded window, read-only behavior, and explicitly names alternative tools. The only minor gap is not explaining the meaning of each return field, but the field names are self-explanatory and the output schema is absent, so this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both campaign_id and customer_id fully described in the input schema. The tool description itself does not add additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Investigate the root cause of a Google Ads cost spike or CPA deterioration' with a specific method (comparing last 7 days vs prior 7 days). This distinguishes it from sibling tools like google_ads_performance_analyze and google_ads_monitoring_cpa_goal, which are explicitly named as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage guidance: use this tool for cost spike/CPA deterioration root-cause investigation, and points to google_ads_performance_analyze for broader diagnostics and google_ads_monitoring_cpa_goal for CPA-vs-target monitoring. This gives clear when-to-use and alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it declares 'Read-only', describes the exact output shape, explains the 'negative' flag semantics, and importantly clarifies that 'Segments with no explicit criterion are targeted by default and do NOT appear.' This goes well beyond the structured schema and gives the agent critical interpretation guidance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence carries essential information: output shape, read-only flag, empty-result caveat, scoping options, and cap. It is well-structured, starting with the core action, then details, then usage. Slightly dense but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description explains the return payload thoroughly and covers the most important edge case (empty result meaning). It addresses scoping across ad_group, campaign, and account levels, and mentions the 1000-criterion cap. For a read-only list tool with 3 optional params, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so baseline is 3. The description adds the 'capped at 1000 criteria' limit and explicitly states that ad_group_id and/or campaign_id can be combined or omitted, which enriches the schema's individual descriptions. This pushes it above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Lists explicit demographic criteria (age range, gender, parental status, household income) set on ad groups.' It uses a specific verb ('Lists') and resource ('demographic criteria on ad groups'), distinguishing it from sibling tools like location_targeting_list or audience_targeting_list by enumerating the exact demographic types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on scoping: 'Scope with ad_group_id and/or campaign_id, or omit both for the whole account (capped at 1000 criteria).' It also clarifies the meaning of an empty result. However, it does not explicitly mention when to prefer this over alternative targeting-list tools, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: mutating side effect, non-reversibility, return format (criterion_ids keyed by input position), and duplicate rejection by Google Ads. This goes well beyond the schema and gives the agent essential execution expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct purpose: main action, return behavior, side-effect warning with actionable guidance. No fluff, information is front-loaded and efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values and key constraints. It covers duplicate handling and rollback, which are critical for a mutation tool. Minor omissions like failure modes or partial success are not disclosed, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions of keywords, ad_group_id, and customer_id. The description adds minor context (e.g., single ad group, keyed by position) but does not substantially enhance parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource: 'Adds one or more keyword criteria to a single ad group.' This clearly distinguishes it from siblings like google_ads_keywords_remove, pause, list, and suggest. The tool's purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: mentions calling google_ads_keywords_cross_adgroup_duplicates first when adding at scale due to duplicate rejection, and recommends recording before-state with mureo_state_action_log_append for rollback. This gives clear when-to-use and when-to-use-alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 explicitly states 'Read-only; generates an action plan but does not execute anything' and 'The evaluation window is hardcoded to LAST_7_DAYS.' It also discloses null behavior for search_term_quality when clicks==0, which is valuable behavioral context beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long due to the detailed return object, but it is front-loaded with the purpose and every major section (output shape, hardcoded window, read-only, alternatives) earns its place. It is dense but structured with clear field names, though it could be slightly more scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex diagnostic tool with no output schema and no annotations, yet the description includes the full return structure, status enum, null condition, hardcoded period, and related tool pointers. It is nearly self-sufficient for an agent to invoke correctly and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% parameter description coverage; campaign_id and customer_id are both fully described with examples and fallback behavior. The description itself adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Diagnose a Google Ads campaign that is not acquiring conversions' and enumerates the diagnostic dimensions (tracking config, bidding alignment, funnel, delivery, search terms). It also explicitly distinguishes itself from sibling tools by naming google_ads_monitoring_cpa_goal and google_ads_monitoring_cv_goal as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: hardcoded LAST_7_DAYS window, read-only behavior, and explicit alternatives for CPA and CV-count monitoring. This tells the agent when to use this tool and when to use a different one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Read-only,' explains failure behavior ('Any subcomponent that fails is replaced with the string 'Retrieval failed' rather than aborting'), details default period, and specifies optional return fields (e.g., cpa_current? only when conversions > 0). This is thorough and transparent beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, starting with purpose, then return shape, failure handling, and alternatives. While it's a single paragraph, each sentence adds essential information, and the return shape is packed into a concise structure. Slight deduction for lack of formatting (e.g., bullets) but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description comprehensively documents the entire return shape, including nested objects, optional fields, and conditions. It also explains error recovery behavior, period defaults, and tool alternatives. This is complete for a complex analysis tool with no structured output definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 tool description adds no new parameter meaning beyond what the schema already contains—e.g., the 'tuned for short-horizon comparison' note appears verbatim in the schema's period description. The description simply restates schema details rather than enriching them, so no score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb 'Diagnose' and a single resource ('a single Google Ads campaign'), and enumerates the composed components (current-vs-previous comparison, top search terms, Google recommendations, recent change history). It also distinguishes itself from sibling tools by naming alternatives for different use cases, ensuring no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided by defaulting to LAST_7_DAYS and recommending longer baselines for extended comparison. Moreover, it clearly states when to use alternative tools: 'For cost-spike root-cause analysis use google_ads_cost_increase_investigate; for account-wide health use google_ads_health_check_all.' This is direct when-to-use vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it is mutating, new schedules default to start_minute/end_minute=ZERO, reversibility is only via inverse operations, and the return format is described as one entry per operation with adds first then removes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main action, and every sentence adds value: purpose, return format, behavioral default, reversibility, prerequisites, and alternative tool. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich schema and the description covering return format, prerequisites, and alternatives, the context is largely complete. It could additionally address partial failure behavior or idempotency, but these are minor gaps for a mutate tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the description does not need to add much. It does reinforce the anyOf constraint (at least one of add_schedules/remove_criterion_ids) and adds the minute default behavior, but otherwise relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Add and/or remove ad-schedule criteria on a Google Ads campaign in a single mutate.' This specifies the action, resource, and scope, and distinguishes it from the read-only sibling by explicitly naming 'google_ads_schedule_targeting_list'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when-to-use guidance, including the prerequisite that at least one of add_schedules/remove_criterion_ids must be provided, and directs users to the read-only alternative: 'For the read-only listing use google_ads_schedule_targeting_list.' It also references source tools for parameter values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly discloses that the operation is mutating and not automatically reversible, advises recording before-state for rollback, and explains the evaluation/firing behavior. This is thorough for a create operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (four sentences), front-loaded with the primary action, and every sentence provides essential information: what it does, return value, mutation warning/rollback guidance, common patterns, and a pointer to documentation. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with nested objects and no output schema, but the description, combined with the detailed input schema, covers the essential aspects: creation behavior, return value, mutation implications, and high-level usage patterns. It omits some details about rule construction, but appropriately defers to Meta docs, making it sufficiently complete for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds value by explaining that evaluation_spec and execution_spec follow Meta's JSON schemas, pointing to external docs, and providing concrete execution types via common patterns. This enhances understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new Automated Rule, specifies the resource, and distinguishes from sibling tools (update/list/get/delete). It also mentions the return value (rule_id) and common patterns, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage patterns (CPA-spike alert, auto-pause, scale winners) which helps in deciding when to use this tool. However, it does not explicitly contrast with alternatives like update or delete, though the name implies creation. No exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses mutating side effects, non-reversibility, rollback suggestion, the 24–72h build delay, the fact that approximate_count remains 0 until build finishes, and the practical meaning of ratio values. This is rich behavioral context beyond what schema alone would tell the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is six sentences, each with a distinct purpose: purpose, return value, mutation warning, timing behavior, ratio semantics, and alternative tool. It is front-loaded and avoids redundancy. Every sentence earns its place, making it dense yet efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no output schema or annotations, the description covers the critical aspects: what it creates, what it returns, timing, ratio ranges, and rollback guidance. It is nearly complete, though it omits potential error scenarios (e.g., invalid source audience) and account_id fallback behavior, which are only in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds extra value by interpreting ratio in concrete terms ('top 1% most similar users in the target country (smallest, highest match)') and giving a recommended source size (1,000–10,000 users). It does not rehash every parameter but clarifies the most behaviorally significant ones.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Creates a Lookalike Audience from an existing source audience.' It also states the return value (audience_id), which clarifies the tool's core function. It is clearly distinguished from siblings like meta_ads_audiences_create (custom audience) and meta_ads_audiences_list (listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names an alternative for a different need: 'For the base audience list use meta_ads_audiences_list.' It also advises recording before-state with mureo_state_action_log_append for rollback, implying when to consider safety. However, it does not explicitly state when to avoid this tool or when a custom audience would be preferred over a lookalike.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the transparency burden. It states 'Read-only,' which covers mutability, and describes the return format explicitly. It adds practical context like 'rolling time window' and the purpose of detecting pixel breaks, but does not mention potential errors, rate limits, or timezone behavior. Still, the core behavioral traits are well disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: first the main action, then the output format, then usage guidance, then an alternative. Each sentence earns its place with no filler or repetition. It is ideal for an agent to scan quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description compensates by explicitly stating the row structure. It also defines a clear use case and points to a related sibling. Minor gaps remain (e.g., timezone, date granularity, pagination), but for a monitoring/reporting tool of this complexity, the description gives enough context for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by noting that longer periods 'cost more Graph API quota but are necessary to spot slow degradations,' which is useful operational semantics not present in the schema. The rest of the parameters are already well described in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Returns aggregated pixel-event counts over a rolling time window.' It also states the exact output shape ('array of {date, event_name, count} rows') and explicitly distinguishes itself from the sibling meta_ads_pixels_events, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete guidance: 'Use this to spot unusual drops in PageView / Purchase / Lead volume that indicate a pixel break.' It also identifies an alternative tool for different needs: 'For per-event metadata ... use meta_ads_pixels_events instead.' This clearly tells the agent when to choose this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 critical behaviors: the empty default doc when the file is absent, server_now as the authoritative clock and the warning not to write it back, the precise semantics of each action_log scope, and the inclusion of action_log_scope/action_log_total markers. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core purpose. Every sentence provides necessary context (server_now semantics, log filtering, markers). It is somewhat dense and partially repeats schema details, but remains efficient for the complexity involved. A 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain return values. It covers all major fields (version, last_synced_at, platforms, legacy campaigns, action_log, server_now) and edge cases (absent file, filtered log markers). It also explains the index field and how to close pending entries. This is fully complete for a read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantic detail beyond the schema: it explains the 'byte-identical' legacy behavior of 'all', clarifies what 'pending' includes (past-due and future-due), and describes the index field for closing entries. This extra context earns a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Read STATE.json and return its parsed v2 document' and enumerates the exact contents (version, last_synced_at, platforms, legacy v1 campaigns, action_log). This clearly distinguishes it from sibling mutation tools like mureo_state_upsert_campaign and mureo_state_action_log_append.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 action_log filter, stating 'pending' is 'for the daily-check evidence loop.' However, it does not explicitly contrast this tool with alternatives or state when not to use it, so it falls short of an explicit when/when-not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly says 'Read-only' and describes the response structure ('raw rows array', 'Empty array when no data'), which are key behavioral traits. It does not mention authentication requirements or potential API errors, but the schema covers property verification. The disclosure is solid but not exhaustive, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose and response format, followed by read-only status and usage/alternative guidance. Every sentence earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex with 6 parameters and no output schema, so the description's explanation of the return format is valuable. It covers main use cases and directs to sibling tools. It could mention row_limit or pagination behavior, but the schema already covers row_limit. Overall, complete enough for effective selection and invocation; a 4 fits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by giving concrete dimension-use examples ('Use dimensions=['query'] for keywords, ['page'] for URLs' etc.) and by clarifying the output shape's 'keys' field maps to requested dimensions. This goes beyond the schema's field descriptions, warranting a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries the Search Console Search Analytics API for organic Google Search performance data, with a specific verb ('Query'), resource, and scope. It also differentiates itself from sibling convenience tools by explicitly naming search_console_analytics_top_queries, top_pages, device_breakdown, and compare_periods as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it recommends which dimension to use for keywords, pages, devices, and daily trends, and explicitly points to sibling tools for convenience shortcuts and period comparisons. This clearly tells the agent when to use this raw query tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It goes beyond a simple return statement by revealing the source path (./BRAND_KIT/kit.yml) and the fallback behavior (tasteful neutral defaults with 'defaults_used' set to true). This is important context that wouldn't be obvious from the schema or tool name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, but every part earns its place: the first sentence states the primary purpose and contents, the second addresses the default behavior and usage context. It is front-loaded and free of any filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema, no-annotation tool, this description is fully sufficient. It explains what is returned (the kit contents), the source, the edge case of no kit, and when to use it. There are no unresolved gaps that would leave an agent confused about how to invoke or interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters because there are none, and it appropriately focuses on the return value. No additional parameter-related meaning is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the brand kit (colours, fonts, logo path, clear-space) from a specific file, which immediately distinguishes it from sibling creative tools like compose, generate_visual, and edit_visual. The verb 'return' and resource 'brand kit' are precise, and there's no ambiguity about what is retrieved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit usage directive: 'Use this to judge brand fit before composing banners.' This gives clear context for when to invoke the tool. However, it does not mention when not to use it or suggest any alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description fully discloses behavioral rules: INSUFFICIENT_DATA threshold for impressions < 100, tie-breaking (all top-score ads get WINNER), the score formula (ctr*cvr or ctr), and read-only nature. This goes well beyond structured annotations and gives the agent reliable expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries essential information: purpose, verdict logic, return structure, read-only safety, and sibling alternatives. No filler or repetition; front-loaded with the primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description enumerates return fields and explains the scoring and verdict rules. It also states the read-only guarantee and differentiates from adjacent tools, making it self-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.
Parameters3/5
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 does not add syntax or format details beyond the schema, but the schema already provides rich guidance on ad_group_id, period, and customer_id. No further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Rank' and clearly identifies the resource: 'ENABLED ads within a single Google Ads ad group' while assigning verdicts. It is unmistakably distinct from sibling tools like google_ads_ad_performance_report and google_ads_rsa_assets_analyze, which are explicitly called out as alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for use: it scopes comparison to a single ad group and is read-only. It names alternatives for cross-ad-group reporting and RSA asset-level analysis, giving 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of disclosure. It clearly states the tool is mutating and not automatically reversible, advises recording before-state for rollback, explains the automatic image upload to ImageAssets, and discloses the failure mode on channel mismatch. This gives the agent a complete safety and behavior picture.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, each with a distinct and necessary role: purpose, image handling, return values, mutation/rollback warning, and alternative usage. It is entirely front-loaded with the core purpose and avoids redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (resource_name, id, generated asset IDs). It also covers the mutation warning, rollback path, and channel requirement. For an 11-parameter create tool, this is sufficient to invoke correctly even without output schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add meaning beyond the schema for parameters; it only restates that image paths are local and uploaded automatically, which the schema already details per-field. No additional semantic value for parameters is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Creates a Responsive Display Ad (RDA) in a DISPLAY campaign's ad group.' It clearly distinguishes itself from sibling google_ads_ads_create for Search campaigns, so an agent can correctly match intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use an alternative: 'For Search campaigns use google_ads_ads_create.' Also gives a hard precondition: the ad_group must belong to a DISPLAY campaign or the call fails with a channel-mismatch error, which is crucial for avoiding failed invocations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects and behavior. It says 'Lightweight — writes only the status field and does not reset learning signals,' 'Returns the ad ID and new status,' and 'Reversible via rollback_apply.' These details go beyond the schema and give critical context about the tool's impact and reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the core purpose and followed by key behavioral notes and usage guidance. Every sentence serves a purpose with no redundancy or filler. Ideal length for this tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple status update with four well-documented parameters and no output schema. The description covers purpose, side effects, return value, and alternative tool usage, making it complete for an agent to select and invoke correctly. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully described in the input schema. The description adds no extra parameter information beyond what the schema provides (e.g., it doesn't elaborate on customer_id or ad_group_id). Baseline of 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Sets the delivery status of a single ad to ENABLED, PAUSED, or REMOVED.' This clearly states the tool's function and enumerates valid values, making it distinct from siblings like google_ads_ads_update, which is explicitly differentiated later.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides direct usage guidance: 'Use this for pause/resume; use google_ads_ads_update to change the creative copy itself.' This explicitly tells when to choose this tool over an alternative, satisfying the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description fully carries the behavioral transparency burden. It discloses the mutating nature ('creates a new Asset row'), the lack of a delete tool, validation limits (5 MB, file extensions), the side effect of reading from local filesystem and POSTing bytes, and the exact return shape. This is comprehensive and goes well beyond minimal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. Each sentence adds distinct value: return values, mutation caveat, validation, side effects, and follow-up tool. Despite being somewhat long, there is no wasted or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (file upload, validation, mutation, no deletion, local filesystem read) and no output schema. The description covers return values, side effects, constraints, and the next step to take. This is a complete picture for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptive text for all three parameters (100% coverage), so the baseline is 3. The description adds meaningful context beyond the schema by explaining the return format, default behavior for `name` (basename), and the credential fallback for `customer_id`. This elevation to 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Upload') with a clear resource ('local image file to Google Ads as an image Asset') and states its intended use ('for use in Responsive Display Ads or image extensions'). It is easily distinguished from sibling tools like google_ads_image_assets_list (listing) or meta_ads_creatives_upload_image (Meta platform).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: it notes the asset is for RDA/image extensions and directs the user to google_ads_ads_create_display for the next step. It doesn't explicitly state when not to use this tool versus other upload tools, but the mention of the no-delete limitation and the recommended follow-up gives practical usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It explicitly states 'Read-only', details the exact return format (single-entry list with fields and None/percentage values), describes failure responses with specific error keys, and discloses the API version limitation on competitor-level data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then proceeds through return format, error format, read-only note, API limitation, and alternative tool. Every sentence adds substantively distinct information; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers return values and error handling. It also explains the data limitation and points to a sibling tool. Combined with the well-documented input schema, the description provides a complete picture for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions, so baseline is 3. The description does not add additional parameter-level details beyond the schema, but the schema itself is rich (e.g., period guidance, customer_id fallback) and the description's mention of returned fields provides helpful output context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('raw impression-share metrics for one Google Ads campaign'), clearly distinguishing it from sibling google_ads_auction_insights_analyze by calling it 'raw' and explicitly pointing to the analyze tool for human-readable insights.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative tool ('For a version with human-readable insights layered on top use google_ads_auction_insights_analyze') and explains the API v23 limitation, helping agents decide when raw impression-share proxies are sufficient versus when to use the richer analysis tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It states 'Read-only' and details the return structure, including the exact shape and quirks like device_type being 'UNKNOWN(<n>)' for non-DEVICE rows. This goes beyond basic safety to explain behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by a compact return type specification and two short alternative pointers. Every sentence contributes useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully explains the returned objects, including enum values and edge cases. It covers alternatives, read-only nature, and scope, making it complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having detailed descriptions (e.g., campaign_id format and fallback behavior for customer_id). The tool description adds no extra parameter-level insight, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'List every campaign_criterion row that has a non-null bid_modifier on a Google Ads campaign.' It clearly distinguishes from siblings by naming alternatives for device-summary and location-only views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'when to use' guidance is provided: 'For the device-summary view... use google_ads_device_targeting_get. For location-only use google_ads_location_targeting_list.' This gives clear exclusions and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 mutating nature, FieldMask-based partial update (only bid_modifier), preservation of other fields, reversibility, ValueError on out-of-range values, and the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each carrying essential information: action, return value, mutating behavior, constraints, and sibling distinction. It is front-loaded and avoids unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking annotations and output schema, the description fully covers what the tool does, its side effects, validation constraints, error behavior, and the key sibling alternative. This is enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 adds useful context about the bid_modifier range and 0.0 rejection, but this mostly mirrors the schema's own parameter descriptions rather than adding new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Update the bid_modifier of a single campaign_criterion,' giving a specific verb and resource. It also distinguishes this tool from google_ads_device_targeting_set by explicitly rejecting bid_modifier 0.0 and directing users to that sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly names an alternative for device toggling: 'To toggle a device on/off with bid_modifier 0.0 use google_ads_device_targeting_set instead (this tool rejects 0.0).' 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes full responsibility for behavioral disclosure. It explicitly states 'Read-only' and provides detailed algorithmic rules for each suggestion category (e.g., 'Device fires MEDIUM when Mobile CPA > Desktop CPA * 1.3'), plus the return structure. This exceeds typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence serves a purpose: it summarizes the checks, specifies the return object, gives trigger conditions, declares read-only, and states when to use alternatives. It is front-loaded and free of padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description fully specifies the return structure and value domains. It explains all three check categories, their triggers, and usage context. Combined with the detailed input schema, the description is complete for an agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not discuss parameters directly, but schema coverage is 100% with rich descriptions (e.g., period usage guidance, campaign_id format, customer_id fallback). Per the rubric, baseline is 3 for high schema coverage; the description adds no additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Run') with a clear resource ('B2B-specific optimization checks against a Google Ads campaign') and enumerates the exact checks (schedule, device CPA disparity, informational-query ratio). It distinguishes itself from generic diagnosis tools by explicitly naming google_ads_performance_analyze as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states exactly when to use this tool ('when the advertiser self-identifies as B2B') and provides an explicit alternative for general cases ('For general campaign diagnosis use google_ads_performance_analyze'). This gives the agent both a clear trigger and a fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly covers edge cases: short-circuit response when no campaigns have spend (including omitted total_freed key), skipping reductions below 100 currency units, fallback to 0 on budget fetch failures, and the read-only nature. This is far beyond typical transparency and leaves little ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately long but every sentence earns its place. It front-loads the core purpose, then covers return structure, edge cases, fallback behavior, read-only nature, and alternative tools. No fluff or redundancy; the density is justified by the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains the return payload structure, including the shape of reallocation_plan items, the short-circuit variant, and the omitted total_freed key. It also explains internal dependencies (get_budget) and error fallback. For a complex tool with no structured output schema, this is exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with descriptions for both parameters, including detailed guidance on period selection and customer_id fallback. The main description does not add additional parameter-specific semantics beyond what the schema provides, so the baseline of 3 is appropriate. The few parameter mentions in the description are behavioral, not semantic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Propose a budget reallocation plan') with a clear method (cutting up to 20% from INEFFICIENT campaigns and distributing across EFFICIENT campaigns). It also distinguishes itself from siblings by explicitly naming google_ads_budget_update and google_ads_budget_efficiency as alternatives. This is a clear, specific verb+resource+method.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool vs alternatives: 'To actually apply a change use google_ads_budget_update; for the efficiency scoring alone use google_ads_budget_efficiency.' It also clarifies that the tool is read-only and only plans, which is strong when-to-use guidance. No exclusions are needed beyond the alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly warns that the operation is mutating and not automatically reversible, explains that shared budgets affect all campaigns, reveals the currency-unit (not micros) gotcha, and notes the immutable period constraint. This goes well beyond a bare 'update' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although the description is longer than average, every sentence conveys essential operational detail: the action, mutability warning, return value, shared-budget side effect, unit clarification, and API period limitation. There is no filler or redundant explanation beyond critical safety-relevant facts.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is remarkably complete. It explains the return value, side effects, required pre-checks, and API constraints. For a mutating tool with six parameters and multiple edge cases (shared budgets, period types, micros vs. currency), this description leaves little ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage, including currency units, mutual exclusivity, and CUSTOM_PERIOD restrictions. The description adds no new parameter-specific meaning beyond echoing key points (e.g., amount not in micros), so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Sets the daily and/or total amount on an existing campaign budget.' This clearly distinguishes it from budget creation (google_ads_budget_create) and retrieval (google_ads_budget_get) by emphasizing 'existing' and enumerating the exact update targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and preconditions: checking reference_count with google_ads_budget_get before modifying shared budgets, and recording prior state with mureo_state_action_log_append if rollback may be needed. It also states a hard constraint—total amounts only apply to CUSTOM_PERIOD budgets—providing a clear when-not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility and excels: it discloses the two-step mutate, return value/error structure, reversibility, duplicate asset creation on identical text, and the campaign limit. This is comprehensive behavioral disclosure beyond any structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the core action first, then return behavior, error case, reversibility, duplicate caveat, and alternative tool. Every sentence is informative and earns its place, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains return values (resource_name, error object) and covers all necessary operational details: mutation, limits, duplicates, and alternatives. It is fully complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters fully described in the input schema. The description adds no additional parameter-level meaning, so the baseline of 3 is appropriate. It does enrich context about duplicates/limits, but that is behavioral, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create a callout Asset and link it to a Google Ads campaign') with a specific verb and resource. It also distinguishes itself from sitelink creation by naming the alternative tool, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus alternatives ('For sitelink variants use google_ads_sitelinks_create'), notes reversibility via google_ads_callouts_remove, and highlights the 20-callout limit as a constraint. This gives the agent clear decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It states the tool is 'Read-only,' notes that it only scans campaign_asset rows (no account-level merge), and reveals a hardcoded limit of 20 callouts per campaign. These are meaningful behavioral traits beyond basic read/write classification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three succinct sentences with no filler. It front-loads the core action and return format, then adds differentiation and usage guidance efficiently. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description specifies the exact return format ([{id, resource_name, callout_text}]). It also includes operational context (read-only, audit before create/remove, hardcoded limit) and sibling differentiation. This is complete for a straightforward list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: campaign_id is described as a numeric string without dashes and obtainable via google_ads_campaigns_list, and customer_id includes fallback behavior. The description adds no extra parameter meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List callout extension assets linked to a Google Ads campaign.' It also distinguishes itself from the sibling tool google_ads_sitelinks_list by clarifying that it only scans campaign_asset rows without account-level merge, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this to audit coverage before calling google_ads_callouts_create or google_ads_callouts_remove.' It also contrasts with google_ads_sitelinks_list, giving clear guidance on when this tool is appropriate versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses that the tool is mutating, counts against daily write quota, is not automatically reversible, and returns resource_name and id. This goes well beyond a bare 'creates campaign' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: action and return, mutation warning, quota, non-reversibility, rollback pointer, prerequisite, and follow-up alternatives. The description is front-loaded with the core purpose and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with a rich schema and no output schema, the description fully covers return shape, preconditions, side effects, and subsequent actions. It addresses the key operational concerns (quota, reversibility, budget creation, later edits) and leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with detailed descriptions and enums, so the baseline is 3. The description adds the prerequisite relationship for budget_id and mentions channel types, but otherwise duplicates the schema's parameter documentation. No significant extra parameter semantics are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a new Search or Display campaign' – a specific verb, resource, and scope. It clearly distinguishes itself from update/status siblings and from ad group creation tools, and even names the update tools for later edits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the budget_id prerequisite and directs users to google_ads_budget_create if missing. It also gives explicit alternatives for later edits (google_ads_campaigns_update or google_ads_campaigns_update_status) and advises recording before-state via mureo_state_action_log_append for rollback, which is clear when-to/not-to guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses that the operation is mutating and not automatically reversible, and suggests recording before-state for rollback. However, it does not detail required permissions or other side effects, so not 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no fluff. Each sentence adds unique value: action, partial update behavior, mutability warning, and alternative tool recommendation. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description sufficiently covers return value, partial update behavior, rollback guidance, and alternative usage. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 valuable partial-update semantics—only fields provided are changed, omitted fields are preserved—which clarifies how all parameters behave beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Updates one or more settings on an existing campaign' with a specific verb and resource. It also differentiates from the sibling tool by explicitly noting that status-only changes should use google_ads_campaigns_update_status instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: for status-only changes, prefer the lighter-weight google_ads_campaigns_update_status. Also explains partial update semantics, giving the agent context on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It fully covers behavioral traits: writes only the status field, returns the campaign ID and new status, supports rollback for ENABLED ↔ PAUSED, and explains that REMOVED is a soft delete reversible within 30 days. This gives an agent clear expectations of side effects and reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: function, scope/return, reversibility, and usage guidance. It is well-structured and free of redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, no output schema, and no annotations, the description provides all necessary context: what it does, what it returns, how it can be reversed, and when to use it. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured parameter descriptions already handle parameter semantics. The description adds context that only the status field is written, but it does not elaborate on campaign_id or customer_id beyond what the schema provides. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Sets the delivery status of a single campaign to ENABLED, PAUSED, or REMOVED.' It clearly identifies the resource (campaign status) and the allowed actions, and it distinguishes this tool from siblings by contrasting it with google_ads_campaigns_update, which handles other settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes direct usage guidance: 'Use this for pause/resume; use google_ads_campaigns_update to change name, bidding, or other settings.' It also mentions the lightweight scope ('writes only the status field') and reversibility considerations, making it easy for an agent to decide when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool is 'Mutating', persists the action with 'status ENABLED by default', returns a resource_name, and is reversible via specific methods. Also reveals constraints like name length and default category, showing substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each earning its place: purpose, return value, mutating/persistence, reversibility, constraints, and alternative tool. Front-loaded with the primary action, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter create tool with no output schema, the description fully covers what the tool does, what it returns, its side effects, defaults, and pointer to update. Combined with rich schema descriptions, this is complete 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.
Parameters3/5
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 a couple of defaults (status, category) but those are already in the schema. It does not meaningfully enhance parameter semantics beyond what the schema already states, so no higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new Google Ads conversion action' — a specific verb and resource. It clearly distinguishes from siblings by explicitly mentioning google_ads_conversions_update for updates and noting reversibility via remove, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: use for creating new conversion actions, and for updating existing ones 'use google_ads_conversions_update'. Also states lifecycle/reversibility options (update with REMOVED or remove), giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 read-only nature, return shape (id, name, type, status, category), null-when-no-match behavior, and limitations (excludes value settings/lookback-window). This is highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, front-loaded with the primary purpose, followed by return details, limitations, and alternatives. Every sentence contributes unique value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-ID tool, the description covers return values, null case, exclusions, and sibling alternatives. Without an output schema, it sufficiently explains expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters have detailed descriptions in the schema. The description adds only minor reinforcement ('by numeric ID'), so it doesn't exceed the baseline for well-documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Fetch one conversion action's configuration from Google Ads by numeric ID.' It clearly distinguishes from siblings by naming google_ads_conversions_list for full listings and google_ads_conversions_tag for tag snippets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use alternatives: 'use google_ads_conversions_tag' for embed snippets, 'use google_ads_conversions_list' for full listings, and 'use the Google Ads UI' for value settings/lookback-window values. This provides clear when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only', details the exact return shape with fields and enum values, and notes ordering by numeric id. This gives the agent a clear picture of side effects and output without needing to invoke.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses three sentences, each with distinct purpose: action/scope, return structure, and usage guidance. No filler or redundancy exists; every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though there is no output schema, the description specifies the return array fields, types, and example enum strings, covering the output contract. It also addresses ordering, read-only behavior, and usage context, making it fully self-contained for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, customer_id, is fully described in the schema with type, format, and fallback behavior (100% coverage). The tool description adds no additional parameter-specific meaning, so it remains at the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List every conversion action configured on the Google Ads customer, ordered by numeric id', specifying a concrete verb, resource, and scope. It distinguishes itself from sibling tools by being the list variant for conversions, as opposed to .get, .create, .update, .remove, or .tag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to discover conversion_action_id values before calling .get, .update, .remove, or .tag' and 'For CV performance metrics use google_ads_conversions_performance', giving both when-to-use and a clear alternative. This directly guides tool selection among conversion-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses destructive nature, that historical data persists, that conversions stop counting, and that re-enabling is possible via an update. It also states the return value. This is thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with every sentence carrying essential information: operation, return value, destructive effect, and alternative. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with simple parameters, the description covers purpose, effects, return, recovery path, and alternative. No critical gaps remain even without an output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, with clear descriptions in the schema. The tool description doesn't add new parameter-level details, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Archive (status=REMOVED) a Google Ads conversion action', which clearly identifies the verb and resource. It also distinguishes itself from sibling update tool by contrasting status=REMOVED with status=HIDDEN.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative: 'For soft-hide that keeps the row visible use google_ads_conversions_update with status=HIDDEN.' It also explains re-enabling via google_ads_conversions_update, giving clear when-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does well: it discloses the mutating nature, partial update behavior (only passed fields modified), the ValueError when no updatable field is supplied, and the return value. However, it stops short of mentioning potential side effects like permanent changes or required permissions, which would make it 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no redundancy. It front-loads the core action, then explains partial update behavior and the required-field error condition, and finishes with the deletion alternative. Every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 9 parameters, 100% schema coverage, and no output schema, the description covers all essential aspects: what it does, how it behaves (partial update), when it fails (missing updatable field), what it returns, and how to achieve deletion. No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already defines all parameters. The description adds value by clarifying that at least one updatable field must be supplied, a constraint not evident from the schema's required array, and explains 'REMOVED' status semantics in relation to deletion. This goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing Google Ads conversion action', making the tool's purpose obvious. It also distinguishes from siblings like google_ads_conversions_create and google_ads_conversions_remove by specifying partial update semantics and linking to the remove tool for deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use this tool (update existing conversion actions) and provides an alternative for deletion: 'To delete/archive an action use status 'REMOVED' here or call google_ads_conversions_remove.' This clear guidance on when not to use it (full removal) and naming the alternative tool earns a top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral transparency burden. It discloses that the tool is read-only, excludes days with zero clicks from the GAQL, defines the exact thresholds for 'rising' and 'falling' (>+1% / <-1%), and details the conditional presence of change_rate_per_day_pct. It also specifies insight-triggering conditions (week-over-week surges >15%, days exceeding 2x average CPC), going far beyond basic safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: opening purpose, full return schema, classification rules, data exclusions, insight criteria, and alternative tools. Every sentence contributes valuable information without redundancy or fluff, making it an efficient and well-organized description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and absence of an output schema, the description is remarkably complete. It details the exact return structure, including nested daily_data and trend objects, defines all possible direction values, explains data exclusions, and documents insight thresholds. It also provides sibling alternatives, making the tool's context fully understandable without needing additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes all three parameters with examples and guidance (e.g., period enum descriptions). Since schema coverage is 100%, the baseline is 3. The description does not add parameter-specific syntax or format details beyond what the schema provides, so it earns the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Detect rising/falling CPC trends in a Google Ads campaign over a reporting window using daily segmentation and linear regression.' It clearly defines the tool's analytical scope and method, and distinguishes it from sibling tools by explicitly naming alternatives for device/auction investigation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus related alternatives: 'For device or auction-share investigation use google_ads_device_analyze or google_ads_auction_insights_analyze.' It also states the tool is read-only and defines the thresholds that trigger insights, giving clear context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and succeeds. It discloses a side effect ('one outbound LP fetch (same SSRF policy as google_ads_landing_page_analyze) plus several GAQL queries') and a failure-handling behavior ('Any failing sub-step is replaced with the literal string 'fetch_failed' so the envelope never raises'). This gives the agent critical expectations about safety, reliability, and non-raising behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence (and even clause) contributes meaningful information: purpose, return shape, failure behavior, side effects, and alternatives. There is no fluff or repetition. The structure is compact despite the complexity, and it front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a complex composite tool with no output schema, so the description must compensate by fully explaining the return value, and it does so with a detailed inline JSON-like structure. It also covers side effects, failure semantics, and alternatives. For a tool of this complexity, the description is complete enough for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter (id, URL, ad_group_id, customer_id) is already well documented in the schema. The description adds no additional parameter-level semantics beyond what the schema states; it focuses on output structure. Per the rubric, baseline 3 applies when schema does the heavy lifting, and there is no extra value here to push higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Collect every input an LLM needs to draft or refresh Google Ads creative for a single campaign.' It enumerates the exact contents of the return object, making the tool's scope unmistakable. It also distinguishes itself from siblings by naming google_ads_landing_page_analyze and google_ads_rsa_assets_analyze as more targeted alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool versus alternatives: 'For just the LP use google_ads_landing_page_analyze; for just RSA asset diagnostics use google_ads_rsa_assets_analyze.' It also frames the tool as a single-campaign creative research aggregator, clarifying the intended use case. This is the gold standard for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 explicitly states 'Read-only,' describes the exact return shape including edge cases (cpa is None when conversions == 0, empty devices list with a message field when no data), and discloses insight trigger conditions. This is comprehensive behavioral disclosure beyond what a schema could offer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is packed with essential information—purpose, return structure, edge cases, sorted order, insight conditions, and alternatives—all in a compact paragraph. Every sentence earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and only a 3-parameter input schema, the description fully compensates by specifying the return object structure, sorting, and edge-case behavior. It also covers the tool's place among siblings, making it complete for an AI agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself provides detailed parameter semantics (default period, campaign ID format, fallback for customer ID). The tool description adds no parameter-specific guidance, so the baseline score of 3 is appropriate—it neither harms nor adds beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Compare Google Ads campaign performance across device segments (Desktop / Mobile / Tablet).' It clearly distinguishes from sibling tools by naming alternatives for bid adjustments and schedule targeting, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives: 'For applying device bid modifiers use google_ads_bid_adjustments_update or google_ads_device_targeting_set; for the raw ad-schedule criteria ... use google_ads_schedule_targeting_list.' This provides direct exclusions and alternatives, leaving no doubt about use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, but the description fully details return order, exact field shapes, null behavior for criterion_id, and the non-obvious enabled/bid_modifier=0.0 convention. This goes far beyond basic disclosure and prevents misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences pack purpose, return contract, edge-case semantics, and alternatives with zero filler. The description is front-loaded with 'Get the device targeting state' and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully specifies the return shape, ordering, and the mureo convention for enabled=False. Combined with thorough schema descriptions, the tool is completely self-contained for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers both campaign_id and customer_id with examples and fallback behavior (100% coverage). The description adds no extra parameter semantics, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get the device targeting state for a Google Ads campaign' with a specific verb and resource. The description also distinguishes from modification siblings by explicitly naming google_ads_device_targeting_set and google_ads_bid_adjustments_update for changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'For modifying, use google_ads_device_targeting_set or google_ads_bid_adjustments_update,' providing direct alternatives. The read-only label and campaign-specific scope clarify exactly when to invoke this getter versus other targeting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it iterates devices individually (failure tolerance), performs UPDATE/CREATE operations, returns a structured result including error strings, and raises ValueError on empty enabled_devices. This goes beyond basic mutation and clearly describes error handling and 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense, with every sentence providing valuable behavior or context. It is front-loaded with the primary action, followed by return structure, mutability, and alternatives—all in a compact paragraph with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description is complete for a mutation tool: it explains the operation, return value shape, error handling, reversibility, edge case (empty array), and points to a related tool for other use cases. This covers all the context 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add significant parameter semantics beyond the schema—it repeats the empty-array constraint and bid_modifier behavior that are already in the enabled_devices schema description. No additional meaning is provided for campaign_id or customer_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Toggle device delivery on a Google Ads campaign by setting bid_modifier=1.0 on enabled devices and 0.0 on disabled ones.' This is a specific verb+resource combination that distinguishes it from sibling tools like google_ads_device_targeting_get (get vs. set) and explicitly points to google_ads_bid_adjustments_update for a different use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use an alternative: 'For fine-grained non-zero bid modifiers use google_ads_bid_adjustments_update.' It also implies when to use this tool (toggle devices on/off) and mentions reversibility by calling the tool again, helping the agent decide between similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Read-only', describes the detailed return payload (counts, categories, diagnostics), and discloses the diagnostic limit of 5 campaigns. This provides complete transparency about what the tool does and does not modify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: it opens with the action, enumerates the return structure, states read-only, and lists alternatives. Every sentence serves a purpose, and the semicolon-separated return structure compactly conveys the output schema in the absence of a structured output definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully specifies the return shape, including category definitions, diagnostic fields, and ordering rules ('problem-first, then warning'). It also covers the optional-customer_id behavior via the schema and gives clear usage boundaries (up to 5 campaigns). This is a complete picture for a read-only health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully covers the only parameter (customer_id) with a clear description, achieving 100% schema coverage. The tool description adds no additional parameter semantics beyond the schema, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Screen every campaign') and resource ('Google Ads account'), defining the exact scope and diagnostic limit ('up to 5 problem/warning campaigns'). It clearly distinguishes itself from sibling tools by naming google_ads_campaigns_diagnose and google_ads_monitoring_cpa_goal as alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: for account-wide health screening by primary_status. It provides clear exclusions and alternatives: 'For single-campaign delivery diagnosis use google_ads_campaigns_diagnose; for CPA-goal monitoring use google_ads_monitoring_cpa_goal.' This gives the agent direct decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description declares 'Read-only' and details the output structure: grouped by severity buckets, each with criterion_id, text, ad_group_id, and a remediation hint. This fully discloses behavior and return format, exceeding the burden without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by specific output details and usage guidance. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fully explains return values and grouping, and the input schema covers parameters. The read-only nature, severity categories, and remediation hints make this self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters well-described, so the baseline is 3. The description adds no additional parameter-level meaning beyond what the schema provides, though it reinforces the campaign scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'reports quality-score and delivery-status issues across every keyword in a campaign,' using a specific verb and resource. It distinguishes itself from sibling tools like google_ads_keywords_list by focusing on diagnostic grouping by severity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends when to use it: 'Use this before pulling raw search-terms reports; it triages where attention should go,' naming the alternative tool category. This gives clear sequencing and purpose, satisfying the when-to-use criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure. It states the operation is non-destructive, preserves quality score and historical stats, returns criterion ID and new status, and is not automatically reversible. This is exemplary transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each adding meaningful information: purpose, non-destructive nature, return value, rollback advice, and sibling distinction. It is information-dense without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description covers the operation's purpose, effects, return value, reversibility, and alternatives. For a simple pause tool, it is fully self-contained and does not leave the agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 itself adds little about the parameters beyond what the schema already documents, but the schema descriptions are complete, so no deduction below baseline is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Sets the status of a single keyword criterion to PAUSED', which is a specific verb+resource+state. It distinguishes from the sibling google_ads_keywords_remove by explicitly recommending pause for temporary suspensions, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use this instead of google_ads_keywords_remove whenever the suspension might be temporary.' It also gives the resumption path via google_ads_keywords_add and advises recording before-state for rollback, making the when-to-use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: it is destructive, not automatically reversible, performs a soft-delete, returns the removed criterion_id, and warns that re-adding creates a fresh criterion losing quality score and learning. This goes beyond minimal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each providing critical information with no redundancy. It front-loads the primary action and result, then adds risk and alternative guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and lack of output schema, the description covers the key elements: what it does, what it returns, how to mitigate risk, and which alternative to use. It is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all parameters at 100%, so the baseline of 3 applies. The description does not add substantial parameter-level meaning beyond referencing that criterion_id comes from google_ads_keywords_list, which is already in the schema. No additional semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes (soft-deletes) a single keyword criterion from an ad group, with a specific verb and resource. It distinguishes itself from sibling tools like google_ads_keywords_pause and google_ads_keywords_add by clarifying the soft-delete nature and the contrast with pausing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use guidance is provided: it recommends preferring google_ads_keywords_pause for temporary suspension, and advises recording before-state with mureo_state_action_log_append for rollback considerations. This clearly differentiates from alternatives and states when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with no annotations, the description fully discloses the mutation behavior: adds create new criteria, removes delete by criterion_id, operations are executed with adds first then removes, and reversibility is only by calling the tool again with inverse operations. The return format (one entry per operation) is also specified, providing comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place. It is front-loaded with the core purpose, then covers return format, mutation semantics, reversibility, constraints, and input format details—all without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description is remarkably complete. It explains what the tool does, how operations are ordered, what the return value means, how to reverse changes, and how to format location IDs. Combined with the rich schema, the agent has everything needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all four parameters with 100% coverage, giving a baseline of 3. The description adds further value by clarifying the accepted ID formats for add_locations (bare numeric IDs or full paths, with auto-prefixing) and explains the relationship between parameters and the operations performed. This goes beyond the schema's individual property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Add and/or remove location criteria on a Google Ads campaign in a single mutate.' It specifies the resource (Google Ads campaign location criteria) and distinguishes the tool from the related listing tool (google_ads_location_targeting_list) by focusing on the update/mutation capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool by explaining the add/remove operations and the requirement that at least one of add_locations or remove_criterion_ids must be provided. It explicitly notes reversibility via inverse operations. While it doesn't name alternative tools explicitly, the schema references both google_ads_campaigns_list and google_ads_location_targeting_list for obtaining IDs, giving practical context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses critical behavior: hardcoded LAST_7_DAYS, read-only nature (does not change bids), status threshold logic, and edge cases (current_cpa None when conversions==0). It even reveals the integration of a full google_ads_cost_increase_investigate payload, which is far beyond typical descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense: a one-sentence purpose, a structured return-type list, and three brief clarifying statements (window, read-only, alternatives). Every sentence adds value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully specifies the return shape, status thresholds, the cost_analysis payload source, and optional suggested_workflow. It also explains the hardcoded window and alternate tools, making the tool fully understandable in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter has detailed descriptions (e.g., target_cpa thresholds, campaign_id format, customer_id fallback). The description itself adds no new parameter semantics beyond mentioning 'user-supplied target', so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific action: 'Evaluate a Google Ads campaign's last-7-days CPA against a user-supplied target and integrate cost-increase analysis.' It clearly identifies the resource, the metric, and the time window. It also distinguishes itself from sibling tools by naming google_ads_health_check_all and google_ads_monitoring_cv_goal for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides when-not-to-use guidance by stating 'For account-wide rollup use google_ads_health_check_all; for daily CV-count vs target use google_ads_monitoring_cv_goal.' It also notes the tool is read-only, which informs selection for side-effect-free analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It explicitly states 'Read-only,' discloses the hardcoded LAST_7_DAYS evaluation window, and details status thresholds and bottleneck routing logic. This goes well beyond minimal disclosure and gives the agent a clear picture of behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but exceptionally well-organized: it starts with purpose, then return payload, routing rules, hardcoded window, Read-only flag, and alternatives. Every sentence earns its place, and the structure makes complex logic digestible without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description fully enumerates the return structure, status values, bottleneck routing criteria, and evaluation window. It also covers the read-only nature and alternatives, leaving no critical gap for an agent to understand how to invoke and interpret the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 3 parameters with descriptions (100% coverage), so the baseline is 3. The tool description repeats some threshold semantics already in the schema (e.g., 'warning' at 80%) but does not add further parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Evaluate a Google Ads campaign's daily conversion rate') and clearly identifies the bottleneck identification purpose. It distinguishes itself from sibling tools by explicitly naming google_ads_monitoring_cpa_goal and google_ads_performance_analyze as alternatives for different evaluation types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit alternatives: 'For CPA-target evaluation use google_ads_monitoring_cpa_goal; for the underlying composite use google_ads_performance_analyze.' This clearly signals when to choose this tool over its siblings, satisfying the 'when/when-not/alternatives' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is read-only, returns a structured composite, defines exact status thresholds ('critical' when diagnostics issues/not ENABLED/impressions==0; 'warning' for warnings or impressions 1-9), and explains suggested_workflow setting. This goes well beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence carries essential information: purpose, return structure, status conditions, read-only flag, and alternative tool pointers. It is well-organized and front-loads the purpose before detailed logic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by fully specifying the return object, status conditions, and workflow behavior. It also situates the tool among related monitoring tools, making it highly complete for an agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both campaign_id and customer_id already well-described. The description does not add further parameter details, but the schema handles it, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Check whether a Google Ads campaign...') and clearly scopes the purpose to active delivery yesterday. It distinguishes from siblings by naming alternatives like google_ads_campaigns_diagnose and google_ads_monitoring_cpa_goal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus alternatives: 'For the raw diagnostics without the yesterday composite use google_ads_campaigns_diagnose; for CPA-target evaluation use google_ads_monitoring_cpa_goal.' This gives both usage context and exclusionary direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and delivers: it discloses the operation is 'Mutating — not automatically reversible,' advises recording before-state with mureo_state_action_log_append, and states the return behavior ('Returns created criterion_ids'). It also explains the broad impact across ad groups, which is important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences that front-load the purpose, then cover scope, return value, mutability/rollback, and the key alternative tool. Every sentence adds necessary information without padding or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description provides a complete picture: what it does, scope, return value, rollback guidance, and a named alternative. Combined with the full schema coverage, the agent has sufficient context to select and invoke the tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already contains detailed descriptions for all parameters, including match type semantics and customer_id fallback. The description reinforces campaign_id scope but does not add significant meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Adds one or more campaign-level negative keywords' and clarifies scope with 'These apply to every ad group in the campaign.' It clearly distinguishes from the sibling tool by naming google_ads_negative_keywords_add_to_ad_group, making the tool's purpose and boundary explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use context: campaign-level negatives for all ad groups, and explicitly directs users to google_ads_negative_keywords_add_to_ad_group for ad-group-level negatives. It even warns about the risk of over-blocking, giving clear guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It warns that the action is destructive ('exclusion is lifted immediately on the next serving cycle, which can increase unwanted traffic'), notes it is 'not automatically reversible', and suggests a rollback strategy via mureo_state_action_log_append. It also states the return value (criterion_id). This is exemplary transparency for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, return value, destructive warning, rollback advice, and scope limitation. It is front-loaded with the core action, and every sentence adds critical information without redundancy. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is remarkably complete. It covers the action, the return value, side effects, reversibility, and an edge case (ad-group-level negatives). There is no ambiguity about what the tool does, what it returns, or what risks are involved, making it fully self-sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with clear descriptions for all three parameters (campaign_id, customer_id, criterion_id). The description does not add new parameter-level detail beyond the schema, so it meets the baseline of 3. It does reinforce the campaign-level scope, which slightly aligns with the schema, but no extra semantics are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource+scope: 'Removes a single campaign-level negative keyword.' This clearly distinguishes it from sibling tools like google_ads_keywords_remove or google_ads_negative_keywords_add_to_ad_group by specifying 'campaign-level' and 'negative keyword'. It also states it returns the criterion_id, leaving no doubt about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (campaign-level negative keyword removal) and provides a when-not with an alternative: 'For ad group-level negatives there is currently no explicit remove tool — use the Google Ads UI or raise an issue if needed.' This tells the agent not to attempt ad-group-level removal with this tool and directs to the appropriate fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly discloses 'Read-only — suggestions are not applied,' which is critical behavioral context. It also details the return fields (text, suggested match_type, spend, conversions, rationale) and gives an example rationale. Minor gaps: no mention of rate limits or permissions, but given the non-mutating nature and clear return spec, this is very good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose, followed by output details and next-step guidance. Every sentence is informative with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only suggestion tool with no annotations and no output schema, the description is thorough. It covers input context, output content, safety profile, and follow-up actions. The period parameter and default behavior are already in the schema, so the description compensates well for missing structured fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining the semantic meaning of the target_cpa parameter ('waste spend relative to a target CPA') and illustrating the rationale format ('spend > 3x target CPA, 0 conversions'), which goes beyond the schema's field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyses recent search-term performance and returns suggested negative keywords that waste spend relative to a target CPA.' It uses a specific verb ('Analyses... returns') and specifies the resource (negative keywords), making it distinct from sibling tools like google_ads_keywords_suggest and google_ads_negative_keywords_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use this to identify wasteful negative keywords, and explicitly notes it is read-only with suggestions, directing users to google_ads_negative_keywords_add / add_to_ad_group to apply them. This clearly distinguishes when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mutating and delivery-affecting nature, warns about zero impressions, mentions action_log recording with observation window, and reversibility via rollback_apply removing exactly created criteria. This goes well beyond schema and compensates for absent annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, return values, effects/alternative. No filler; each sentence carries distinct, valuable information. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, scope, return values, side effects, reversibility, and tool differentiation. Given no output schema, the description adequately explains what to expect. Could mention customer_id fallback but schema already does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description adds return-value semantics (criterion_id, resource_name, etc.) but no additional parameter-specific guidance beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Excludes'), names the exact resource types (websites, mobile apps, mobile app categories), and clarifies scope (campaign or ad group level). It also distinguishes from sibling google_ads_negative_keywords_add by explicitly directing search-term exclusions there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the alternative tool: 'Exclude search terms with google_ads_negative_keywords_add instead.' Also implies use case: blocking placements at campaign/ad group level. Provides context for batching and scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fully specifies the output shape (one row per campaign/network), exact field names, the filtering of Display/YouTube/Discover rows, rounding behavior, and read-only status. This is exceptional transparency for a report tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, with four sentences each serving a distinct purpose: purpose, output shape, filtering/formatting details, and usage guidance. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description thoroughly explains the return shape, filtering, rounding, and read-only nature. For a report tool with optional parameters already documented in the schema, this is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions covering 100%, so the schema already documents parameter semantics. The description adds overall output context but no param-specific details beyond the schema, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific purpose: reporting Google Ads performance split by ad network (Google Search vs. Search Partners). It differentiates itself from sibling reporting tools by explicitly naming alternatives and the unique output format, so an agent can immediately understand what this tool does and how it differs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this to decide whether to toggle Search Partners.' It also names alternative tools for other scenarios ('For overall campaign totals use google_ads_performance_report; for per-ad breakdowns use google_ads_ad_performance_report'), providing 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states the tool is 'Mutating — the underlying change ... is committed to the campaign immediately and is NOT reversible through this tool.' It also discloses server-side re-validation to prevent injection and notes broader side effects on budget/device/schedule. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, return value, mutation/irreversibility warning, and validation plus pointer to the list tool. It is front-loaded with the core action and includes no filler or redundancy. This is an efficiently structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small 2-parameter tool with no output schema, the description covers all necessary context: input, return value, mutation side effects, irreversibility, validation, and related tool. It gives the agent enough to know when and how to invoke it, and what to expect. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters with 100% coverage, including the resource_name pattern and customer_id fallback behavior. The description adds little beyond the schema: it reiterates the resource_name format and mentions server-side re-validation, which is more of a behavioral detail than parameter semantics. Therefore, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Apply one Google Ads recommendation by resource name.' It clearly identifies the action and resource, and distinguishes itself from the sibling tool google_ads_recommendations_list by explicitly mentioning that tool for listing candidates. This is a clear, non-tautological purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance by stating 'To list candidates use google_ads_recommendations_list,' establishing the typical workflow and alternative. It also warns that the action is irreversible and that some recommendation types change budget/device/schedule settings, giving the agent clear context for when to apply caution. This is strong conditional usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states "Read-only" and details the return shape (array with resource_name, type, impact, campaign_id). It omits pagination/limit behavior, but for a straightforward list tool this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but efficient. The output format is included because no output schema exists, and every phrase serves a purpose. The description is front-loaded with the core purpose and quickly covers read-only behavior, filters, and the apply alternative in just two sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description covers all essential context: what the tool does, what it returns, that it is read-only, how to filter, and which sibling tool to use for applying. This is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the filtering semantics: campaign_id scopes to one campaign, recommendation_type scopes to one kind. This goes beyond the schema descriptions and clarifies behavioral impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("List") and names the exact resource ("Google's current automated recommendations for the account"). It clearly distinguishes itself from the sibling apply tool by framing this as a read-only list operation and showing the return shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool vs. the apply alternative: “To apply a recommendation use google_ads_recommendations_apply with resource_name from this list.” It also explains how to scope via campaign_id or recommendation_type, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly reveals output structure, sorting ('Rows sorted by impressions descending'), and explicitly states it is read-only. This exceeds typical transparency by documenting return shapes and label semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries essential information: purpose, output structure, sorting, read-only flag, and alternative tools. It avoids redundant phrasing and earns its length by providing a full return specification in the absence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and only 3 parameters, the description fully specifies the return shape, parameter roles, performance labels, and cites sibling tools. It gives enough context to make the tool independently usable without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds context for campaign scope but does not add significant parameter semantics beyond the schema. It correctly relies on schema for period and customer_id details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Split Responsive Search Ad asset performance within a Google Ads campaign into headlines and descriptions,' clearly stating the specific action and resource. It explicitly names the tool's function and differentiates it from siblings by mentioning related tools for audit and ad-level comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit alternatives: 'For an audit version with replacement recommendations use google_ads_rsa_assets_audit; for ad-level A/B use google_ads_ad_performance_compare.' Also states 'Read-only,' signaling when it's safe to use without mutation side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explicitly states 'Read-only; does not modify any assets,' which is essential for an agent to know. It also discloses decision thresholds (e.g., 'HIGH priorities fire when headlines < 8 or descriptions < 3') and the 'wait_for_data' condition, making the tool's behavior predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. The return object is fully enumerated, which is necessary because there is no output schema. The opening sentence states purpose, then thresholds, read-only status, and alternative tool all follow in a logical, compact structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 absence of an output schema and annotations, the description is remarkably complete. It specifies the full return schema, trigger thresholds, read-only behavior, and differentiates itself from the closest sibling. An agent has everything needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed semantics for each input parameter (period guidance, campaign_id example, customer_id fallback). The description itself adds no further parameter-specific information, so baseline 3 is appropriate per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Audit') and resource ('Responsive Search Ad assets'), and clearly states the output ('emit replacement recommendations'). It distinguishes itself from the sibling tool google_ads_rsa_assets_analyze by explicitly redirecting users who need the raw per-asset breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit alternative: 'For the raw per-asset performance breakdown use google_ads_rsa_assets_analyze.' It also specifies when HIGH and LOW priorities fire, providing concrete guidance on when the tool's output is actionable vs. when to wait for more data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses read-only behavior ('Read-only'), return semantics ('returns an empty list when the campaign has no schedule targeting (meaning: 24/7 delivery)'), and details each return field with types and enum ranges. This is comprehensive behavioral disclosure beyond what a schema could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but every sentence adds value: the main action, return field specification, edge-case behavior, and cross-references to related tools. It is front-loaded with the primary purpose and structured logically without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fully documents the return shape including criterion_id, day_of_week, start_hour, end_hour, start_minute, end_minute, and bid_modifier, plus edge cases like empty list and null bid_modifier. It also contextualizes usage within the broader targeting toolset, making it complete 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both campaign_id and customer_id, so the schema already explains the parameters. The description adds context around the update workflow but does not add new parameter-level semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List the ad-schedule (day-of-week + hour-of-day) targeting criteria attached to a Google Ads campaign.' This clearly identifies what the tool does and distinguishes it from sibling tools like google_ads_schedule_targeting_update and google_ads_device_targeting_get.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this to audit schedule coverage or collect criterion_ids before calling google_ads_schedule_targeting_update.' It also mentions the alternative for device modifiers and geo targeting, providing clear when-to-use versus 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.
Behavior5/5
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 declares 'Read-only', details the exact return structure, and explains candidate semantics (e.g., keyword_candidates with CV>0 and not registered, negative_candidates top 20 by cost with conversions=0). This is thorough behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence serves a distinct purpose: purpose, return shape, read-only status, and sibling differentiation. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description fully specifies the return contract, including nested ngram_distribution top-10s and candidate filter criteria. It also provides alternative tool pointers, making it complete for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with clear descriptions, including campaign_id format and period enums. The description itself does not need to add parameter meaning; it complements the schema by specifying the output shape.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Analyze') and identifies the resource ('keyword/search-term overlap and N-gram distribution for a Google Ads campaign'). It explicitly names sibling alternatives in the final sentence, distinguishing it from google_ads_search_terms_review and google_ads_search_terms_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool versus alternatives: 'For rule-scored add/exclude/watch buckets use google_ads_search_terms_review; for the raw unscored term log use google_ads_search_terms_report.' The schema description also adds period-selection guidance for recent changes versus trend baselines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a strong job: it states 'Read-only', warns that campaign_id/ad_group_id are 'NOT echoed back in the output — scope your query before calling', and describes the exact return shape. It could add more about row limits or sorting but covers the most critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then the return shape, then a critical caveat, and finally explicit sibling differentiation. Every sentence carries useful information with no fluff, and the use of semicolons efficiently packs in the alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains the return value shape and metrics. It covers parameter semantics (via schema and added context), read-only behavior, scoping caveats, and alternative tools. For a list-style report with 4 optional parameters, this description is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds value beyond the schema by explaining the ID omission behavior and suggesting shorter vs. longer period windows for different diagnostic scenarios. This enriches parameter understanding beyond the field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'List actual user search queries that triggered ads' and the resource 'over a reporting window'. It also specifies the output shape and explicitly distinguishes from sibling tools like google_ads_search_terms_review, google_ads_search_terms_analyze, and google_ads_performance_report, making the tool's unique role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use this for raw query logs when you need to eyeball the terms yourself' and then names alternatives with their specific use cases (rule-based candidates, intent-class distribution, campaign-level aggregates). This clearly tells the agent when to use this tool vs. when to choose a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fully discloses the destructive nature, immediate stoppage, purging of evaluation history, non-reversibility, and the new rule_id on re-creation. This is thorough and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, starting with the primary action, then the success flag, followed by important alerts and alternatives. Every sentence provides necessary information without unnecessary fluff, making it easy to scan and act upon.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex destructive delete operation with no annotations and no output schema, this description covers all essential aspects: immediate effect, data purge, reversibility, rollback mechanism, and alternative for suspension. It is sufficiently complete for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already explains rule_id and account_id formats, requiredness, and fallback behavior. The description adds context about rule_id's role in rollback (re-creating assigns a new ID), but does not add parameter-specific syntax or meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Deletes an Automated Rule' with a specific verb and resource, and it distinguishes itself from sibling tools by explicitly noting that temporary suspension should use meta_ads_ad_rules_update instead. The phrase 'Returns a success flag' also clarifies the return behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'For temporary suspension prefer meta_ads_ad_rules_update with status=DISABLED.' It also advises recording before-state for rollback and warns about downstream references, giving clear context on when this tool is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so exceptionally well. It explicitly warns that the operation is 'Mutating — not automatically reversible,' advises using mureo_state_action_log_append for rollback, and notes timing/suspension behavior. No contradiction 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose, then covers safety, timing, and status guidance. Every sentence carries significant information with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex update tool with 8 parameters, nested objects, no annotations, and no output schema, the description covers essentials: purpose, partial-update semantics, reversibility, rollback path, timing, status behavior, and return value. It is complete enough 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds tool-level value by clarifying that only supplied fields change and that updates take effect on the next scheduled evaluation. It does not deeply re-explain each parameter but complements the already-rich schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Updates fields on an existing Automated Rule,' which clearly identifies the verb, resource, and scope. It distinguishes this from sibling tools like create/delete/list/get by emphasizing 'existing' and 'Partial update.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: partial updates, mutating nature, rollback suggestion, and 'Changes take effect on the next scheduled evaluation.' It also recommends using status=DISABLED rather than deletion for suspension. However, it does not explicitly contrast with alternative tools beyond rollback logging and does not state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It discloses partial update semantics, returns the updated ad set, warns that the operation is 'not automatically reversible' and advises recording before-state, and explains the targeting read-modify-write merge behavior and the replace flag. This is rich, actionable context beyond a basic summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, front-loaded with the core purpose (updates an ad set, partial update) followed by key behavioral caveats. Every sentence adds value: the merge behavior, the replace flag, and the sibling tool pointer are all meaningful. No fluff or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 13-parameter tool with nested objects and no output schema or annotations, the description is remarkably complete. It covers the critical edge cases (partial update, rollback, targeting merge, end_time clearing, budget interactions) that an agent needs to invoke the tool correctly. Combined with the exhaustive schema, the agent has all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 every parameter in detail. The description adds high-level guidance about targeting merge behavior and bidirectional relationships (e.g., when to use bid_amount), but most per-parameter semantics are already in the schema. Baseline 3 is appropriate; the description does not need to repeat schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Updates one or more settings on an existing ad set' and distinguishes it from siblings by noting 'For status-only transitions prefer meta_ads_ad_sets_pause / meta_ads_ad_sets_enable.' It also explains the partial-update behavior, making the tool's scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance, including the alternative pause/enable tools for status-only changes and when to use replace_targeting ('to replace the whole spec instead (e.g. to clear a facet)'). Also warns about mutability and rollback, giving clear context for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 explicitly states 'Read-only' and discloses that ad_review_feedback is only populated when the ad is in WITH_ISSUES. This goes beyond a simple fetch description and informs the agent of relevant conditional behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with a clear structure: action, return fields, and usage guidance. Every sentence earns its place, and there is no redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description fully covers the purpose, the fields returned, and the recommended use case. It is complete for a single-record read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the baseline is 3. The description does not add additional parameter-level detail beyond what the schema already provides, but it reinforces the context for ad_id (derived from a list).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Fetches the full detail record for a single ad', using a specific verb and resource. It distinguishes from siblings like meta_ads_ads_list by emphasizing 'single ad' and listing specialized fields such as ad_review_feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Call this when an ad shows up as WITH_ISSUES in ads.list'. This gives a concrete trigger and explains the value of the tool in that context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does so well: it discloses 'Lightweight; the ad stops serving immediately', reversibility, return value ('Returns the ad_id and new status'), and scope ('Does not affect the parent ad set or sibling ads'). 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core action, then reversibility, return value, and scope. Every sentence adds unique value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ad pause operation, the description is complete: it covers the action, immediate impact, reversal, return data, scope boundary, and usage guidance versus alternative. The schema covers parameters fully, and the description even mentions output without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 no extra parameter semantics beyond what the schema already provides; it does not elaborate on account_id or ad_id, but the schema descriptions are sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb+resource: 'Pauses a single ad by setting its status to PAUSED.' It clearly distinguishes from sibling tools by specifying scope: 'Does not affect the parent ad set or sibling ads' and differentiates from meta_ads_ad_sets_pause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives: 'Use for creative-level pause; use meta_ads_ad_sets_pause to stop a whole ad set.' Also mentions reversal paths via rollback_apply or meta_ads_ads_enable, giving clear context for when this tool fits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses mutability, non-reversibility, partial update behavior, and return value. It adds valuable context about creative limitations and rollback logging. Minor gap: no mention of permissions or error conditions, but overall strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, partial update/return, mutability/rollback, creative limitation, and status alternatives. Information is front-loaded and no filler exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema, the description is remarkably complete. It covers return value, rollback concern, creative change path, and alternative tools for status transitions. Given the 4 parameters and 100% schema coverage, nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics: account_id falls back to META_ADS_ACCOUNT_ID, and status changes should prefer pause/enable tools. This exceeds schema descriptions by clarifying optionality and preferred usage for specific parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Updates fields on an existing ad. Partial update.' – a specific verb and resource with a clear scoping qualifier. It differentiates from sibling tools by explicitly naming meta_ads_ads_pause/meta_ads_ads_enable for status-only changes and by stating that creative cannot be swapped via this call, which distinguishes it from creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus alternatives: status-only transitions should use pause/enable, and creative changes require creating a replacement ad. It also advises recording before-state with mureo_state_action_log_append for rollback, giving practically actionable context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to cover safety, the description fully discloses the destructive nature: impact on targeting ad sets, possible delivery stoppage, irreversibility, and the caveat about approximate_count not being restored. It goes beyond simple 'deletes' to explain real-world consequences and mitigation steps, making the tool's behavior transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence carries critical safety information. It front-loads the core action and return value, then proceeds from broad consequences to specific mitigation steps. The structure is logical, and the density is justified for a destructive, irreversible operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of this destructive mutation tool, the absence of annotations, and the lack of an output schema, the description covers all necessary contextual aspects: what it does, what it returns, side effects, irreversibility, prerequisites, and related tool usage. It is complete and self-sufficient for an agent to decide and execute safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both account_id and audience_id already well documented in the input schema. The description does not add extra semantic detail about the parameters themselves, such as formats or fallbacks, beyond what the schema provides. It earns the baseline 3 for not compensating further, but also does not need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Deletes a Custom Audience.' This clearly distinguishes it from sibling tools like meta_ads_audiences_create, meta_ads_audiences_list, and meta_ads_audiences_get. It also scopes to 'Custom Audience' rather than lookalike audiences, avoiding ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool and provides a recommended pre-flight workflow: call meta_ads_audiences_get first to identify impacted ad sets, consider pausing them, and log before-state for potential rollback. This offers clear context and practical alternatives, setting expectations for safe usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states 'Read-only,' lists the exact return fields, and notes conditional fields (rule for rule-based, pixel_id for WEBSITE audiences), giving the agent a complete picture of expected behavior without requiring an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then return fields, then usage guidance. Every sentence provides necessary information with no redundancy. The structure flows logically and stays appropriately concise for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, no annotations), the description covers all critical aspects: purpose, output fields including conditional ones, read-only safety, and when to invoke it. It is fully self-sufficient for an agent to select and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add new parameter-level semantics beyond what the schema provides, but the schema itself already documents account_id's format/fallback and audience_id's source. The description's mention of 'single Custom Audience' reinforces the audience_id purpose but adds no new details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetches') and identifies the resource ('full detail record for a single Custom Audience'), clearly distinguishing it from sibling list or delete tools. It further specifies the content ('rule definition and approximate_count'), making the tool's purpose explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Call this before meta_ads_audiences_delete or before create_lookalike to verify you have the right audience.' This provides direct contextual guidance and differentiates it from alternatives, which is exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure: it explicitly says 'Mutating — not automatically reversible; record before-state with mureo_state_action_log_append if you may need to roll back.' It also warns about immediate spend and reinforces the PAUSED default, adding meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences with no filler: it front-loads purpose and return value, then covers mutation risk, spend guardrail, and resource hierarchy. Every sentence earns its place and avoids duplicating the full schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a high-stakes create operation with no output schema and no annotations, the description provides the essential operational context: return value, rollback guidance, default status, spend safety, and the required sibling calls to fully create a campaign. It is complete enough for the agent to invoke and chain the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 8 parameters with high detail, so the baseline is 3. The description adds the crucial context that a campaign is only a container and ad sets/ads are separate, which explains why those parameters do not exist here and how the returned id should be used in subsequent calls. It mostly reinforces schema details, so it does not reach 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Creates a new campaign in the specified Meta Ads account' and notes the return of the campaign id, providing a specific verb, resource, and scope. It also distinguishes itself from sibling tools by explicitly pointing to meta_ads_ad_sets_create and meta_ads_ads_create as the separate steps for ad sets and ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear invocation context: default status is PAUSED and ACTIVE should only be passed after operator confirmation of spend. It names the sibling tools that must be used for ad sets and ads, which clarifies boundaries, though it does not explicitly state 'use this when creating a new campaign' as opposed to updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the action on campaign status, the non-recursive side effect on nested entities, the return value (campaign id and new status), and reversibility via rollback_apply or meta_ads_campaigns_pause. No contradiction with annotations (none present).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core action. Each of the four sentences adds distinct value: main purpose, child-status caveat, return value, and reversibility. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's apparent simplicity, the description covers all essential behavioral nuances: what is changed, what is not changed, what is returned, and how to reverse. The mention of related sibling tools makes the description contextually complete for an agent to act correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters (account_id and campaign_id). The description adds no extra parameter-specific meaning beyond what the schema already 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific verb 'resumes' and resource 'paused campaign' and sets status to ACTIVE. It distinguishes from sibling tools like meta_ads_campaigns_pause and the ad-set/ads enable tools by noting the campaign-only scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (to resume a paused campaign) and when-not-to-use (when child ad sets/ads are paused, they won't auto-resume) with named alternatives (meta_ads_ad_sets_enable / meta_ads_ads_enable). This gives 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is 'Mutating — not automatically reversible' and advises recording before-state with mureo_state_action_log_append. It also surfaces the prerequisite of a product catalog, giving the agent essential behavioral and safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, mutability/rollback, and alternative. It is front-loaded with the action, contains no redundant information, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutating, catalog-dependent, 7 params) and no output schema, the description covers the essential context: what it does, prerequisites, side effects, rollback recommendation, and alternative tool. It also clearly states the return is the new creative id, which is sufficient for an agent to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for all parameters, so the description doesn't need to add param-level detail. The description only mentions product_ids in the context of the catalog requirement, which is already covered in the schema's product_ids description. Baseline 3 applies because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates a Collection AdCreative that pulls products from a catalog into a mobile-optimized storefront layout' and notes it returns the new creative id. It distinguishes this from sibling tools by explicitly contrasting with carousel for 'static card decks', making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: it requires a product catalog and directs users to set it up via meta_ads.catalogs.* tools first, and for non-catalog static decks it recommends meta_ads_creatives_create_carousel instead. This clearly states when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that the operation is 'Mutating — not automatically reversible' and advises recording before-state with mureo_state_action_log_append. It also mentions the return value (new creative id) and that Meta combines assets at serve time. While it doesn't cover permissions or errors, it discloses the critical mutation and persistence behavior sufficiently.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, with the core purpose front-loaded, followed by risk/rollback guidance and explicit alternatives. Every sentence contributes meaningful information without redundancy or filler, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 params, no output schema, no annotations), the description covers all essential context: purpose, usage scenarios, alternatives, constraints, mutability, and return value. The parameter details are thoroughly documented in the schema, so the description doesn't need to repeat them, making it complete and well-rounded.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by specifying recommended ranges ('Supply 2–10 images, 1–5 of each text field') and explaining the rationale ('Meta combines them at serve time'), which complements the schema's min/max constraints with real-world guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Creates a Dynamic Creative' and explains the distinctive behavior (Meta auto-generates and optimises combinations). It also differentiates from sibling tools by naming meta_ads_creatives_create and meta_ads_creatives_create_carousel, specifying exactly when each should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use when you want Meta to learn the best-performing asset mix rather than testing manually' and explicitly recommends alternatives for static single-image ads and carousels. This goes beyond vague context and gives actionable 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It discloses that the operation is 'Mutating — not automatically reversible' and recommends rollback recording, describes return values, and includes edge-case behavior such as 'image_url is rejected in video mode.' This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, leading with the purpose and return values, then usage and prerequisites. Every sentence adds value, with no fluff or redundancy. It is well-structured for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 12-parameter tool with no output schema or annotations, the description covers purpose, return values, mutation/rollback, usage conditions, prerequisites, and a key constraint (link_url). It provides sufficient context for an agent to select and invoke the tool correctly, and the schema covers the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% parameter coverage with detailed descriptions for all 12 parameters. The description text adds minimal new parameter-specific semantics; it repeats some schema info (e.g., link_url requirements) but does not meaningfully compensate beyond the schema's already high coverage. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Creates a Lead Ad AdCreative attached to a Meta Instant Form' with a clear verb and specific resource, distinguishing it from sibling tools like meta_ads_creatives_create. It also states the return values, which further clarifies the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use under a campaign with objective=OUTCOME_LEADS and an ad set with optimization_goal=LEAD_GENERATION' and provides prerequisites, e.g., 'the lead form must exist (create via meta_ads_lead_forms_create) and belong to the same Facebook Page.' This gives clear when-to-use and prerequisite guidance without needing explicit alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 explicitly states 'Read-only — does not modify the account' and discloses the default limit of 50 per call. This is valuable behavioral context beyond the schema, though it stops short of mentioning rate limits or API error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the primary action, followed by return fields, behavioral note, and usage guidance. It is efficient with no fluff or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description lists the specific fields returned per creative (id, name, status, etc.). It also covers optional account_id fallback, pagination limits, read-only nature, and points to the sibling tool for ads, making this a complete and self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents both parameters (100% coverage), but the description adds practical guidance about using smaller limits and filtering client-side for large inventories. This insight goes beyond the schema's static default/max values, making the parameters more actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Lists AdCreative resources in a Meta Ads account' with a specific verb and resource, and enumerates the returned fields. It also distinguishes itself from the sibling tool meta_ads_ads_list by explicitly saying 'To list the ads that consume these creatives, use meta_ads_ads_list.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use this to audit creative inventory or to find a creative_id for reuse in meta_ads_ads_create.' It names the alternative for listing ads (meta_ads_ads_list) and offers practical advice about handling large inventories with smaller limits and client-side filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and exceeds it: it discloses mutation ('Mutating and delivery-affecting'), the specific risk of zero delivery, the replace-not-append semantics, the merge behavior preserving other targeting, return values ('Returns ad_set_id, the applied facets, and Meta's update result'), and side effects ('Recorded in STATE.json's action_log' and 'reversible via rollback_apply'). This is exemplary disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and return value, then layers risk, replacement semantics, merge behavior, and state/rollback side effects. Every sentence adds distinct, non-redundant information, and the whole thing is appropriately sized for a complex mutating tool — no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description covers all essential context: what it does, what it returns, the mutation risk, the replace semantics, what is preserved, and the rollback/logging path. The only minor omission is permission requirements, but the description is otherwise complete for an agent to select and invoke this tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and each parameter already has a detailed description, so baseline is 3. The description adds genuine value beyond the schema by generalizing the replacement rule ('Each supplied facet REPLACES its current value... an omitted facet is left untouched'), which clarifies omission behavior not stated per-field in the schema. It also frames the read-modify-write merge across facets.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Sets one ad set's delivery-surface exclusions.' This clearly distinguishes it from the sibling meta_ads_excluded_placements_get (getter vs setter) and from Google Ads negative placement tools. The scope ('one ad set') and platform (Meta) are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the read-before-write workflow via 'read-modify-write merge' and warns of the risk ('excluding too much can take an ad set to zero delivery'), giving clear caution about when to use it. However, it does not explicitly name the alternative meta_ads_excluded_placements_get or state when not to use this tool — that guidance lives in the schema rather than the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does so thoroughly. It discloses the tool is 'Mutating, reversible' and explains the effects of each status value: ARCHIVED stops new submissions but keeps existing leads queryable, ACTIVE undoes an archive. It also warns about Meta's version-dependent mutability, which is a valuable caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a clear role: purpose, scope/rationale, and usage instructions. Front-loaded and efficient with no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with 100% schema coverage, the description is comprehensive. It covers purpose, scope, side effects, reversibility, and provides specific status instructions. No output schema exists, but this is acceptable given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with rich descriptions for all parameters, so the baseline is 3. The description adds minor behavioral nuance (e.g., 'existing leads stay queryable' for ARCHIVED) but does not significantly expand on form_id or account_id, which are already well-documented in the schema. The added value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Changes a lead form's lifecycle status.' It clearly distinguishes this from sibling lead form tools by stating it updates only the status field and names the other out-of-scope fields, 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage direction: 'Pass status=ARCHIVED to retire a form... Pass status=ACTIVE to undo an archive.' It also states which fields are intentionally out of scope, effectively telling the agent when not to use this tool (for any non-status updates). The explanation of Meta's mutability limitations adds context without being verbose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses side effects (writes locally), return value (row count), header format, column order stability, PII handling, and data retention. Excellent coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each providing necessary context. No redundant information, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, description covers purpose, output format, side effects, and retention. Fully sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%), so baseline is 3. Description adds value by explaining field_order's purpose for stable CRM schemas and header row composition, exceeding baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it does: fetches leads for a lead form and writes to a local CSV. Distinct from sibling tools like meta_ads_leads_get by mentioning local file output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies use for CSV export and mentions regular exporting due to 90-day retention, but does not explicitly name alternative tools or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the operation is mutating, not automatically reversible, pixels cannot be deleted via Graph API once created, and recommends recording before-state. It also mentions pixel limits and post-creation verification steps. There is no contradiction with annotations because none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and return value, then provides essential behavioral and usage guidance in four compact sentences. Every sentence adds operational value—pre-check, irreversibility/logging, and post-creation verification—without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no annotations and no output schema, the description fully covers purpose, return value, side effects, prerequisites, irreversible nature, and follow-up actions. It gives an agent everything needed to invoke this tool correctly and avoid common mistakes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters already have detailed descriptions (name purpose and account_id format/fallback). The description adds minimal parameter-specific semantics beyond the schema; it mostly contributes operational context rather than parameter detail, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Creates') and resource ('Meta Pixel on the ad account'), and states the return value ('Returns the new pixel id'). It clearly distinguishes this create tool from sibling tools like meta_ads_pixels_list, meta_ads_pixels_get, meta_ads_pixels_stats, and meta_ads_pixels_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call meta_ads_pixels_list first to check for existing pixels due to pixel limits and preference for reuse. It also directs to use meta_ads_pixels_stats / events after creation to confirm the pixel is firing, and suggests mureo_state_action_log_append for auditability. This provides clear when-to-use and alternative actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses that the operation is mutating, not automatically reversible, and suggests logging before-state with mureo_state_action_log_append for rollback. It also reveals rate limits and the non-obvious retailer_id upsert behavior, which is far more than a generic 'Creates' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: the first states purpose and return value, the second provides mutability/rollback guidance, and the third presents bulk alternative and upsert caveat. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 12 parameters fully documented in the schema and no output schema, the description fills the critical contextual gaps: it states the return value (new product_id), warns about rate limiting, explains the upsert semantics, and suggests rollback tracking. This is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and each parameter already has rich descriptions (e.g., retailer_id's upsert behavior, price format, availability enums). The tool-level description adds operational context but does not introduce new per-parameter semantics. Baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Adds a single product to a Meta Product Catalog.' It also mentions the return value ('Returns the new product_id'), which clarifies the operation's outcome. This clearly distinguishes it from sibling tools like meta_ads_products_update, meta_ads_products_delete, and meta_ads_products_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends an alternative for bulk ingestion: 'prefer a scheduled feed (meta_ads_feeds_create) — Meta rate-limits single-product adds aggressively.' It also explains the upsert behavior for retailer_id, guiding when a subsequent add might unexpectedly update instead of insert.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 declares 'Read-only', specifies the exact return fields, and notes that the catalogue is finite and thus returns the whole class — meaningful behavioral context beyond a simple 'list' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each with a distinct purpose: scope, return values, side-effect declaration, and usage guidance. It is front-loaded with the primary action and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by listing the returned fields and the read-only nature. It also addresses the finite catalogue behavior and usage context, making it complete for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% description coverage, so the baseline is 3. The tool description does not add parameter-level details beyond what the schema covers, though it does contextualize the catalogue classes and internal IDs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Lists a full Meta targeting category catalogue' — a specific verb and resource. It enumerates the supported classes and explicitly contrasts with meta_ads_targeting_search, distinguishing this tool as the finite-catalogue alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this for behavior / demographic targeting, where keyword search (meta_ads_targeting_search) is not supported', giving a clear when-to-use directive and naming the alternative. The rationale 'the catalogue is finite, so this returns the whole class' further explains the choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the read-only nature, asynchronous processing, rejection of creatives referencing in-progress videos, and the need to poll until ready. It also explains the nested status object and per-stage details, providing substantial behavioral context beyond basic tool function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main purpose, and every sentence provides valuable information. It balances detail (status object, polling behavior, timing) without unnecessary fluff, achieving excellent conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description compensates by explaining the returned fields (status, id, title, length, created_time), the nested status object, and how to interpret readiness. It also places the tool within the broader workflow, covering what is needed for effective use. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (video_id and account_id) fully described. The description adds minimal extra parameter semantics, only referencing video_id in the context of polling. Baseline is 3 due to high schema coverage; the description does not significantly enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Gets an uploaded video's processing status and metadata' with a specific verb, resource, and list of returned fields. It also distinguishes itself from sibling tools like meta_ads_videos_upload and meta_ads_videos_thumbnails by describing its role in the upload workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when to use the tool: 'poll this tool until the nested status object reports the video is ready... before calling meta_ads_creatives_create with video_id.' It also mentions the alternative for the next step ('pick a thumbnail via meta_ads_videos_thumbnails') and notes typical processing time, providing clear context and anticipated usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It explicitly states 'Read-only — does not modify the account,' and also discloses a behavioral nuance: 'Thumbnails only exist once processing has finished, so check meta_ads_videos_get first — an empty list usually means the video is still processing.' This provides critical operational context beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each serving a distinct purpose: stating the function, listing return fields, and giving usage guidance. It is front-loaded with the core purpose and avoids redundancy, earning a top score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since no output schema exists, the description compensates by explicitly enumerating the return fields (id, uri, is_preferred, height, width). It also covers prerequisites (video processing completion) and the next step in the workflow (passing uri to meta_ads_creatives_create), making the tool fully understandable in its operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (video_id and account_id) with 100% coverage, so the description adds little beyond what the schema states. It does not elaborate on parameter semantics further, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Lists the thumbnails Meta auto-generated for an uploaded video,' which clearly specifies the verb ('Lists') and the resource ('thumbnails' for a video). It also differentiates from sibling tools like meta_ads_videos_get by focusing specifically on thumbnail generation and returning fields (id, uri, is_preferred, height, width).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: after uploading a video, and it advises checking meta_ads_videos_get first to ensure processing is complete. It also explains how to use the result (pick preferred thumbnail and pass its uri to meta_ads_creatives_create), giving both context and a concrete downstream action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses the mutating nature (asset is persisted), async processing by Meta, the need to poll for readiness, supported formats and size limit, and that Meta fetches the URL itself. This gives a comprehensive behavioral picture beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, each earning its place: purpose, mutation/return value, async behavior and polling, and format/alternative guidance. It is front-loaded with the core purpose and has zero fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the tool's complexity. It covers the return value (video_id), async processing and polling, size/format limitations, and provides an alternative for local files. With no output schema, it appropriately explains the expected result and next steps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds some high-level context (e.g., Meta fetches the URL, returns video_id) but does not need to compensate for missing schema details. The parameter semantics are already fully explained in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads a video from a public HTTPS URL to the Meta Ads account, and specifically distinguishes it from the sibling meta_ads_videos_upload_file by noting that local-file uploads should use that alternative. It also mentions the return of video_id, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use meta_ads_videos_upload_file for local files, states that larger files require resumable upload (not yet supported), and directs the user to poll meta_ads_videos_get for status before attaching the video to a creative. This is clear when-to-use and when-not-to-use guidance with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 mutating nature, returns video_id, and explains the asynchronous processing with a required polling step. It also states supported formats and size limits, and mentions an unsupported larger-file path — giving agents a clear behavioral model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a distinct role: purpose/returns, async behavior/polling, and formats/alternatives. No filler or redundancy; the content is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and lack of an output schema, the description adequately covers the return value (video_id), the need to poll, file constraints, and the URL-upload alternative. It provides sufficient contextual grounding for an agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with each parameter (file_path, title, account_id) already described in the schema, including formats and size limits in file_path. The description does not add new parameter-level semantics beyond what the schema provides, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Uploads a video from a local file path to the Meta Ads account library' — a precise verb+resource+method. It explicitly differentiates from the URL-based sibling by stating 'For uploads from public URLs use meta_ads_videos_upload.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative meta_ads_videos_upload for URL uploads, and instructs to poll meta_ads_videos_get until status ready before attaching to a creative. It also notes a size limitation (1 GB, resumable not supported), signaling when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: entries are NOT reversible, duplicate imports are no-ops, platforms without feeds return status='unavailable' meaning mureo is BLIND, and 'truncated' means older changes are unreachable. It also explains that mureo's own changes are skipped and the observation window is anchored to actual change time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Though lengthy, every sentence delivers critical operational knowledge—edge cases, failure semantics, idempotency, and platform blindness—with no fluff. The structure front-loads the core purpose and then adds necessary caveats in a logical order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and complex behavior, the description covers response semantics (status='unavailable', truncated interpretation), idempotency, non-reversibility, and repeated-call safety. It is complete enough for an agent to select and invoke correctly, including understanding what results to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each parameter already has detailed inline descriptions (path restrictions, 'since' re-check vs backfill caveat, platform key format). The main description reinforces these but doesn't add much beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Import changes made OUTSIDE mureo ... into STATE.json's action_log'. It clearly distinguishes from sibling tools by scoping to external changes and explaining the purpose (making manual operations visible to daily-check). No other sibling has this exact import/visibility function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use reasoning ('so manual operation is visible to daily-check'), and crucial usage warnings: poll often because history cannot be backfilled, re-check via 'since' but not for backfill, and how to interpret 'truncated'. It also states the tool is safe to call repeatedly, which guides frequency expectations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses that the tool is read-only, describes the return format ('raw Markdown in one payload'), explains the tier structure and precedence rules, and notes the edge case of no insights. This is thorough and goes well beyond minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for the tool's complexity. It front-loads the core purpose, then adds necessary detail about tiers, precedence, and usage timing. Every sentence earns its place, including the list of workflow names, which serves as practical guidance rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description fully compensates by detailing return values (tiers, labels, precedence, empty-case guidance string) and usage context. It is complete for a simple getter tool with no parameters and no destructive actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids parameter explanations since none exist, and the schema fully covers the (empty) parameter space.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Load every insight previously saved via /learn.' It specifies the exact resource (insights saved via /learn) and the action (load), and distinguishes it from sibling tools by describing the two-tier structure (operator and workspace), which no other tool mentions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage timing: 'Call this near the start of every diagnostic workflow... BEFORE drawing conclusions.' It lists specific workflows and provides rationale. However, it does not explicitly mention when not to use it or alternatives (though none exist among siblings), so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses deterministic behavior, the built-in direction semantics (lower-is-better vs higher-is-better), volume-only metrics being 'reported, never scored,' and the noise_pct threshold with zero/absent baseline resulting in 'inconclusive' to avoid fabricating swings. This is exemplary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-structured: a lead purpose statement, usage instruction, platform neutrality, behavioral rules, and edge cases. Each clause earns its place without filler, and the information is front-loaded with the most critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the output classification (improved/regressed/inconclusive), the default noise threshold, platform flexibility, and edge cases like zero/absent baseline. This is complete for an evaluation tool with object inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed property descriptions (e.g., before contains examples and typical source). The description adds semantic value by clarifying the direction mapping for metric names, noise_pct default, and that before is usually metrics_at_action. This goes beyond the schema but relies on the schema's existing clarity, hence a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Deterministically evaluate whether a logged action's outcome improved, regressed, or is inconclusive.' It clearly distinguishes this tool from siblings by positioning it as 'the reproducible verdict the observation-window review (daily-check) and /learn rely on,' setting it apart from raw reporting or analytics tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use: pass before/after metrics to get a reproducible verdict for daily-check and /learn, and notes it works for any platform. It even contrasts with 'eyeballing the numbers.' However, it does not explicitly name alternative tools or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the tool mutates Search Console state, is safe to call repeatedly (PUT not POST, no duplicate entries), returns a status object with no synchronous processing status, does not fetch/validate sitemap contents, and requires verified owner/full user status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence in the description earns its place: purpose, mutation semantics, idempotency, return format, async behavior, auth requirement, and sibling tool differentiation. It is dense but well-structured 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is remarkably complete. It covers the return value, lack of synchronous status, async validation, auth prerequisites, and provides clear alternatives. No significant context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add parameter-specific meaning beyond the schema; it references 'feedpath' and 'site_url' only implicitly. However, the schema's parameter descriptions are already detailed, so no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Submit a sitemap URL to Google Search Console for the given verified site.' It clearly distinguishes from sibling tools by naming search_console_sitemaps_list and search_console_url_inspection_inspect as alternatives, and explains the mutation/refresh behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool vs alternatives: 'For read-only inspection of already-submitted sitemaps use search_console_sitemaps_list; for per-URL indexing diagnostics use search_console_url_inspection_inspect.' Also provides context on idempotency, auth requirements, and the asynchronous nature of processing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It explicitly states 'Read-only; no mutation' and discloses the exact return shape (raw Webmasters API response with siteUrl and permissionLevel), giving the agent clear behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: purpose, return shape, read-only note and usage guidance, and alternatives. Information is front-loaded and there is zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description fully covers purpose, return value, safety behavior, and when to use it, while also referencing relevant siblings. It is complete in every meaningful way.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% parameter coverage with a detailed description of site_url. The tool description adds no additional parameter semantics beyond what the schema states, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and names the exact resource ('metadata and permission level for a single Search Console property'), clearly distinguishing this from sibling tools like search_console_sites_list (list properties) and search_console_url_inspection_inspect (per-URL data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('use this to verify whether the authenticated account has write access before calling mutating tools') and names specific alternatives for other use cases, providing clear contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly discloses read-only behavior ('Read-only; no re-indexing is triggered') and adds rate limit detail (~2000 URLs per property per day). It also describes the exact return envelope, including optional fields, which is essential operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized; each sentence serves a distinct purpose (result format, safety, rate limit, use-case, alternatives). The return-envelope detail is lengthy but necessary given no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-output-schema tool, the description fully accounts for return structure, optional fields, read-only behavior, and rate limits. It also situates the tool relative to sibling Search Console tools, making it complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters at 100%, including property syntax for site_url and cross-property rejection for inspection_url. The tool description adds no parameter-specific semantics beyond this, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inspect') and identifies the exact resource ('a single URL's indexing state') and API. It distinguishes from siblings by explicitly naming alternative tools for site-wide coverage and performance metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States when to use ('Use this to debug why a specific page isn't ranking') and explicitly lists alternatives: search_console_sitemaps_list for site-wide coverage and search_console_analytics_query for performance metrics. Also flags the daily rate limit, giving practical usage constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It explains return semantics ('unknown is an honest answer and never means no impact'), the guardrail consistency of 'would_block', and the existence of 'unevaluated_rules' to surface. It also notes that the delivery_records form reaches no platform API, effectively describing side-effect profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core purpose in the first sentence. Each subsequent sentence earns its place by covering invocation modes, return semantics, and guardrail behavior. It is dense but not padded, though it could be slightly more concise without losing important nuance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description describes key return fields ('measured', 'partial', 'unknown', 'would_block', 'unevaluated_rules') and edge cases. It covers both platform-specific and generic usage, cumulative impact, and the distinction between inert and satisfied guardrails. For a complex tool with nested objects and six parameters, this is highly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover all six parameters (100% coverage), but the description adds meaning beyond the schema by explaining the two mutually exclusive parameter groups ('tool'+'arguments' vs 'excluded_entities'+'delivery_records') and clarifying the nuanced meaning of omitting 'standing_exclusions' versus passing an empty list. The mode distinction is not fully evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear, specific purpose: 'Before applying a batch of exclusions / blocks / negative keywords, report how much of the account's OWN recent delivery... it removes'. The verb 'report' plus the resource (delivery impact) and the context (before applying exclusions) distinguish it from analytic sibling tools like analysis_anomalies_check or analysis_delivery_collapse_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is explicit: 'Before applying a batch of exclusions...' and it contrasts the two invocation modes: with 'tool'+'arguments' for platform APIs, or with 'excluded_entities'+'delivery_records' for any other platform, noting the latter 'reaches no platform API'. It also advises to omit 'standing_exclusions' when unknown, 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's behavioral traits: mutating, not automatically reversible, returns updated ad group, and does not cascade. It also provides a mitigation for rollback via mureo_state_action_log_append. This goes well beyond basic expectations for an update tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with clear purpose: action+partial update, return value+rollback advice, non-cascade guidance. No redundancy or filler. The information is front-loaded with the primary purpose then important caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description notes 'Returns the updated ad group,' covering the return value. It also addresses related tools and rollback. It does not mention permission requirements or error conditions, but for an update tool with these details, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has detailed descriptions. The tool description adds semantic context about how parameters are applied (partial update, only provided fields changed), which clarifies parameter behavior globally. It could add more per-parameter details, but the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Updates one or more settings on an existing ad group.' It specifies the resource (ad group) and the verb (updates), and differentiates from create/list by focusing on existing ad groups and partial updates. It also distinguishes from related tools by noting it does not cascade to ads or keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Partial update — only provided fields are changed' clarifies when to use this tool for targeted modifications. It also gives clear exclusions and alternatives: 'Does not cascade to ads or keywords... use google_ads_ads_update / update_status and google_ads.keywords.* for those.' This directly tells the agent when to select a different tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation is mutating and not automatically reversible, advises using mureo_state_action_log_append for rollback, and reveals the immutability of the period field. This goes beyond the schema and provides critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and well-structured, covering purpose, return values, mutation warning, usage flow, and constraints. While it is longer than minimal, every sentence provides necessary information. The logical progression from purpose to alternatives to parameter usage is clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description is remarkably complete. It covers all key aspects: purpose, return values, mutation side effects, best practices, alternative tools, and parameter selection. The absence of an output schema is compensated by explicitly stating what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 100%, the baseline is 3. The description adds semantic value by explaining the relationship between period, amount, total_amount, and total_amount_micros, and clarifying when to use CUSTOM_PERIOD vs daily amounts. It does not introduce new parameter syntax but enhances practical understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Creates a new campaign budget that can be attached to one or more campaigns.' It also explicitly differentiates from sibling tools by naming google_ads_budget_update as the alternative for editing existing budgets, and mentions the return of id and resource_name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: when to use this tool (creating new budgets), when not to (editing existing budgets, directing to google_ads_budget_update), and a typical flow (budget.create → campaigns.create). It also explains the specific use case for CUSTOM_PERIOD with total amount vs daily amount.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses read-only status, sorting order, the 100-row cap, timestamp format caveats with defensive parsing advice, and the API's rejection of open-ended ranges with mureo's compensating behavior. It also documents the exact return shape, including field names and example enum values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense single paragraph but every sentence adds necessary information. The return-format explanation, though verbose, is essential since there is no output schema. It is front-loaded with the primary action and includes a clear alternative at the end, balancing detail and brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description fully compensates by specifying return fields, types, and formatting caveats. It covers date behavior, read-only nature, and usage context, while also pointing to a sibling for narrower queries. No critical gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 adds value beyond the schema by explaining why omitted dates default to 14 days and that the API rejects open-ended ranges, which mureo automatically fills. This clarifies the behavior of start_date and end_date parameters in a practical way not captured in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List the most recent change_event rows on a Google Ads account', and adds sorting and capping details. It distinguishes from sibling tools by stating 'Use this for audit-trail diagnosis' and explicitly naming an alternative, google_ads_cost_increase_investigate, for narrower filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: 'Use this for audit-trail diagnosis' and explicitly points to an alternative for bid/budget-only filtering. It also explains date default behavior ('Defaults to the last 14 days when dates are omitted') and the mureo filling of open-ended ranges, which helps the agent decide when to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It explicitly states that the operation is mutating and not automatically reversible, recommends a rollback strategy, reveals Meta's mandatory fields (privacy_policy_url and follow_up_action_url), explains the write-only nature of context_card.cover_photo_id, and even cites the specific error subcode for a missing follow_up_action_url.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct yet information-dense. It opens with the core purpose and return value, then adds mutation warnings, parameter relationships, and Meta requirements—all without redundancy. Every sentence contributes value, and the structure aids quick scanning for the most critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 params, nested objects, no output schema), the description is remarkably complete. It covers the return type, mutation side effects, rollback guidance, required Meta fields, error subcode, and parameter-specific behaviors (write-only, branching, higher-intent step count). This is comprehensive for a create operation with such a rich schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
While the schema already has 100% parameter description coverage, the tool description adds substantial meaning beyond the schema. It explains that questions are ordered, details CUSTOM question requirements (key, label, options), clarifies that thank_you_page does not replace follow_up_action_url, and describes the branching logic for conditional_questions_choices. This enriches the schema's static definitions with operational semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Creates a new lead form on a Facebook Page. Returns the new form_id.' This identifies the specific verb (creates), resource (lead form on a Facebook Page), and return value, effectively distinguishing it from sibling tools like lead_forms_list and lead_forms_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 (creating a lead form) and even advises recording before-state with mureo_state_action_log_append if rollback may be needed. It does not explicitly compare against alternatives like update or list, but the creation purpose is unambiguous and the mutation warning is a useful guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses read-only behavior ('never mutates the ad account'), return statuses (status=ok | no_credentials | data_unavailable), the meaning of an empty signals list, and the fact that certain parameters are ignored for non-applicable capabilities, including the multi-week window rationale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence serves a purpose. It front-loads the main function, then flows logically into usage prerequisites, capability-specific details, parameter applicability, and safety/return behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and a complex multi-capability tool, the description covers all essential context: return payload structure, error statuses, parameter scoping, and prerequisite sequencing. It is fully complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds crucial semantics beyond the schema: it explains that window_days applies only to detect_anomalies and scope only to diagnose_performance, and that platform must match the value from mureo_analytics_modules_list. This clarifies conditional parameter behavior not obvious from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it runs one capability of the analytics module and returns a structured result. The description enumerates the exact capabilities, which distinguishes it from sibling tools like mureo_analytics_modules_list and analysis_* tools that might check or diagnose separately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use after mureo_analytics_modules_list confirms the platform advertises the capability. It also clarifies which parameters apply to which capabilities, guiding the correct invocation. However, it does not explicitly name alternative tools or state when not to use it, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains replacement semantics (complete set, not additive), how overlapping aliases can't double-count, that passing an empty list clears the override, that it's stored persistently, and that it returns the updated state document. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and each sentence adds substantive information, but it is longer than necessary. It front-loads the core purpose and then logically flows through usage, semantics, tips, and return values. No fluff, but not as tightly concise as the two-sentence gold standard.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and lack of output schema, the description covers all necessary aspects: purpose, when to use, replacement semantics, clearing, storage location, persistence, and return value. It also provides a practical tip to avoid typos, making it fully actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explaining the higher-level semantics of conversion_action_types (complete set overriding defaults, preventing double-counting) and reinforces the platform key uniqueness. This goes beyond the schema's parameter descriptions, which already are detailed, but the description enriches the mental model.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states its purpose: declaring which Meta Insights action_type rows count as this account's conversions, overriding mureo's built-in generic set. It uses a specific verb ('Declare') and resource ('Meta Insights action_type rows') and distinguishes itself from sibling state tools by focusing on conversion override logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool: when an advertiser uses custom pixel events or when the account emits only component rows. It also provides practical guidance (call meta_ads_insights_report first to verify exact strings, confirm with operator) and explains clearing behavior, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the behavioral disclosure burden. It explains what each entry reports (name, configured status, capabilities, model ids), the configuration criteria (API key or codex login), and the nuanced semantics of 'edit', 'max_size', and 'supported_sizes', including the clamping behavior. This goes well beyond a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized. It front-loads the core purpose, then details entry components, then clarifies capability field semantics, and ends with an explicit usage call. Every sentence contributes valuable information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description provides comprehensive context: what the tool returns, how to interpret the fields, configuration requirements, and when to call it. It equips the agent to use the tool effectively and understand results without additional guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter information. The description doesn't add parameter-specific meaning (there are none), but it thoroughly explains the output structure and field semantics. Baseline for 0 params is 4, and the description meets that without exceeding into parameter territory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List the image-generation providers available to Creative Studio', a specific verb+resource statement. It clearly distinguishes this tool from sibling tools like creative_studio_generate_visual or creative_studio_edit_visual by framing it as a discovery/list operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this before creative_studio_generate_visual to see which providers can be selected', giving a clear when-to-use directive. It also conveys the purpose of checking provider configuration and capabilities, which helps the agent decide to invoke it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses major behaviors: wholesale replacement, no per-asset patch, omitted side preserved, ad replaced under same ID, learning reset, re-review, non-reversibility, and rollback suggestion. Exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat long but every sentence adds essential information: purpose, replacement semantics, preservation behavior, return value, side effects, rollback advice, and alternative tool. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is exceptionally complete. It covers what the tool does, how it behaves, side effects, reversibility, and when to use alternatives. The only missing pieces are already covered by schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 key semantic value by explaining that supplied side is fully replaced and omitted side preserved, which is critical for correct use of headlines/descriptions parameters. It also clarifies fallback behavior for customer_id via schema, but description reinforces it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates creative copy of an RSA by replacing headlines/descriptions. It explicitly distinguishes from google_ads_ads_update_status for status-only changes, avoiding confusion with sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: creative copy updates, with full side replacement semantics. Names the alternative google_ads_ads_update_status for pause/resume and recommends mureo_state_action_log_append for rollback, covering both usage and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly discloses the outbound HTTP GET, timeout, body cap, redirect limit, User-Agent, and SSRF protections. It also explains error handling (returns error field instead of raising) and that customer_id only affects credential routing, not analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, output fields, error handling, side effects, security, and usage. It is front-loaded with the core action and structured logically. Despite length, there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must enumerate return fields, which it does in detail. It also covers side effects, security constraints, error behavior, and use-case guidance. It is fully complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters. The description adds meaningful context beyond the schema, notably that customer_id is "unused by the analysis itself" and only scopes credential routing. URL restrictions are also echoed in the schema, but the description's SSRF detail reinforces behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Fetch a landing page over HTTP(S) and extract structured content for ad-copy alignment." It clearly differentiates from siblings by naming alternatives (search_console_url_inspection_inspect, google_ads_creative_research) and distinct use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: "Use this for ad-copy vs. LP message-match and keyword-extraction workflows." It also names two alternatives with their distinct purposes, giving clear when-to-use vs. when-not-to-use direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses that the tool is mutating, not automatically reversible, and recommends recording before-state with mureo_state_action_log_append. It also mentions the return value (new creative id), which is critical behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, mutability/rollback guidance, and alternatives. Front-loaded with the core action, then critical risks, then distinctions. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity and absence of output schema, the description is complete: it explains the return value, mutation risk, use cases, and alternatives. Combined with detailed input schema, an agent has enough context to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 beyond schema by explaining that link is used for the 'See More card' and as fallback, and by describing the card structure (image/video, name, description, link). This enriches understanding of the parameters without duplicating schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Creates a Carousel AdCreative with 2–10 swipeable cards', giving a specific verb, resource, and format. It clearly distinguishes from sibling tools by naming meta_ads_creatives_create_dynamic and meta_ads_creatives_create_collection as alternatives for different use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use alternatives: 'For auto-optimized asset rotation use meta_ads_creatives_create_dynamic; for product-feed-driven carousels use meta_ads_creatives_create_collection.' Also provides context for when this tool is appropriate (product catalogs or multi-step narratives).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 that the operation is mutating, not automatically reversible, and recommends recording before-state with a specific rollback tool. It also states the return value, which is essential with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: main action, return value, mutation warning with rollback tip, prerequisite, and alternative. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage constraints, mutation/rollback behavior, and return value. Given there's no output schema and no annotations, this is unusually complete for a mutating tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all parameters clearly (100% coverage), so the baseline is 3. The description adds a bit of extra meaning by clarifying that media_id is used 'as creative' and emphasizing the ad_set_id prerequisite, pushing it slightly above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Boosts an organic Instagram post by creating a paid ad') and returns the new ad_id. It distinguishes from sibling meta_ads_ads_create, which is for non-organic ads, and implicitly from page post boosting by specifying Instagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite (ad_set_id must exist with budget/targeting) and gives an explicit 'when-not-to-use' with a named alternative tool. This provides clear guidance for selection relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that the operation is mutating ('Mutating (creates a Page photo)'), not automatically reversible, uploads UNPUBLISHED, requires the pages_manage_posts permission and Page Access Token, and includes a notable quirk about the one-way write field and Meta rejecting context_card{cover_photo_id}. This goes well beyond a simple 'creates a photo' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but exceptionally dense. Every sentence earns its place: purpose, distinction from sibling, typical flow, a verification gotcha, required parameter exclusivity, publication status, auth requirement, and mutability. It is front-loaded with the primary action and returns value, then builds context. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, this description is remarkably complete. It covers the action, return value, use case, integration flow with lead form creation, a common failure mode and how to avoid it, parameter constraints, permission requirements, and write side effects. An agent has everything needed to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all 4 parameters with descriptions (100% coverage), so baseline is 3. The description adds meaningful semantic emphasis by stating 'Provide exactly one of file_path (local image) or image_url' and by explaining the purpose of the resulting photo_id in relation to the lead form context_card. It doesn't re-document every parameter, but it clarifies the critical output-to-input relationship that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource: 'Uploads a photo to a Facebook Page and returns its PAGE photo id.' It clearly distinguishes itself from the sibling meta_ads_images_upload_file by explaining the crucial difference between a Page photo id and an ad-account image_hash, and even names the exact use case (Instant Form cover photo). This is far more than a tautology or vague purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: 'Typical flow: upload here → take photo_id → pass it as context_card.cover_photo_id to meta_ads_lead_forms_create.' It also tells users when NOT to use it (the image_hash from meta_ads_images_upload_file does NOT work) and provides an alternative verification path (meta_ads_lead_forms_get). This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses destructive behavior: it is irreversible, affects DPA/Collection ads on the next serve cycle, and warns about new product_id assignment on re-add. It even suggests a rollback mechanism. This is comprehensive behavioral disclosure beyond the structured fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and returns value, then provides necessary warnings and alternatives. Every sentence earns its place—there is no fluff or redundancy. Length is appropriate for the destructiveness of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's effect (deletes a product), return value (success flag), side effects (ads skip product), reversibility (not automatic), rollback strategy (mureo_state_action_log_append), and an alternative approach. For a destructive tool with no output schema and no annotations, this is exceptionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 explaining the consequence of using product_id with the same retailer_id (new Meta product_id on re-add), which deepens understanding of the product_id parameter beyond its simple schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Deletes a single catalog product.' It distinguishes from siblings like meta_ads_products_update and meta_ads_products_add. The scope is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool and when to avoid it. It names a specific alternative for temporary suppression: 'meta_ads_products_update with availability="out of stock"'. It also advises recording state for rollback, which is contextual usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses that the operation is mutating, not automatically reversible, and that only supplied fields are changed. It also notes the return value and provides specific guidance on rollback state tracking, offering behavioral transparency beyond basic safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, using three sentences that are front-loaded with the core purpose and then provide essential usage and safety context. Every sentence adds distinct value: purpose, mutation warning with rollback guidance, and alternative tool direction. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, no output schema, and no annotations, the description is exceptionally complete. It explains the mutation nature, partial update behavior, return value, rollback strategy, and when to choose an alternative tool. It also implicitly covers the catalog product context by referring to retailer_id and upsert semantics in the sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds value by clarifying that only supplied fields are changed (partial update semantics) and by highlighting availability toggles as a key use case, which enriches understanding of how parameters like availability behave in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates one or more fields on an existing catalog product, using a specific verb and resource. It distinguishes from siblings by explicitly contrasting with meta_ads.products.add for full replacement, and by noting it is the correct entry point for availability toggles, which is unique among product tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it says to use this tool for partial updates and availability toggles, and to use meta_ads.products.add for full record replacement. It also advises recording before-state with mureo_state_action_log_append for rollback, giving clear when-to-use and alternative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 honestly discloses that the tool is mutating, not automatically reversible, and recommends recording before-state with mureo_state_action_log_append. It also explains Meta's test execution and comparison behavior, going well beyond a simple mutation warning.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense, opening with the core purpose and then adding necessary caveats and follow-up guidance. Every sentence earns its place, and the structure flows logically from what → side-effects → prerequisites → next steps.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, 5 required, no output schema), the description fully compensates: it covers creation, return value, side effects, rollback, execution semantics, prerequisites, and post-conclusion workflow. The schema handles parameter specifics, so the description is complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters (100% coverage), but the description adds valuable semantic context: even traffic splitting across cells, the requirement for pre-existing ad sets, and the meaning of confidence_level in terms of spend/duration. This goes beyond the baseline schema-driven understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Creates a new Split Test') and clearly states the return value (study_id). It distinguishes itself from sibling tools like meta_ads_split_tests_get/list/end by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: cells must reference pre-existing ad sets, and analysis after conclusion should use meta_ads_split_tests_get. This gives clear when-to-use guidance and points to the appropriate alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does excellently: it discloses the tool is read-only, issues two REST calls per invocation, does not diff/merge periods, requires agent alignment by first key, and documents return shape. This far exceeds basic safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose, return shape, critical caveat about no merging, safety/read-only, call count, defaults, and alternative tool. The description is front-loaded with the core function and remains dense without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description compensates by specifying the exact return object shape and per-row fields. It also explains alignment logic, default behavior, and gives an explicit sibling alternative, making the tool self-contained for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so baseline is 3. The description adds value by explaining the return structure (keys, clicks, impressions, ctr, position), the alignment requirement, and defaults like dimensions=['query'] and row_limit=100, which reinforces but goes slightly beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Query Search Console search analytics twice and return both periods side-by-side.' It clearly distinguishes this tool from the single-period sibling by contrasting return shape and explicitly naming the alternative for single-period queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use this tool versus alternatives: 'For a single-period query use search_console_analytics_query.' It also clarifies that the tool does not diff/merge and the agent must align rows, setting clear expectations for how to use the returned data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses read-only behavior, no input, and the exact return format including the siteEntry array structure and permission level enums. This fully covers the behavioral burden for a simple 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, then a compact return specification and an alternative tool reference. Every sentence earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no params and no output schema, but the description explains the return array, field types, read-only nature, and the alternative for single-site metadata. It is complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters, and the description confirms 'takes no input'. Since there are no parameters to clarify, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List every Search Console property...' plus explicitly distinguishes from sibling search_console_sites_get. The return shape is also detailed, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states 'regardless of permission level' showing the full scope, and explicitly directs to search_console_sites_get for single-property queries. This gives 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that the tool is mutating, not automatically reversible, and recommends recording before-state via mureo_state_action_log_append. It also explains the return values, Meta's image hosting behavior, mandatory thumbnail for video, video processing requirements, and the CTA requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: purpose first, then return values, mutating warning, mode-specific instructions, and finally sibling tool alternatives. Every sentence adds value with no redundancy or fluff, keeping the length appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 params, two modes, mutual exclusions, prerequisites, and rollback concerns), the description is remarkably complete. It covers prerequisites, return values, mutating nature, parameter relationships, and when to use alternatives—all without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial meaning beyond the schema: explaining image_url vs image_hash semantics, mutual exclusivity of video/image parameters, the requirement for call_to_action in video mode, and the thumbnail preconditions. This dramatically improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Creates a single image or video Meta Ads AdCreative.' It clearly distinguishes from siblings by naming meta_ads_creatives_create_carousel and meta_ads_creatives_create_dynamic as alternatives for other use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: image mode vs video mode, which parameters to supply in each, prerequisites like video processing and thumbnail selection, and directs carousel/dynamic use cases to alternative tools. This is comprehensive context for selecting and invoking the tool correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It covers atomicity, merging per window key, preservation of omitted fields and other platforms/campaigns, the always-written account_id, and return of the updated state document. This is comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph that is well-structured and front-loaded. Every sentence adds value: purpose, differentiation, parameter guidance, merge behavior, and return value. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested objects and no output schema, the description fully covers what the tool does, how parameters interact, side effects, and return value. It also explains the functional context (read-only dashboard toggle), making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description adds crucial meaning: it explains the relationship between totals/metrics_period and periods, merge semantics with a concrete YESTERDAY/LAST_30_DAYS example, and the platform key uniqueness rule. This significantly clarifies parameter usage beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool atomically sets a platform-level metric rollup in STATE.json's v2 platforms section. It explicitly distinguishes itself from mureo_state_upsert_campaign, which writes per-campaign metrics, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the tool is for feeding the read-only reporting dashboard's per-platform KPIs and period toggle without re-querying. It explicitly names the alternative tool (mureo_state_upsert_campaign) and contrasts when each should be used, plus detailed guidance on totals vs periods parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mureo MCP server](https://glama.ai/mcp/servers/logly/mureo/badges/card.svg)](https://glama.ai/mcp/servers/logly/mureo)

Score Badge

Copy to your README.md:

[![mureo MCP server](https://glama.ai/mcp/servers/logly/mureo/badges/score.svg)](https://glama.ai/mcp/servers/logly/mureo)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/logly/mureo'

If you have feedback or need assistance with the MCP directory API, please join our Discord server