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

Annotations already mark this as read-only (readOnlyHint=true) and open-world (openWorldHint=true). The description adds the behavioral insight of intelligent caching, which makes repeated calls efficient and cost-free. It does not contradict the annotations and provides useful 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loaded with 'REQUIRED' and the core purpose. Every sentence adds value: purpose, usage context, and caching benefit. There is no fluff or repetition.

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

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

The description gives strong usage context and lists what elements will be extracted, partially covering return value expectations. However, it omits parameter explanations and does not describe the output format or error handling. For a tool with no output schema and zero param documentation, this leaves meaningful gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'every image URL' which maps to the media_urls parameter, but it does not explain the purpose of ad_id or brand_name, nor the string-or-array flexibility of media_urls. Only minimal parameter insight is provided.

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

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

The description clearly states the tool's purpose: analyzing images from Facebook ads. It specifies the action (download and analyze), the resource (ad images), and the extracted elements (visual elements, text, colors, people, brand, composition), distinguishing it from the video-analyzing sibling tool.

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

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

Explicit usage guidance is provided: it is REQUIRED for every image URL from get_meta_ads during comprehensive analysis. This names the specific source tool and implies the alternative (analyze_ad_video) for video URLs, making the when-to-use decision clear.

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

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

Annotations provide readOnlyHint=true, which covers safety. The description adds behavioral context by mentioning that it downloads videos, uses Gemini's capabilities, and employs intelligent caching. This goes beyond the annotations without contradicting them, offering useful context about how the tool operates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, with three sentences that front-load the key purpose and then list specific analysis capabilities and the caching feature. Every sentence adds value without unnecessary fluff.

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

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

There is no output schema, so the description should explain return values. It lists the types of insights extracted (visual storytelling, audio, etc.) but does not describe the response structure or how the output is presented. This leaves gaps for an agent expecting to use the results.

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

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

Schema description coverage is 0%, and the description does not explain the parameters beyond implying media_url is the video source. It fails to clarify the purpose of ad_id and brand_name, leaving the agent without guidance on how these optional parameters affect the analysis.

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

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

The description clearly states the tool's primary function: 'analyzing video ads from Facebook' and 'Download and analyze ad videos'. It specifies the verb (analyze), resource (video ads), and source platform (Facebook), which distinguishes it from sibling tools like analyze_ad_image.

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

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

The description emphasizes 'REQUIRED for analyzing video ads from Facebook', clearly indicating the primary use case. However, it does not explicitly mention when not to use it or name alternatives such as analyze_ad_image or analyze_ad_videos_batch, so it lacks explicit exclusions and alternative guidance.

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

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

Annotations already provide readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds useful context about 'intelligent caching' and 'shared prompt optimization,' but does not disclose potential limitations like rate limits, video size caps, or failure behavior for a batch operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is around 40 words across four sentences, which is acceptable, but it redundantly mentions token efficiency twice ('maximum token efficiency' and 'reduces token costs') and includes vague filler like 'comprehensive batch video analysis.' It is front-loaded with 'REQUIRED' but could be tighter.

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

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

With no output schema and only 0% schema coverage, the description should explain what the batch analysis returns (e.g., per-ad results, aggregated summary) and any input constraints (e.g., URL count, formats, auth). It only provides high-level intent and benefits, leaving critical gaps for a batch processing tool.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. It only alludes to media_urls via 'video ads' and completely omits ad_ids and brand_names. It does not clarify the role of optional parameters or how they affect batch output, leaving the agent under-informed.

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

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

The description clearly states the tool is 'REQUIRED for batch analyzing multiple video ads from Facebook' and details its function: 'Download and analyze multiple ad videos using Gemini's advanced video understanding in a single API call.' This distinct verb+resource specification and emphasis on batch processing cleanly separates it from the sibling analyze_ad_video.

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

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

It explicitly positions the tool as the required choice for batch analysis and highlights 'significantly reduces token costs compared to individual video analysis.' This gives a clear when-to-use signal, but it does not explicitly name the sibling analyze_ad_video or state scenarios where individual analysis would be preferable, leaving a small gap.

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

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

Annotations indicate readOnlyHint=false, so the description correctly implies a mutation operation. It adds that the tool 'removes old cached media' and 'frees disk space,' but it does not disclose whether deletion is permanent/reversible, whether it requires special permissions, or what happens to associated metadata. For a deletion tool, this lacks critical safety info, but the core action is conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is redundant and has fluff: the opening 'REQUIRED' is unexplained, 'cleaning up old cached media files' is repeated as 'cache maintenance,' and 'Essential for' adds little. It could be trimmed to one or two sentences without losing meaning. It is not overly long, but not tight either.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the primary use case and when to trigger it. However, it omits the parameter's role, any return value or success/failure indications, and the irreversible nature of deletion. Given the low complexity, this is borderline adequate but leaves room for improvement.

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

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

The input schema has one parameter, max_age_days, and schema_description_coverage is 0%. The description makes no mention of this parameter, leaving the agent to infer its purpose from the name alone. Since the description does not compensate for the low coverage, the parameter's meaning (how age is defined, default behavior, impact of changing it) remains ambiguous.

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

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

The description clearly identifies the tool as cleaning up old cached media files (images and videos) and freeing disk space, which is a specific action on a specific resource. It distinguishes itself from sibling tools like analyze_ad_video and search_cached_media by focusing on deletion/cleanup rather than analysis or search.

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

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

The description explicitly states when to use the tool: 'when users want to remove old cached media, clean up storage space, or when cache becomes too large.' It provides clear context and a user-intent trigger, though it does not explicitly mention when not to use it or suggest alternative sibling tools such as get_cache_stats for checking cache size.

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

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

Annotations already cover readOnlyHint=true, so the safe-read nature is established. The description adds useful behavioral context about what it reports (storage usage, file counts) beyond the annotation, without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact (two sentences) with the key purpose front-loaded ('REQUIRED'). The final sentence 'Essential for cache management and monitoring' is slightly redundant but not harmful.

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

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

For a zero-parameter, read-only stats tool with clear annotations, the description adequately provides purpose and usage context. It describes what data is reported (storage space, cached file counts) even without an output schema, making it complete for its simplicity.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuously). The description need not explain parameters, making baseline 4 appropriate.

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

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

The description clearly states it is for 'checking media cache status and storage usage' and lists specific metrics (storage space, files analyzed and cached). This distinguishes it from sibling tools like cleanup_media_cache (mutation) and search_cached_media (search).

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

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

It explicitly says 'REQUIRED' and names concrete user intents ('cache statistics', 'storage space used', 'how many files have been analyzed'). It does not mention exclusions or alternatives, but the use cases are clear enough for a no-parameter read-only tool.

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

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

Given the readOnlyHint=true annotation, the description adds useful behavioral context beyond safety: it fetches only active ads, includes content/media/dates/targeting, and discloses that visual analysis requires a separate tool. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with front-loaded purpose, no redundancy, and each sentence adds essential information about usage and limitations.

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

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

The description covers the core purpose, usage sequence, output fields, and a key limitation. However, it omits explanations for optional parameters and does not describe the return structure in detail, which is more critical given the lack of an output schema.

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

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

With 0% schema description coverage, the description must compensate but only explains the required platform_ids parameter. The optional parameters trim, limit, and country are not described, leaving their meaning unclear.

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

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

The description clearly states 'Retrieve currently running ads for a brand using their Meta Platform ID,' identifying the action, resource, and scope. It distinguishes itself from sibling tools like get_meta_platform_id and analyze_ad_image by explicitly naming them.

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

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

It provides explicit usage guidance: 'Use this tool after getting a platform ID from get_meta_platform_id' and directs users to 'MUST also use analyze_ad_image on the media_url' for visual analysis, covering both workflow and complementary alternatives.

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

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

Annotations already signal read-only (readOnlyHint=true) and open-world (openWorldHint=true) behavior. The description adds that it searches the live Facebook Ad Library and returns platform IDs, but does not disclose multiple-match behavior, failure modes, or rate limits. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose, but sentences 1 and 3 repeat nearly the same information ('Search for companies or brands...' and 'searches the Facebook Ad Library to find matching brands'). It could be tightened to two sentences.

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

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

For a simple one-parameter read-only search, the description explains the core output (platform IDs) and the integration point (before ad retrieval). However, with no output schema, it omits details about no-match results, multiple IDs per brand, and response format, leaving some uncertainty.

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

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

The input schema has 0% description coverage for brand_names. The description mentions 'companies or brands' and 'matching brands,' but does not specify accepted format (string vs array), matching semantics (exact/fuzzy), or handling of multiple brands. It only partially compensates for missing schema documentation.

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

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

The description opens with a specific verb+resource: 'Search for companies or brands in the Meta Ad Library and return their platform IDs.' It clearly distinguishes from sibling get_meta_ads by framing this as the prerequisite ID lookup step ('before retrieving their ads').

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

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

It provides explicit context: 'Use this tool when you need to find a brand's Meta Platform ID before retrieving their ads.' It does not mention exclusions or alternatives, but the workflow positioning makes the target use case clear.

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

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

Annotations already mark the tool as read-only (readOnlyHint=true), so the description adds some context about retrieving past analysis results and avoiding re-downloads. However, it does not disclose return format, pagination behavior, or any limitations, which leaves gaps beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with 'REQUIRED' and a clear purpose. It efficiently covers use cases and benefits, though the final sentence partially restates the first, making it slightly redundant.

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

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

For a search tool with all optional parameters and no output schema, the description gives a clear role and use cases but lacks details on returned fields and limit behavior. The agent would benefit from more explicit information about what the search results contain.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions four of five parameters (brand_name, has_people, color_contains, media_type) but does not explain value formats (e.g., how to specify colors) or the limit parameter. This provides partial but not complete parameter guidance.

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

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

The description clearly states the tool searches previously analyzed ad media (images and videos) in cache, with specific use cases such as searching by brand name, people, colors, and media type. It distinguishes itself from sibling analysis and cache management tools by emphasizing retrieval of past results without re-downloading.

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

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

The description explicitly says to use this tool for searching cached media with various filters and frames it as REQUIRED and Essential. It implies alternatives by noting retrieval without re-downloading, but does not explicitly name alternative tools or 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.