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

The annotations already indicate read-only and non-destructive behavior. The description adds that it downloads and analyzes images, uses caching for cost-efficiency, and extracts specific content types. It doesn't contradict annotations and offers useful operational context beyond the structured metadata.

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 and front-loaded with the 'REQUIRED' label and core purpose. It lists valuable details (caching, what to extract) without repetition. The structure is efficient and each sentence adds information.

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

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

For a simple image-analysis tool, the description covers the main functionality, usage context, and caching behavior. It does not describe return format, but the list of extracted elements gives a strong hint. Combined with annotations and sibling context, it's reasonably complete, though a brief note on output or error handling would improve it.

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

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

The schema has no descriptions (0% coverage), and the tool description only indirectly refers to media_url as the image URL. It does not explain the purpose or effect of ad_id or brand_name parameters. Since the description fails to compensate for the missing schema information, the agent gets little additional meaning for these parameters.

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

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

The description clearly identifies the tool's function: downloading and analyzing ad images from TikTok ads. It lists specific extractable elements (visual, text, colors, people, brand, composition) and distinguishes from sibling tools by focusing on images rather than videos. It leaves no ambiguity about the resource and action.

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 'REQUIRED for analyzing images from TikTok ads' and instructs to use it for every image URL from search_tiktok_ads. It provides strong when-to-use guidance, though it doesn't explicitly mention alternatives or when-not-to-use. The context is clear and compelling.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial behavioral context: it downloads and processes videos via Gemini, extracts specific narrative elements, notes that TikTok CDN URLs expire quickly, and explains the caching strategy for stability. This goes well beyond the annotations and gives the agent a clear model of what happens during invocation.

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

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

Three compact sentences, front-loaded with 'REQUIRED', efficiently convey purpose, extraction details, parameter guidance, and caching. 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.

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 covers the core functionality, critical parameter usage, processing details, and caching behavior. The only notable gap is the roles of media_url and brand_name, which leaves some cross-parameter scenarios ambiguous. Overall, it is reasonably complete for an agent to invoke successfully.

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

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

The schema has 0% description coverage, and the description compensates for only one of three parameters: ad_id is thoroughly explained with its signed-URL rationale. However, media_url and brand_name are left undefined, and the relationship between ad_id and media_url is not clarified. This partial coverage earns a mid-range score.

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 analyzes TikTok video ads, with a specific verb ('analyzing') and resource ('video ads from TikTok'). It enumerates the specific aspects extracted (hook, scene-by-scene storytelling, on-screen text, audio/voiceover, pacing, brand messaging), 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 opening 'REQUIRED for analyzing video ads from TikTok' frames when to use the tool. It also gives a critical usage instruction ('ALWAYS pass ad_id') with a clear rationale. However, it does not explicitly mention when not to use it or name alternatives, though the scope restriction to video ads and the presence of analyze_ad_image imply the boundary.

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

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

Annotations already indicate readOnlyHint=false (a mutating operation), and the description confirms by mentioning 'cleaning up' and 'freeing disk space.' However, it doesn't disclose that files are permanently deleted, potential irreversibility, or any side effects beyond space freeing. The description adds some context but could be richer.

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 but contains redundancy: 'freeing disk space,' 'clean up storage space,' and 'storage management' all express the same idea. The leading 'REQUIRED' is unnecessary and adds noise. It is front-loaded but could be more concise.

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

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

Given no output schema, the description should hint at what the tool returns (e.g., number of files deleted, space freed). It also doesn't mention irreversibility or any confirmation flow. For a destructive tool with annotations indicating mutation, this is a notable gap, but the core purpose and trigger conditions are covered.

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 mention the only parameter 'max_age_days' at all. The parameter name is somewhat self-explanatory, but the description fails to clarify its role (e.g., cutoff age for deletion), leaving the agent without additional guidance beyond the schema's default value.

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 a specific action ('cleaning up old cached media files') and resource ('images and videos'), distinguishing it from sibling tools like get_cache_stats or search_cached_media. The verb 'cleanup' is unambiguous and tied to a concrete outcome (freeing disk space).

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

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

Explicitly states when to use the tool: 'when users want to remove old cached media, clean up storage space, or when cache becomes too large.' It doesn't explicitly mention when not to use it, but the context and sibling tools make that implicit, which is sufficient.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is clear. The description adds useful behavioral context about what statistics are provided (storage usage, file counts) and positions it as essential for monitoring. It does not introduce any side effects or contradictions.

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

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

The description is front-loaded with the essential purpose ('REQUIRED for checking media cache status') and followed by usage cues. It is efficient overall, but the final sentence 'Essential for cache management and monitoring' adds little beyond the earlier text, 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?

Given the tool's simplicity (no params, read-only, no output schema), the description covers the core purpose and user intents. It does not describe return format or how it relates to cleanup decisions, but these are not critical given the annotations and simplicity. The description is sufficient for accurate selection and invocation.

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

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

The tool has zero parameters, so the schema is inherently 100% covered. No parameter explanation is needed, and the description appropriately omits any. This aligns with the baseline of 4 for zero-parameter tools.

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 function: checking media cache status and storage usage. It lists specific outputs (storage space used by cached media, number of files analyzed/cached) and distinguishes it from siblings 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?

The description explicitly states when to use: 'when users ask about cache statistics, storage space used by cached media, or how many files have been analyzed and cached.' It provides strong contextual guidance, though it does not explicitly mention when not to use it or name alternative tools for related tasks.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is clear. The description adds behavioral context by promising a 'fresh playable video URL' and detailing what information the response contains (creative, landing page, country targeting, engagement metrics). No contradictions found.

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

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

The description is two concise sentences: the first states the function and the returned data categories, the second provides usage context. There is no redundant wording or unnecessary detail, making it highly efficient.

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

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

For a simple one-parameter read-only lookup, the description adequately sets expectations by listing the output content categories and linking to the appropriate sibling search tool. No output schema exists, but the enumerated detail fields are sufficient for an agent to understand what the tool provides.

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

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

The input schema has zero description coverage for the single parameter ad_id, so the description must compensate. It does so by explaining the provenance ('from search_tiktok_ads') and the purpose (identifying a specific TikTok ad), which gives the agent enough context to provide a valid value.

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

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

The description uses a specific verb ('Get detailed information') and identifies the exact resource ('a specific TikTok ad'), while enumerating concrete data categories (full creative, landing page, country targeting, engagement metrics, playable video URL). It clearly distinguishes itself from the sibling search_tiktok_ads by specifying that it operates on an ad_id rather than performing a 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 this tool: 'Use this with an ad_id from search_tiktok_ads' and calls it 'Essential for analyzing ad content and extracting media URLs for visual analysis.' It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to select it appropriately.

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 and openWorldHint, and the description adds useful context like 'previously analyzed' and 'without re-downloading media.' However, it does not disclose details about return formatting, ordering, or behavior when no results are found. The added context is helpful but not extensive.

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, front-loaded with 'REQUIRED,' and uses three short sentences that each add value. It captures the purpose, use cases, and benefit without extraneous information.

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

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

Given the five optional parameters and no output schema, the description covers the main search dimensions and conveys the tool's purpose and typical use cases. It doesn't explain the return structure, but it implies the retrieval of prior analysis results, which is sufficient for an annotated read-only search 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. It names the searchable filters (brand_name, has_people, color_contains, media_type) and maps them to user intents, adding meaning beyond the raw schema. However, it does not explain value formats or the meaning of the limit parameter, leaving some gaps.

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

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

The description clearly states the tool finds 'previously analyzed ad media (images and videos) in cache' with a specific verb and resource. It distinguishes itself from siblings by emphasizing 'cached media' and the search use cases (brand name, people, colors, media type).

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

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

The description provides explicit when-to-use guidance: 'REQUIRED for finding previously analyzed ad media' and lists specific user intents (search by brand, find media with people, search by colors, filter by media type). It lacks explicit when-not-to-use or alternative tool references, but the context 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds useful behavioral context beyond those annotations: exact case-sensitive matching, the public nature of the Ad Library, and that spend/impressions are returned as bands, not exact figures. 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 three sentences, each earning its place: purpose, usage modes with an example, and return values plus required companion tools. It is front-loaded and contains no filler.

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

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

Given no output schema, the description explicitly lists return fields (ad ids, run dates, spend/impression bands, media URLs) and directs to analyze tools for visual analysis. It could mention pagination behavior via cursor/limit, but the description is otherwise complete for a search tool with good annotations.

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

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

The schema has 0% description coverage, so the description must compensate. It provides critical semantics for the primary parameter 'query', explaining it can be an exact advertiser name or a keyword, and highlights case sensitivity. However, it doesn't explain 'limit' or 'cursor', but these are standard pagination parameters and the query guidance is the key missing piece.

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

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

The description states a specific verb and resource: 'Search TikTok's public Ad Library for the ads an advertiser is running.' It also lists the return fields (ad ids, run dates, spend/impression bands, media URLs), distinguishing it from siblings like analyze_ad_video and 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?

Explicitly instructs to use the exact registered advertiser name (case-sensitive) or a keyword, and names appropriate alternatives: 'For complete analysis ... you MUST also use analyze_ad_video (passing ad_id) or analyze_ad_image.' This gives clear context for when to use this tool versus others, though it doesn't 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.