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 'thumbnails and downloads never consume quota', a behavioral trait, but does not mention read-only status, auth needs, or side effects.

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

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

Two sentences, front-loaded with the most important information, no wasted words.

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 parameters and no output schema, the description adequately explains the return values (quota, reset time, cache stats) and provides a helpful note about non-quota consumption. Slightly lacking in behavioral detail but sufficient for a simple status 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?

No parameters exist, so the baseline is 4. The description adds meaning by explaining what the tool returns, compensating for the lack of 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 states the tool returns 'Pexels quota remaining, reset time, and this session's cache stats', specifying the exact resource and purpose. It distinguishes itself from sibling tools focused on media search and retrieval.

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?

No explicit guidance on when to use this tool versus alternatives. While the purpose is obvious, there is no mention of use cases or when to avoid it.

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

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

No annotations exist, so description must disclose behavior. It mentions parallelism, deduplication, caps on queries (6) and previews (12), and media type selection. However, it does not describe error handling, result format, or side effects, leaving gaps.

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

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

Two sentences that are front-loaded with key functionality: parallelism, query limit, deduplication, and ideal use. No redundant words; every sentence adds value.

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

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

No output schema, so description should outline what is returned; it does not. The parallelism and deduplication are well explained, but missing details on error handling, result structure, and relation to sibling tools. Adequate but not fully comprehensive.

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

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

Schema coverage is only 17% (only previews has a description). The description adds meaning for queries (parallel, deduplicated) and previews (capped at 12), and mentions media type. But per_query, orientation, and preview_height are not elaborated, so compensation is partial.

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?

Description clearly states the tool runs up to 6 search queries in parallel with deduplication, and the use case for multi-scene content. Verb 'run' and resource 'search queries' are specific, distinguishing it from single-query siblings like search_photos and search_videos.

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 says 'Ideal for gathering candidates for a multi-scene piece of content', providing a clear context. Does not explicitly list when not to use or compare to alternatives, but the use case is well-defined.

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

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

With no annotations, the description provides some behavioral context: it lists media in compact format with inline thumbnails. However, it does not disclose whether the operation is read-only, how pagination works, or any other side effects. It adds value beyond a bare 'list' but leaves gaps.

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 a single, front-loaded sentence with no extraneous words. It efficiently communicates the core function and output format.

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 6 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return values, pagination, filtering (e.g., the 'type' parameter), or error conditions. A user or agent would need to infer or experiment to use the tool correctly.

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

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

Schema description coverage is only 33%, and the description adds no information about parameters. It does not explain the purpose of fields like 'page', 'per_page', 'previews', or 'preview_height'. The tool has 6 parameters, and the description offers no help in understanding them beyond what the sparse schema provides.

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 'List media inside a collection (photos and/or videos), compact format + inline thumbnails', specifying the action, resource, and output format, distinguishing it from siblings like search_photos or featured_collections.

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 lacks explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a collection ID from featured_collections) or situations where other tools would be more appropriate. The input schema mentions the ID source, but the description itself does not.

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

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

With no annotations, the description must fully disclose behavior. It only mentions 'compact format + inline thumbnails' but omits details on pagination, rate limits, data freshness, or whether it supports any filtering beyond the provided parameters.

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 sentences long, front-loads the core purpose, and contains no filler. Every sentence adds value.

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 4 parameters, no output schema, and no annotations, the description is too sparse. It lacks details on return format, pagination behavior, and how this curated feed differs from other similar tools, making it inadequate for informed use.

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 should explain parameters. It only hints at preview behavior via 'inline thumbnails' but does not clarify 'page', 'per_page', or 'preview_height' beyond what the schema already provides.

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 provides a curated feed of photos from Pexels, using 'hand-curated' and 'fresh, high quality' to specify the resource. It also distinguishes itself from the sibling 'search_photos' by referencing its format and content.

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

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

The description implies usage for browsing curated content instead of searching, with the comparison to 'search_photos'. However, it does not explicitly state when to use this tool versus other siblings like 'popular_videos' or 'featured_collections', nor does it provide exclusions.

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

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

No annotations are provided, so the description carries full burden. It discloses streaming to disk, return format (file paths, sizes, attribution lines), and non-quota usage. It does not mention overwrite behavior or error handling, but the key behavioral traits are covered.

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

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

Three sentences: one for purpose and defaults, one for behavior and return, one for quota note. No fluff, front-loaded with the key action.

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 4 parameters, no output schema, and moderate complexity, the description covers purpose, behavior, and param details reasonably well. It lacks explicit output structure but mentions return fields. Could mention maxItems limit from 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?

Schema coverage is 50%; the description adds context for photo_size (explaining resolution mapping) and directory (mentioning env var override). Items parameter is described as 'photos/videos by #id', which aligns with schema. It does not fully compensate for undocumented parameters but adds some 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?

Description clearly states the verb 'download' and resource 'photos/videos by #id', distinguishing it from sibling tools that search or retrieve metadata. It specifies the action, target (local directory), and default location.

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 notes that downloads don't consume API quota, providing a usage incentive. However, it lacks explicit guidance on when to use this tool versus alternatives like get_media (which likely returns URLs) or search tools. The context is implied but not fully explicit.

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

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

No annotations provided, so description carries full burden. It states a read-only list operation, which is simple, but omits any details about auth, rate limits, or side effects. Adequate for a straightforward listing tool.

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

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

Two sentences, front-loaded with purpose, followed by cross-reference to related tool. No wasted words.

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

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

No output schema and no description of return format. Agent may not know what data fields collections return (e.g., id, title). Missing pagination info beyond schema min/max.

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

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

Schema coverage is 0% and description does not mention parameters. Agent must deduce page and per_page from schema alone, which lacks context like default values or typical usage hints.

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?

Description clearly states it lists featured collections, a specific resource type, and distinguishes from the sibling tool collection_media. It is not a 5 because it could be more specific about what a featured collection is.

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?

Provides clear guidance to use collection_media for browsing a single collection, implying this tool is for listing. Could be improved by explicitly stating when to use this over search or curated tools.

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

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

With no annotations, the description must carry full behavioral burden. It only covers license and style options, but omits key traits: whether it is read-only, what happens on invalid IDs, rate limits, or output format details. The safe nature is implied but not confirmed.

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

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

Two concise sentences with no fluff. The core action and options are front-loaded, and every word adds value.

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 tool is simple, yet the description lacks output format details (e.g., structure of attribution lines) and error handling. It is minimally adequate but omits context like whether items must be from Pexels or how invalid items are treated.

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

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

Schema coverage is 0%, so the description must compensate. It mentions 'used media' and styles but does not clarify the items parameter structure (id/type pairs) or constraints (max/min items). The schema's enum for style is repeated but not explained.

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 verb 'Generate' and the resource 'attribution lines for used media'. It also lists the styles (plain, markdown, html) and mentions the Pexels license, distinguishing it from sibling tools like search_photos or download_media.

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

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

The description implies usage after obtaining media IDs (items), and mentions three output styles. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_media) or 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.

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 describes the return content accurately but does not explicitly state side-effects or idempotency. However, as a 'get' operation, the read-only nature is implied, and the description offers sufficient transparency for safe usage.

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

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

Two concise sentences, front-loaded with core purpose and outputs, followed by a usage guideline. 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.

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

Given the simple tool (2 required params, no output schema), the description covers what it does, when to use, and what it returns. It lacks information on error conditions or response structure, but the return description is sufficiently detailed for most use cases.

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

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

Schema coverage is 0% (no parameter descriptions in schema), so the description must compensate. It mentions 'by #id' and 'photo or video' which loosely maps to the 'id' and 'type' params, but does not formally describe each parameter's purpose, format, or constraints beyond the schema definition.

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 retrieves 'full metadata for one photo or video by #id' and lists specific outputs (source/download URLs, video files with fps/resolutions, Pexels page URL). It distinguishes itself from sibling tools by noting that search/preview are sufficient for selection.

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 ('when you need URLs or exact file variants') and when not to ('search lines + previews are enough for choosing'), providing clear decision criteria relative to sibling tools.

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

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

No annotations, so description carries burden. Mentions 'compact format' and thumbnails but omits return format details, pagination, or auth needs.

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?

Single sentence, no fluff. Could benefit from slight structuring but overall 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?

No output schema; description insufficiently explains output details despite 8 parameters. Missing pagination and response shape.

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 has 8 parameters with only 25% described. Description broadly mentions 'min-resolution/duration' but does not explain previews, preview_height, or page/per_page behavior.

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?

Clearly states it returns Pexels' current popular videos with optional constraints. The phrase 'compact format + inline poster thumbnails' differentiates from siblings like search_videos.

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?

Implies use for trending content but no explicit when-to-use or when-not-to-use. Lacks mention of alternatives like search_videos for query-based searches.

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

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

With no annotations, description adds key behavior: 'costs no API quota for already-seen ids'. However, it does not disclose return format, error handling, or authorization requirements. Some behavioral insight but incomplete.

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

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

Two sentences, front-loaded with action and context, then parameter guidance. No redundant words. Efficient and clear.

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 low complexity (2 params, no output schema, no annotations), description covers purpose, usage context, and parameter behavior. Lacks explicit return format and alternative tool comparisons, but sufficient for basic use.

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

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

Schema coverage is 0%, so description must add meaning. It implies ids are from earlier searches and height affects magnification. Provides functional context but no details on min/max, default, or types beyond schema.

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?

Description states 'Fetch inline thumbnails for specific photo #ids', specifying verb (fetch) and resource (inline thumbnails for photos by ids). It distinguishes from siblings like get_media and download_media by focusing on thumbnails and the context of earlier searches.

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?

Implies usage after search_photos with 'from earlier searches' and 'finalists'. Guides parameter use ('Use a larger height for a closer look at finalists'). Does not explicitly exclude alternative tools, but context is clear.

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

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

With no annotations, the description carries the full burden. It discloses default inline thumbnails and token cost (~75 tokens each), enabling the agent to understand behavioral expectations. However, it omits details on pagination, sorting, and potential rate limits, preventing a perfect score.

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

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

Two concise, front-loaded sentences with no wasted words. The first sentence immediately states the action and resource, and the second provides key behavioral details. Every sentence adds value.

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 9 parameters, no output schema, and no annotations, the description is incomplete. It explains output format and default previews but lacks details on pagination, error handling, or result ordering. More context would be needed for an agent to use it reliably without external knowledge.

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 56%, so the schema partially documents parameters. The description adds context for the 'previews' parameter (default behavior and token cost) and hints at output structure, but does not significantly improve understanding of other parameters like page, locale, or orientation beyond what the schema provides.

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 'Search Pexels photos' and specifies the output format (compact line with id, dimensions, photographer, etc.), making the tool's purpose unambiguous. It naturally distinguishes from siblings like search_videos by mentioning 'photos' and the unique inline thumbnail feature.

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

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

The description implies use for searching photos with visual validation, but provides no explicit guidance on when to use this tool versus alternatives like batch_search, preview_photos, or curated_photos. No when-not-to-use or exclusion criteria are given, leaving the agent to infer proper usage.

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

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

No annotations provided. Description discloses default previews and return format, but doesn't mention side effects or permissions (likely read-only). Adequate for a search tool but lacks depth.

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

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

Two concise sentences: first states core function and output, second gives actionable next-step tip. No redundancy.

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

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

With 10 parameters and no output schema, description covers basic output and hints but doesn't explain search behavior or filter usage. Adequate but not comprehensive.

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?

Only 30% schema coverage. Description mentions previews default true but doesn't elaborate on other parameters like query, locale, orientation. Limited value beyond schema.

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?

Clear verb 'Search' and resource 'Pexels videos'. Description specifies return format (compact line with id, dimensions, etc.) and distinguishes from sibling 'video_storyboard'.

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?

Suggests using video_storyboard for deeper inspection, but no explicit guidance on when to use this vs alternatives like popular_videos or curated_photos. The search context is implied.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool returns inline images, samples frames evenly, and costs no quota for already-seen videos. This provides good transparency for a read-only preview tool.

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

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

The description is very concise at two sentences. The first sentence front-loads the core purpose and output, while the second adds a key behavioral note (cost). No unnecessary words.

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 covers the key aspects: what it returns, how it samples, and a cost benefit. It is adequate for an agent to decide whether to use this tool, though it could specifiy image format or error handling.

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 covers 67% of parameters with descriptions. The description adds context about 'evenly-sampled preview frames' tying to the frames parameter, but does not explain the height parameter or provide additional details beyond the schema.

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 verb 'Return' and the resource 'poster plus evenly-sampled preview frames from inside a video'. It distinguishes itself from sibling tools like search_videos or download_media by emphasizing the validation of motion/content/framing without 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 implies when to use the tool: to validate a clip without downloading, and notes cost benefits. However, it does not explicitly state when not to use it or mention alternative tools for comparison.

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