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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only the mild ownership constraint ('the user's collections'); it says nothing about duplicate handling, the 100-image cap, partial-failure behavior, or permission requirements for a non-idempotent mutation. With annotations carrying most of the burden this is a small but real gap.

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?

It is a single front-loaded sentence with no filler, so it is not padded. However, brevity here comes at the cost of under-specification rather than efficiency, so it earns only a middling score.

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?

An output schema exists, so return values need no explanation, but this is a non-idempotent write tool with two required, entirely undocumented parameters and a batching limit. The description omits what happens to images already in the collection and whether the operation is all-or-nothing, leaving the agent under-informed for a mutation.

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 and it does not. Neither collection_id nor image_ids is explained, and the important limits encoded in the schema (image_ids minItems=1, maxItems=100) are never surfaced in prose. The names are largely self-explanatory, which keeps this above a 1.

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 ('Add images to ... collections'), which lets an agent separate it from get_collection, create_collection, and list_collections. It does not explicitly name a sibling, but the mutation-versus-read distinction is implied by 'Add'.

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?

There is no guidance on when to use this tool versus create_collection or get_collection, no mention of prerequisites (does the collection need to pre-exist?), and no exclusions. The only implied usage is that an existing collection is targeted via 'one of the user's collections'.

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?

The annotations already declare that this is a non-read-only, non-idempotent, open-world, non-destructive operation. The description adds no behavioral context such as permission requirements, duplicate-name handling, or side effects. It is not contradictory, but it provides almost no transparency 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 a single front-loaded sentence with no wasted wording. It is appropriately concise, though its terseness contributes to gaps in other dimensions rather than being a structural flaw.

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 create tool with an output schema and annotations, the description gives the minimum viable purpose statement. The structured fields cover return values and safety hints, but the description still omits usage guidance and parameter meaning that would make it complete.

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 compensate by explaining the required name parameter. It does not mention the parameter, its constraints, or what the name represents. The schema carries all parameter information without any descriptive support.

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: "Create an image collection." This is clear enough for an agent to understand the basic action. However, it does not differentiate from sibling tools such as add_to_collection, get_collection, or list_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 gives no explicit guidance about when to use this tool versus alternatives. It does not mention prerequisites, whether a collection must not already exist, or how it relates to add_to_collection or list_collections.

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, so safety and external reach are covered. The description adds only that matching is by visual appearance ('look like') rather than metadata, and says nothing about pagination behavior, result limits, or how similarity is scoped across asset types.

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?

A single front-loaded sentence with no wasted clauses. It is appropriately tight, though the brevity comes at the cost of the missing guidance noted in other dimensions.

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?

An output schema and annotations reduce the burden, but a read tool with an enum param and a direct sibling overlap (reverse_image_search) needs more than one sentence. Nothing clarifies what kind of results come back or how this differs from the other similarity/search siblings.

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 75%, with only asset_type lacking a schema description. The description adds no meaning to id, page, per_page, or asset_type beyond the schema text; 'one you already have' only loosely restates that id refers to an existing asset.

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: find images or videos visually similar to an existing Shutterstock asset. That is clearly distinct from search_images/search_videos (keyword search), but it does not distinguish itself from the sibling reverse_image_search, which appears to cover overlapping intent.

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?

Usage is only implied by the phrase 'one you already have from Shutterstock,' suggesting the tool requires an existing Shutterstock asset id. There is no explicit when-to-use/when-not guidance and no routing to alternatives such as reverse_image_search or search_images.

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, so safety is covered, but the description adds nothing beyond 'full details' — no indication of what kind of detail comes back, that results may differ by asset_type, or that the country parameter affects editorial results specifically. For an open-world read whose output varies by asset type, this leaves the agent without behavioral context the annotations cannot supply.

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?

A single efficient sentence with the action front-loaded and no filler. It is arguably too sparse for the amount of variation the tool supports, but nothing is wasted.

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 a simple single-record read, an output schema exists, and annotations cover the safety profile, so the description covers the minimum. What is missing is how asset_type interacts with the other parameters (country only for editorial) and any note about a miss/not-found outcome.

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 67%, so the schema carries most of the load, and country is well documented there. The description does add a small mapping value by spelling out the four asset kinds and rendering the 'music' enum as 'track', but it says nothing about the required id or that country applies only to editorial.

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 gives a specific verb ('Get') and resource ('full details of one image, video, track or editorial photo'), and the enumeration of asset types lets an agent distinguish this from the search_* siblings, which return many results. It stops short of naming a sibling or stating the single-asset scope explicitly against get_collection, but the intent is unambiguous.

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?

Usage is only implied: 'the full details of one' suggests this is the follow-up call after a search, but the description never says to use it after search_images/search_videos/etc., nor does it exclude any case. The needed context (id comes from a search result) lives in the schema rather than the description.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds nothing beyond them: no result ordering, no statement about behavior for an empty or unknown collection, and no indication of what a page of results looks like. With the annotation bar already met, the description contributes almost no extra 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.

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

A single front-loaded sentence with no filler. It is efficient, though its brevity is part of why other dimensions are thin.

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?

An output schema exists, so return values need not be explained, and paging is covered by the schema. Still missing for a read tool are result ordering and the behavior for an invalid or empty collection, which would make this callable without guesswork.

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 67%, with both paging parameters documented in the schema (defaults, bounds) while collection_id is bare. The description only weakly compensates by implying collection_id identifies one of the user's own collections; it gives no format or provenance detail for obtaining that id.

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 names a specific verb and resource ('List the images in one of the user's collections'), which clearly separates it from list_collections and the search_* siblings. It stops short of any explicit sibling differentiation, but the resource itself is unambiguous.

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?

There is no when-to-use or when-not-to-use guidance, no mention of how this differs from search_images or list_collections, and no stated prerequisites (for example, that a collection_id must be obtained first). Usage is only implied by the tool name and sentence.

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, so safety is covered. The description adds the useful scope hint that collections span user-owned and team-shared picks, but says nothing about result volume, pagination, or whether shared collections are included for every caller.

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?

One sentence, front-loaded with the verb and resource, with the appositive definition placed after the core claim. Nothing is wasted and nothing is buried.

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 an output schema present, return values need not be described, and annotations cover the safety profile. For a zero-param list tool this is nearly sufficient; only the scope of "the user's" collections versus team-shared ones would sharpen it further.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly spends no words on argument semantics.

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?

Uses a specific verb + resource ("List the user's image collections") and adds a gloss ("the lightboxes a team uses to share picks") that tells an agent what a collection actually is. The singular sibling get_collection is implicitly distinguished by "list" vs retrieval, but the description never names it.

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 enumerating verb plus the "team shares picks" framing implies the natural use case (discovering collections before fetching assets or adding to one), but there is no explicit when-to-use, when-not-to-use, or named alternative among get_collection, create_collection, or add_to_collection.

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, so the safety profile is covered externally. The description adds the useful ordering guarantee ('newest first') but omits pagination behavior and, critically, the default asset_type=image filter that silently narrows results.

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?

A single tight sentence that front-loads the action, then ordering, then motivation. Nothing is wasted and nothing important is buried.

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?

An output schema exists, so return values need no explanation, and the operation is simple. Still, for a tool whose default behavior is filtered to one asset type, the description should disclose the image-only default and pagination limits rather than leaving both to the 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 67%: page and per_page are documented in the schema, but asset_type has only an enum and a default of 'image' with no explanation. The description adds no parameter meaning at all, leaving the agent unaware that the default call returns only images.

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 ('List ... licensed') and adds scope details (newest first) that let an agent distinguish it from sibling listers like list_collections and list_subscriptions. It never names a sibling explicitly, so differentiation is inferred rather than stated.

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?

'to reuse it rather than license it again' gives a purpose-level hint about when this tool is the right call, which is more than nothing. However, it never says when NOT to use it, offers no alternative tools for related lookups, and doesn't mention that results are filtered by asset type.

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?

The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavioral context by saying the result shows licensable content and remaining quota, but says nothing about account scoping beyond 'the user's', auth requirements, 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.

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

A single front-loaded sentence with no filler; the colon clause adds real information rather than restating the name. Slightly compressed rather than structured, but 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 zero-parameter read tool with an output schema and readOnly/openWorld annotations, the description covers what the agent needs: what is listed and roughly what comes back. The missing piece is a routing cue against the adjacent 'list_licenses' and 'list_collections' tools.

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 takes zero parameters, so there is no parameter meaning to convey and the baseline of 4 does not strictly apply; the description's only relevant semantic contribution is framing the output, which is largely redundant with the output 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?

States a specific verb and resource ('List the user's Shutterstock subscriptions') and adds scope detail about what the listing conveys (licensable content and remaining quota). It does not explicitly distinguish itself from the similarly named sibling 'list_licenses', so it stops short of a 5.

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?

Usage is only implied by the verb and object: an agent can infer this is the read path for subscription status, but the description never says when to prefer it over 'list_licenses' or 'list_collections', nor does it state any exclusions or prerequisites.

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 covered. The description adds that the corpus is Shutterstock and the input is your own image, but omits that at least one of image_url/image_path must be provided despite zero required parameters, and says nothing about file constraints beyond the schema.

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

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

A single front-loaded sentence with the action and target stated first, followed by concrete input examples. No filler or redundant restatement of the schema.

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?

Return values are covered by an output schema and the safety profile by annotations, so the remaining burden is small. The only real omissions are the at-least-one-image-source constraint and differentiation from find_similar.

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 75% and the schema itself documents image_url, image_path and per_page limits, so the baseline applies. The one gap the description could have filled — what commercial vs editorial licensing means for results — is addressed nowhere, and the mutually exclusive nature of the two image inputs is left implicit.

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 names a concrete verb (find) and resource (Shutterstock images) and clarifies the query mode is 'images that look like one of your own', which separates it from keyword search. It stops short of naming the closest sibling, find_similar, which is the main ambiguity risk.

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 examples (sketch, mood board, a photo to replace) imply when this is useful, so the use case is inferable. There is no explicit guidance on when to prefer this over search_images or find_similar, and no stated prerequisite about supplying exactly one image source.

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, so the safety profile is covered. The description adds some context by signalling that results are editorial-licensed material intended for news/commentary, but says nothing about the licensing/usage constraints that make editorial content different, nor about result volume or pagination behavior.

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?

A single front-loaded sentence with no padding; the subject list is informative rather than wasteful. The trailing 'for news and commentary' is slightly redundant with 'editorial' but does reinforce the use context.

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 an output schema present and 86% parameter coverage, return-value and argument details are adequately handled elsewhere. However, for a 7-parameter search tool with multiple search siblings, the description is too thin on differentiation and on the editorial-rights implications that determine whether results are usable.

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 86%, including a NOT-operator hint on query, country-code pattern with the note that editorial rights vary by country, and date/per_page bounds — so the schema does the heavy lifting. The description adds no parameter meaning whatsoever, leaving it at the baseline for high coverage.

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?

States a specific verb ('Search') and a specific resource ('editorial photos'), with a subject-matter scope of news, sport, entertainment and events. The word 'editorial' plus the 'news and commentary' framing implicitly separates it from the generic search_images / search_videos siblings, though it never names an alternative outright.

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?

'For news and commentary' implies the intended use case — editorial rather than commercial/creative imagery — which is a meaningful selection cue against search_images. It stops short of explicit when-to-use/when-not guidance, prerequisites, or naming the sibling to prefer for non-editorial needs.

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, so safety and external-reach are covered. The description adds nothing further: it does not mention that results are licensed stock assets, that licensing is a separate step (list_licenses/get_asset), the per-page cap, or the default safe-search behavior.

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?

One front-loaded sentence with zero waste, but it is undersized for an 11-parameter search tool with licensing and pagination semantics. Concise is good; this is terse to the point of under-specification.

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 11 parameters, an output schema, and open-world read behavior, the description should explain filtering strategy and result handling. It leaves commercial-vs-editorial licensing, pagination limits, and all enum filters to an incomplete 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 description coverage is only 45% across 11 parameters, so the description carries a real burden and meets none of it. Six enum/filter parameters (sort, license, image_type, orientation, people_age, safe) have no description anywhere, and the description never explains their effect or interaction.

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?

States a specific verb (Search) and resource (Shutterstock photos, illustrations and vectors), and the media list implicitly separates it from siblings like search_videos and search_music. It stops short of explicitly naming the closest alternative, search_editorial, whose results also contain images.

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 gives no when-to-use guidance, no exclusions, and no routing to search_editorial, find_similar, or reverse_image_search. An agent must infer the choice purely from sibling names.

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, so safety and external-catalog reach are covered. The description adds only the catalog scope ('production music'), and says nothing about pagination limits, default sort ordering, licensing/watermark implications, or result cardinality beyond what the output schema and annotations already imply.

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?

A single front-loaded sentence with no filler or redundancy. It is efficient, though for a 13-parameter tool the extreme brevity leaves no room for the operational notes an agent actually needs.

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 13 optional parameters, an output schema, and non-obvious defaults (per_page defaults to 20 with a hard cap of 50, sort defaults to 'score'), the description omits everything an agent needs for correct invocation strategy. It never mentions pagination behavior or that results likely require further calls to preview or license.

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 69%, so the schema documents most parameters. The description adds modest conceptual mapping by naming 'tempo' and 'length', which helps translate user language to bpm_from/bpm_to and duration_from/duration_to, but it says nothing about query, sort, page, per_page, vocals, or instrumental.

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?

States a specific verb ('Search') and a specific resource ('Shutterstock's production music'), plus the facets it filters on. The asset type alone distinguishes it cleanly from siblings search_images, search_videos, and search_editorial.

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?

Usage is implied by the resource name: an agent can infer this is the tool for finding music tracks. However, there is no explicit guidance on when to prefer it over find_similar or how to move from a search result to licensing (get_asset, list_licenses), and no note that all filters are optional.

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, so the safety profile is covered. The description adds nothing beyond that: no mention of pagination limits, that per_page caps at 50, how results are ordered by default, or what a result set contains. For an 11-parameter search tool it contributes almost no 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.

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

The single sentence is front-loaded and contains no filler, so it is structurally fine. The problem is under-specification rather than verbosity: it is concise at the cost of almost all useful detail.

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?

An output schema exists so return values needn't be explained, but with 11 parameters, 45% schema coverage, and numerous undocumented filters, the definition is not complete enough to guide correct invocation. At minimum it should clarify default sort behavior, licensing filters, and pagination limits.

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 45%, with safe, sort, license, resolution, orientation, and aspect_ratio undocumented in the schema. The description does not compensate for any of these gaps, leaving enum-bearing filters like resolution and aspect_ratio to be interpreted from their names alone.

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?

States a specific verb (Search) and resource (Shutterstock video footage), which is enough to distinguish it from siblings like search_images and search_music. It stops short of saying anything about scope or result characteristics, but the tool's identity is unambiguous.

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?

There is no when-to-use guidance, no mention of alternatives such as search_images, search_editorial, or find_similar, and no stated prerequisites. The agent must infer selection criteria entirely from the tool name and sibling list.

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, so safety is covered. The description adds one genuinely useful behavioral fact — the returned image is a watermarked preview, not the licensed asset — but says nothing about resolution, rate limits, or whether previews are logged/attributed.

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?

A single front-loaded sentence with no filler; the purpose clause follows the action. Slightly informal wording ('Look at') but nothing is wasted.

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 read-only tool with no output schema, the description covers the core intent, but it leaves the asset_type/country interaction and the nature of the returned preview under-explained, which matters for an editorial-vs-image distinction.

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 description mentions no parameters. With 67% schema coverage the baseline is middling, and the enum parameter asset_type has no description at all in the schema, so the agent gets no help understanding when to pass 'editorial' versus 'image' or that country only matters for editorial.

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?

States a specific verb and resource: view a watermarked preview of an image. The qualifier 'watermarked preview' implicitly separates it from get_asset (full asset) and find_similar, but no sibling is named, so an agent must infer the distinction.

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 clause 'to judge whether it fits' implies the evaluation/decision use case, but there is no explicit when-to-use versus get_asset or search_images, and no statement about what to do after judging (e.g., license or fetch the full asset).

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