Server Quality Checklist

Tool Scores

• analyze_single_adC
  2.8/5.0
  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. It mentions the tool performs AI analysis and returns specific outputs, but lacks critical behavioral details such as whether it's read-only or mutative, permission requirements, rate limits, or error handling. For a tool with 4 required parameters and no annotation coverage, this is a significant gap.

  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 brief and front-loaded with the core purpose in the first sentence, followed by a technical note. It avoids redundancy, but the second sentence could be integrated more smoothly. Overall, it's efficient with minimal waste.

  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?

  Given the complexity (4 required parameters, no annotations) and the presence of an output schema (which handles return values), the description is incomplete. It covers the basic action and output types but misses parameter explanations and behavioral context. It's minimally adequate but has clear gaps for a tool with this level of complexity.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the schema provides no parameter details. The description adds minimal value by implying date parameters ('Dates in YYYY-MM-DD format'), but doesn't explain the semantics of 'ad_id', 'account_id', or the purpose of the date range. This fails to compensate for the low coverage, leaving most parameters undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Run AI analysis') and resource ('on a single ad'), and specifies the output ('detailed analysis, performance score, and recommendations'), which distinguishes it from siblings like 'analyze_account_ads' or 'analyze_campaign_ads' that handle multiple ads. However, it doesn't explicitly differentiate from all siblings, such as 'get_account_analysis', which might overlap in purpose.

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

  Usage Guidelines2/5

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

  The description provides no guidance on when to use this tool versus alternatives like 'analyze_account_ads' or 'get_account_analysis', nor does it mention prerequisites or exclusions. The date format note is a technical detail, not usage context, leaving the agent with no help in selecting among similar tools.

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

• analyze_campaign_adsB
  3.1/5.0
  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. It mentions that the tool 'Returns performance scores and recommendations,' which gives some behavioral insight. However, it lacks critical details: whether this is a read-only operation, if it triggers background processing, potential rate limits, authentication requirements, or error conditions. For a tool with 4 required parameters and no annotation coverage, this is insufficient.

  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 highly concise and front-loaded: the first sentence states the core purpose and output, while the second provides essential usage notes. Every sentence adds value without redundancy. At 3 sentences total, it's 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?

  Given the tool has an output schema (which covers return values), the description doesn't need to explain outputs. However, with 4 required parameters, 0% schema coverage, and no annotations, the description should do more to compensate. It provides basic purpose and some parameter guidance but lacks behavioral transparency and complete parameter semantics, making it minimally adequate but with clear gaps.

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

  Parameters2/5

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

  Schema description coverage is 0%, so the description must compensate. It adds meaning for campaign_id ('comes from list_campaigns') and date parameters ('Dates in YYYY-MM-DD format'), which covers 3 of 4 parameters. However, account_id is entirely undocumented in both schema and description, leaving a significant gap. The description provides partial but incomplete parameter semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/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: 'Run AI analysis on all ads in a campaign. Returns performance scores and recommendations.' This specifies the verb ('Run AI analysis'), resource ('all ads in a campaign'), and output type. However, it doesn't explicitly differentiate from siblings like analyze_account_ads or analyze_single_ad, which would require a 5.

  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 provides some usage context: 'campaign_id comes from list_campaigns' implies a prerequisite tool and 'Dates in YYYY-MM-DD format' specifies date formatting. However, it doesn't explicitly state when to use this tool versus alternatives like analyze_account_ads or analyze_single_ad, nor does it mention exclusions or specific scenarios. This is implied guidance rather than explicit.

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

• generate_ad_from_urlB
  3.3/5.0
  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 of behavioral disclosure. It mentions that 'Brand guidelines are resolved server-side,' which adds useful context about how inputs are handled. However, it lacks details on critical behaviors like whether this is a read-only or mutation operation, potential rate limits, error handling, or what the output entails (though an output schema exists). For a tool with no annotations, this is insufficient.

  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 highly concise and well-structured: three sentences that efficiently convey purpose, parameter guidance, and server-side behavior. Each sentence adds clear value without redundancy, making it easy to parse and front-loaded with key information.

  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?

  Given the tool has an output schema (which handles return values) but no annotations and 0% schema coverage, the description is moderately complete. It covers the core purpose and parameter usage but misses behavioral details like mutation status or error cases. For a tool with 5 parameters and no annotations, it should provide more context to be fully adequate.

  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 0%, so the description must compensate. It explains that 'product_url' is the only required parameter and others have 'smart defaults,' adding meaning beyond the bare schema. However, it doesn't describe what the other parameters (objective, platform, ad_type, aspect_ratio) do or their possible values, leaving significant gaps. With 0% coverage, the description provides some but not enough semantic detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/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: 'Generate an ad creative concept from a product URL.' It specifies the verb ('generate'), resource ('ad creative concept'), and input source ('from a product URL'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'generate_ad_concepts', which might have overlapping functionality, so it doesn't reach a perfect score.

  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 provides some usage guidance by stating 'Only ask the user for product_url — all other params have smart defaults,' which implies when to use this tool (for quick generation with defaults) and hints at alternatives (tools requiring more parameters). However, it doesn't explicitly name when-not-to-use scenarios or specific sibling alternatives, leaving some ambiguity.

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

• get_competitor_adsA
  4.1/5.0
  Behavior3/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 implies a read-only operation ('Get') and specifies data source ('scraped ads'), but doesn't disclose behavioral traits like rate limits, authentication needs, or what happens if the competitor_id is invalid. It adds some context about the ID source, but lacks details on response format or potential errors.

  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 zero waste. The first sentence states the purpose and scope, and the second provides essential usage guidance. It's front-loaded with the core action and efficiently conveys necessary information without 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 1 parameter with 0% schema coverage and an output schema (which handles return values), the description is mostly complete. It covers purpose, parameter semantics, and usage context. However, as a read tool with no annotations, it could benefit from mentioning behavioral aspects like data freshness or limitations, but the output schema reduces this need.

  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 description coverage is 0%, so the description must compensate. It adds crucial meaning beyond the schema: 'competitor_id must come from list_competitors — match by brand name, then use the internal ID.' This explains how to obtain and validate the parameter, which is not in the schema. For a single parameter with no schema documentation, this is excellent compensation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and resource 'scraped ads for a specific competitor', specifying it includes 'creative previews and copy'. It distinguishes from siblings like 'analyze_account_ads' or 'scrape_competitor_ads' by focusing on retrieval rather than analysis or scraping. However, it doesn't explicitly contrast with all siblings, such as 'get_account_analysis' or 'get_scrape_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?

  It provides clear context: 'competitor_id must come from list_competitors — match by brand name, then use the internal ID.' This tells when to use (after identifying a competitor via list_competitors) and how to obtain the parameter. It doesn't explicitly state when not to use or name alternatives like 'scrape_competitor_ads' for new data, but the guidance is sufficient for correct invocation.

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

• list_competitorsA
  4.1/5.0
  Behavior3/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 this is a list operation (implying read-only behavior) and mentions the output includes internal IDs for downstream use. However, it lacks details on behavioral traits like pagination, rate limits, error handling, or what 'tracked' means. The description adds some context but doesn't fully compensate for 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 highly concise and well-structured: three sentences that efficiently convey purpose, parameter guidance, and downstream usage. Each sentence earns its place by adding critical information without redundancy, making it front-loaded and easy to parse.

  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 (simple list operation), one parameter with 0% schema coverage, and the presence of an output schema, the description is fairly complete. It covers purpose, parameter semantics, and usage context. However, it could improve by addressing behavioral aspects like what 'tracked' entails or output specifics, though the output schema may handle some of this.

  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 description coverage is 0%, so the description must compensate. It explains that 'account_id comes from get_my_accounts', adding semantic meaning beyond the schema's type and requirement. This clarifies the parameter's source and purpose, though it doesn't detail format or constraints. With one parameter and partial compensation, this exceeds the baseline for low coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'List' and resource 'tracked competitor brands with their internal IDs', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_competitor_ads' or 'scrape_competitor_ads' beyond mentioning they require IDs from this response, which provides some differentiation but not a complete distinction.

  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: it states that 'account_id comes from get_my_accounts' (prerequisite), and 'Use competitor IDs from this response for get_competitor_ads and scrape_competitor_ads' (downstream usage). This gives clear context on when and how to use this tool in relation to alternatives, though it doesn't explicitly say 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.

• get_google_performanceA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries full burden. It discloses key behavioral traits: it's a read operation (implied by 'Get'), requires a customer_id from another tool, uses specific date formats, and has default date logic. However, it doesn't mention rate limits, authentication needs, error handling, or pagination behavior, leaving gaps for a tool with 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?

  Two sentences with zero waste: first states purpose and metrics, second provides essential parameter guidance. It's front-loaded with core functionality and efficiently adds necessary context. Every sentence earns its place by addressing critical usage 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?

  Given 3 parameters with 0% schema coverage and an output schema (which handles return values), the description is mostly complete. It explains parameter semantics and usage context well. However, as a read tool with no annotations, it could better address behavioral aspects like rate limits or error cases, slightly reducing completeness.

  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 0%, so the description must compensate. It adds significant meaning: explains customer_id source ('from get_my_accounts'), date format ('YYYY-MM-DD'), and default behavior ('last 30 days'). This covers all 3 parameters well, though it doesn't detail null handling for dates or parameter constraints beyond format.

  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 ('Get') and resource ('Google Ads performance metrics') with specific metrics listed (spend, impressions, clicks, CTR, CPC, conversions, ROAS). It distinguishes from siblings like 'get_meta_performance' (different platform) and analysis tools (e.g., 'analyze_account_ads') by focusing on metric retrieval rather than analysis.

  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 it: for Google Ads metrics with date filtering. It explicitly references 'customer_id comes from get_my_accounts' and gives date format/range guidance. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings (e.g., vs. 'get_account_analysis'), though the purpose distinction is implied.

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

• get_meta_performanceA
  4.2/5.0
  Behavior3/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 key behavioral traits: it's a read operation (implied by 'Get'), requires account_id from another tool, and has date formatting and default behavior. However, it doesn't mention potential rate limits, authentication needs, error handling, or pagination, leaving gaps for a tool with 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?

  The description is appropriately sized and front-loaded: first sentence states purpose and metrics, second sentence covers key parameters and defaults. Every sentence adds value with zero waste, making it efficient for an AI agent to parse.

  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 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is largely complete. It explains the tool's purpose, parameter semantics, and usage context. The output schema likely covers return values, so no need to detail them. Minor gaps include lack of error cases or advanced behavioral traits.

  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 0%, so the description must compensate. It adds meaning for all 3 parameters: account_id (source from 'get_my_accounts'), start_date/end_date (format YYYY-MM-DD, default last 30 days). This covers semantics beyond schema types, though it could detail null handling or date validation more explicitly.

  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 specific action ('Get') and resource ('Meta Ads performance metrics') with explicit listing of metrics (spend, impressions, clicks, CTR, CPC, ROAS, conversions). It distinguishes from siblings like 'get_google_performance' by specifying the platform (Meta Ads) and from analysis tools by focusing on raw metrics retrieval rather than analysis.

  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 it: to obtain performance metrics for Meta Ads, with account_id sourced from 'get_my_accounts' and date defaults to last 30 days. However, it lacks explicit guidance on when NOT to use it or alternatives (e.g., vs. 'analyze_account_ads' for deeper insights), though the specificity helps differentiate from siblings.

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

• scrape_competitor_adsA
  4.2/5.0
  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 effectively describes key traits: the tool starts an async job (implying it's non-blocking), returns a run_id for tracking, and requires polling via 'get_scrape_status' to check completion. It doesn't mention error handling, rate limits, or permissions, but covers the core async behavior well, justifying a 4.

  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 highly concise and well-structured in two sentences: the first states the purpose, and the second provides clear usage steps. Every sentence earns its place by delivering essential information without redundancy, making it front-loaded and efficient.

  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 (async job with polling), no annotations, and an output schema (which likely covers the run_id return), the description is fairly complete. It explains the async nature and workflow but lacks details on error cases or prerequisites. With output schema handling return values, it's adequate but not exhaustive, warranting a 4.

  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 1 parameter with 0% description coverage, so the description must compensate. It mentions 'account_id' implicitly in the context of fetching competitor ads but doesn't explain what this parameter represents (e.g., an account identifier for targeting). The description adds minimal semantic value beyond the schema, resulting in a baseline 3.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/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: 'Start an async scrape job to fetch fresh competitor ads.' It specifies the verb ('Start'), resource ('async scrape job'), and target ('competitor ads'), distinguishing it from siblings like 'get_competitor_ads' (which retrieves results) or 'analyze_account_ads' (which analyzes). However, it doesn't explicitly differentiate from all siblings (e.g., 'list_competitors'), so it's not a perfect 5.

  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 instructions: 'Then call get_scrape_status with that run_id and poll every few seconds until status is 'completed', then call get_competitor_ads.' It clearly outlines the workflow and when to use this tool versus alternatives (e.g., 'get_competitor_ads' for results), making it highly actionable for an AI agent.

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

• generate_ad_conceptsA
  4.4/5.0
  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 of behavioral disclosure. It clearly indicates this is a generation/creation tool (not read-only) and provides important workflow guidance about parameter sourcing. However, it doesn't disclose other behavioral traits like rate limits, authentication needs, output format, or whether this creates persistent resources versus temporary concepts.

  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 perfectly front-loaded with the core purpose in the first sentence, followed by essential usage guidance. Every sentence earns its place by providing critical information about parameter sourcing and workflow constraints. No wasted words or redundant 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?

  Given the tool has an output schema (so return values are documented elsewhere), no annotations, and 3 parameters with 0% schema coverage, the description does well by explaining the critical product_id parameter workflow. However, it leaves ad_type and ad_objective parameters completely unexplained, which is a gap for a tool with multiple parameters.

  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?

  With 0% schema description coverage, the description must compensate. It provides crucial semantic guidance for the product_id parameter (must come from list_products, match user mentions, use internal ID). However, it doesn't explain the semantics of ad_type or ad_objective parameters, which have defaults but no explanation of what values are valid or what they mean.

  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 specific action ('generate multiple ad creative concepts') and the target resource ('for an existing product in the system'), distinguishing it from siblings like generate_ad_from_url or analyze_* tools. It provides a complete verb+resource+scope 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 explicitly states when to use this tool ('for an existing product in the system') and provides clear prerequisites ('product_id must come from list_products'). It also gives specific guidance on parameter sourcing ('match the product name the user mentions, then pass the corresponding internal ID') and what not to do ('Never ask the user to provide a product ID').

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

• list_campaignsA
  4.4/5.0
  Behavior3/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 this is a read operation ('List') and specifies the return fields (IDs, names, status, budget), which helps understand behavior. However, it doesn't mention potential limitations like pagination, rate limits, or authentication requirements, leaving some behavioral aspects unclear.

  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 extremely concise with only two sentences, both carrying essential information. The first sentence establishes purpose and scope, while the second provides usage guidelines. There is zero wasted text, and information is front-loaded appropriately.

  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 has an output schema (which handles return values), the description focuses appropriately on purpose, usage, and parameter semantics. It covers the essential context for a simple listing tool with one parameter. The main gap is lack of behavioral details like pagination or rate limits, but the output schema reduces the need for return value explanation.

  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 0%, so the description must compensate. It provides crucial semantic context for the single parameter: 'account_id comes from get_my_accounts' explains where to obtain this value and establishes a dependency. This adds meaningful information beyond the bare schema type, though it doesn't specify format constraints or validation rules.

  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 specific action ('List all campaigns'), resource ('for a Meta ad account'), and scope ('with their IDs, names, status, and budget'). It explicitly distinguishes from siblings like analyze_campaign_ads by specifying this tool provides campaign IDs for use in that sibling.

  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: 'account_id comes from get_my_accounts' establishes a prerequisite dependency. It also specifies when to use alternatives: 'Use campaign IDs from this response in analyze_campaign_ads' directs users to the appropriate sibling tool for deeper analysis.

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

• analyze_account_adsA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden and discloses key behavioral traits: expensive operation, 30-60 second duration, and confirmation requirement. It doesn't cover error handling or output format, but provides substantial operational context beyond basic 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?

  Four sentences with zero waste: first states purpose, second warns of cost/time, third gives prerequisites/alternative, fourth specifies invocation condition. Each sentence adds critical information, and warning is appropriately 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?

  For a complex, expensive operation with no annotations but an output schema, the description covers purpose, costs, prerequisites, alternatives, and invocation conditions well. It doesn't explain what 'full AI analysis' entails or potential errors, but given output schema exists, this is reasonably 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 description coverage is 0%, so description must compensate. It explains the confirmed parameter's purpose (user explicit request) and implies date range usage, though doesn't detail account_id, start_date, or end_date formats. Adds meaningful context for one parameter and overall usage.

  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 specific action ('Re-run a full AI analysis') and resource ('ALL ads in the account'), distinguishing it from siblings like analyze_campaign_ads, analyze_single_ad, and get_account_analysis by emphasizing comprehensive scope and re-analysis nature.

  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 get_account_analysis for existing results, only call after user explicitly requests fresh re-analysis, and prerequisites (individual ads analyzed first). Clear alternatives and when-not-to-use scenarios are specified.

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

• get_account_analysisA
  4.6/5.0
  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 effectively discloses key behavioral traits: it's a read operation ('Fetch'), fast performance, reads from a database, and does not re-run analysis. However, it lacks details on permissions, rate limits, 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?

  Two sentences, front-loaded with core purpose, followed by performance note and usage guidance. 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.

  Completeness4/5

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

  Given 1 parameter, no annotations, but an output schema exists, the description is mostly complete. It covers purpose, usage, and behavior well, but could improve by hinting at return format or error cases, though output schema mitigates this.

  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 0%, so the description must compensate. It implies the 'account_id' parameter is needed to specify which account's ads to analyze, adding context beyond the bare schema. However, it doesn't detail format or constraints for 'account_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 ('Fetch'), resource ('most recent stored AI analysis for all ads in an account'), and scope ('all ads in an account'). It specifically distinguishes itself from sibling 'analyze_account_ads' by noting it reads from the database without re-running analysis, avoiding duplication.

  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 ('Use this before analyze_account_ads') and distinguishes from an alternative ('Fast — reads from the database without re-running analysis'), indicating it's for retrieving existing data rather than generating new analysis.

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

• get_scrape_statusA
  4.6/5.0
  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 effectively describes the tool's polling nature, status values, and expected workflow sequence. However, it doesn't mention potential rate limits, error handling for 'failed' status, or authentication requirements, leaving some behavioral aspects unspecified.

  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 perfectly front-loaded with the core purpose, followed by essential status values and explicit usage instructions. Every sentence earns its place by providing critical operational guidance without redundancy or unnecessary elaboration.

  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 polling nature and the existence of an output schema (which presumably covers status return values), the description provides strong contextual completeness. It explains the workflow relationship with sibling tools, status values, and polling behavior. The main gap is lack of error handling guidance for 'failed' status.

  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 0% description coverage for its single parameter 'run_id', but the description compensates by explaining that this tool checks the status of 'a competitor scrape job started by scrape_competitor_ads', implicitly defining run_id as the identifier returned by that initiating tool. This adds meaningful context beyond the bare schema type declaration.

  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 specific action ('Poll the status') and resource ('competitor scrape job started by scrape_competitor_ads'), distinguishing it from siblings like scrape_competitor_ads (which starts the job) and get_competitor_ads (which retrieves results). It explicitly names the initiating tool, establishing a clear workflow relationship.

  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: after calling scrape_competitor_ads, and when to stop using it (when status is 'completed', then call get_competitor_ads). It also specifies polling frequency ('every few seconds') and names the alternative tool for retrieving results, creating a complete usage protocol.

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

• resume_adA
  4.6/5.0
  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 effectively describes the tool's dual-mode behavior (resuming vs. returning a confirmation message) and the confirmation requirement, which are critical for safe operation. However, it doesn't mention potential side effects like budget implications 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?

  The description is front-loaded with the core purpose, followed by critical usage guidelines. Every sentence earns its place: the first explains what the tool does, the second specifies the confirmation requirement, and the third defines the alternative behavior. No wasted words.

  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 operational nature (resuming ads), no annotations, and an output schema (which handles return values), the description is mostly complete. It covers purpose, usage rules, and parameter behavior. However, for a mutation tool, it could benefit from mentioning permissions or irreversible effects.

  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 0% description coverage, so the description must compensate. It explains the 'confirm' parameter's purpose and the conditional behavior based on its value. While it doesn't explicitly mention 'ad_id', the context implies it identifies the ad to resume. This adds meaningful context beyond the bare 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 verb ('Resume') and resource ('a paused Meta ad'), and specifies the outcome ('The ad will start spending again'). It distinguishes from sibling tools like 'pause_ad' by being the opposite action, and from analysis tools by being an operational command.

  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 instructions: 'Only call with confirm=True after the user has explicitly confirmed they want to resume this specific ad. If confirm is False, return the confirmation message.' This clearly defines when to use (with user confirmation) and the alternative behavior (returning a message without confirmation).

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

• get_my_accountsA
  4.7/5.0
  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 effectively describes key behaviors: the tool returns account IDs (not asking users for them), has conditional execution based on environment variables, and handles multi-account scenarios by listing them for user choice. It doesn't mention error conditions or rate limits, but covers the essential workflow.

  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 in four sentences, each adding distinct value: purpose statement, usage priority, environment variable handling, and multi-account scenario. There's no redundant information, and critical guidance 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 simplicity (0 parameters, output schema exists), the description provides complete context. It explains what the tool does, when to use it, special conditions, and how to handle results. With an output schema handling return values, the description appropriately focuses on workflow rather than output structure.

  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 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters since none exist, focusing instead on the tool's purpose and usage 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's purpose with specific verbs ('Get') and resources ('user's connected Meta ad account IDs and Google Ads customer IDs'). It distinguishes itself from sibling tools by focusing on account retrieval rather than analysis, generation, or management operations.

  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: 'Call this first before any other tool — never ask the user for account IDs.' It also specifies conditions for skipping the call when MUZE_DEFAULT_ACCOUNT_ID is set and what to do when multiple accounts exist. This gives clear when-to-use and alternative handling instructions.

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

• list_productsA
  4.7/5.0
  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 effectively communicates that this is a read-only operation (listing products) and specifies the data returned, but does not mention potential limitations like pagination, rate limits, or authentication needs. However, it adds valuable context about resolving product IDs, which is helpful beyond basic functionality.

  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 highly concise and front-loaded, consisting of two sentences that each serve a clear purpose: the first states what the tool does, and the second provides critical usage guidance. There is no wasted language, and the structure efficiently conveys essential 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 (0 parameters, no annotations, but with an output schema), the description is complete. It clearly explains the tool's purpose, usage context, and output details, and the presence of an output schema means return values need not be described. This covers all necessary aspects for effective agent use.

  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 has 0 parameters with 100% coverage, so the baseline is 4. The description does not add parameter-specific information, but this is appropriate given the lack of parameters. It compensates by explaining the tool's role in resolving product IDs, which is semantically relevant to its usage.

  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 specific action ('List products') and resource ('in the user's account'), distinguishing it from siblings like list_campaigns or list_competitors. It provides concrete details about what information is returned (internal IDs, names, URLs, selling propositions), making the purpose explicit 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 states when to use this tool ('Call this before generate_ad_concepts to resolve product_id') and when not to ('never ask the user for IDs directly'). It names a specific alternative (generate_ad_concepts) and provides clear context for its application, offering complete guidance.

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

• pause_adA
  4.7/5.0
  Behavior4/5

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

  With no annotations provided, the description carries full burden and does well: it discloses the immediate effect ('stop spending immediately'), the confirmation requirement, and the conditional behavior based on the confirm parameter. It doesn't mention permissions, rate limits, or error conditions, but provides 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?

  The description is perfectly front-loaded with the core purpose, followed by critical usage guidelines. Every sentence earns its place: the first explains what the tool does, the second provides essential safety guidance, and the third clarifies the alternative behavior. No wasted words.

  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 this is a destructive mutation tool with no annotations but with an output schema (which handles return values), the description is nearly complete. It covers purpose, critical usage constraints, and parameter semantics. It could mention authentication requirements or error cases, but the output schema likely handles response formatting.

  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?

  With 0% schema description coverage, the description fully compensates by explaining both parameters: ad_id is implied as the identifier for 'this specific ad,' and confirm is thoroughly documented with its boolean logic, default behavior (implied by the guidance), and the different outcomes based on its 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 specific action ('Pause a live Meta ad') and resource ('ad'), distinguishing it from sibling tools like 'resume_ad' (which does the opposite) and analysis tools. It goes beyond just restating the name by specifying it's for live ads that will stop spending immediately.

  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: 'Only call with confirm=True after the user has explicitly confirmed they want to pause this specific ad.' It also distinguishes when not to use it (when confirm is False) and specifies the alternative behavior in that case (return confirmation message).

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