footage.cool: 4K Drone & Aerial Stock Footage

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

The description adds meaningful behavioral context beyond annotations: it accepts on the buyer's behalf, emails the accepted text, and routes free evaluation orders to manual review while paid orders proceed to checkout. These side effects and downstream consequences are exactly what an agent needs before invoking a non-read-only legal acceptance 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 definition is three tight sentences: purpose first, then a consent precondition, then downstream outcomes. Every sentence adds necessary information with no repetition or waste.

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 mutation tool with no output schema, the description covers the operation, consent requirements, side effects, and post-acceptance routing. Combined with complete schema descriptions and annotations, an agent has enough context to invoke it 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 100%, so all five parameters are already documented in detail. The description reinforces the consent precondition but does not add parameter-level meaning beyond what the schema provides, making the baseline of 3 appropriate.

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

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

The description states a specific verb and resource: accepting the Dataset License Agreement for a quoted order on the buyer's behalf. This clearly distinguishes the tool from siblings like get_dataset_agreement and quote_training_dataset, which retrieve or quote rather than accept.

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

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

It gives an explicit precondition: call ONLY after the buyer has seen the tier, clip count, price, payment method, key terms, and full agreement text, and has explicitly agreed. This is strong usage guidance, though it does not name alternate tools or explicitly route to get_dataset_agreement as a prerequisite.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond this: it does not render video or license anything, and it returns an edit decision list with preview URLs. This helps the agent set expectations about side effects and output without contradicting the annotations.

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

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

The description is three sentences with no fluff: the first front-loads the core planning action, the second describes the output, and the third lists exclusions. Every sentence earns its place, and key differentiators are prominently stated.

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 8 parameters and no output schema, the description provides solid context: it explains the high-level purpose, the nature of the return value (EDL with preview URLs), and what the tool does not do. It misses some detail about how ordering or cost totals are computed, but the core information needed to invoke it correctly is present.

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 already describes all 8 parameters with 100% coverage, including pace ranges, query examples, and defaults. The description's references to 'description', 'chosen pace', and 'shoots and locations' map to existing parameters but add no new semantic detail. Baseline 3 is appropriate given the schema handles parameter documentation.

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

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

The description clearly states the tool's function: 'Plan a timed edit from a description' and details what it does (picks/orders clips, sets cut lengths, totals license cost, returns an EDL with preview URLs). It also explicitly differentiates from render/license tools by stating what it does not do, which helps distinguish it from siblings like license_clip and render-related tools.

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 clear context for when to use the tool: when you have a text description and need a timed rough-cut plan. It also offers exclusions ('does not render video or license anything') that tell the agent situations where this tool is not appropriate. However, it does not explicitly name alternative tools, so it stops short of a 5.

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, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context by stating it reports chain of title, people/property flags, and release policy, and explicitly disclaims legal advice. It doesn't describe any side effects, but for a read-only tool this is sufficient.

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 concise sentences: purpose and tiers first, output details second, disclaimer third. No redundant phrasing or filler. Every sentence earns its place, and key information is front-loaded.

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

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

With no output schema, the description adequately describes what the tool returns (chain of title, flags, release policy). It also clarifies its non-authoritative nature. For a read-only check tool with fully documented parameters, this is complete enough for an agent to invoke 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 100%, so the baseline is 3. The description repeats the list of intended uses from the schema but adds no new meaning beyond that. The schema already explains the default and the AI data license note, so the description doesn't materially enhance parameter understanding.

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 specifies a clear verb ('Screen') and resource ('a clip'), and states exactly what it does: checks license coverage and which tier fits. It also distinguishes itself from siblings like license_clip (which actually licenses) by focusing on the screening aspect. The listed use tiers and output (chain of title, flags, release policy) make its purpose unmistakable.

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 clear context for when to use this tool: to screen license coverage before an intended use. It does not explicitly name alternatives or exclusion conditions, but the phrasing 'Catalog screening, not legal advice' implies a pre-license check use case. Given the sibling list, an agent can infer this is the read-only precursor to license_clip, though explicit when-not guidance is absent.

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 idempotentHint=true, and the description reinforces this by stating 'Calling again with the same quote returns the same checkout.' The description adds valuable behavioral context beyond annotations: it discloses that the tool returns a checkout URL and a private order token, that the user pays on Stripe, and that card details must never be collected. It doesn't contradict 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 compact and front-loaded with the core action and precondition. Every sentence earns its place: the precondition, the return values, the security note, the idempotency behavior, and the non-proof-of-purchase warning. No filler or 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?

For a 2-parameter tool with 100% schema coverage and no output schema, the description is complete. It covers when to call, what it returns, security constraints, idempotency, and a caveat about purchase proof. An agent has everything needed to invoke it correctly and to explain the outcome to the user.

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 100%, so the schema already documents both parameters. The description adds meaning by explaining the purpose of quote_token ('Private quote_token returned by quote_4k_license') and the exact meaning of confirmed ('Set true only after the user explicitly approves...'). This goes beyond the schema's field descriptions and helps the agent understand the semantic contract.

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 ('Create or resume'), a specific resource ('Stripe hosted checkout for a quote'), and clearly distinguishes this from siblings like quote_4k_license and get_4k_order. It also names the exact precondition (user approval of clip, resolution, license, price, terms), which makes the tool's purpose unmistakable.

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

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

The description explicitly says 'Call ONLY after the user explicitly approves...' and lists the exact conditions that must be met before invocation. It also tells the agent what not to do ('never collect card details in chat') and clarifies that creating checkout is not proof of purchase, which prevents misuse.

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 non-read-only, idempotent, non-destructive, and open-world. The description adds real value beyond them: the payment is external (browser redirect or emailed invoice), retries return the same artifact, card details must never be collected in chat, and payment is not delivery because each paid order is manually reviewed. Only the idempotency restatement overlaps with structured data.

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?

Five short sentences, front-loaded with purpose and routing, then safety constraints and the manual-review caveat. Every sentence carries operational information an agent needs; nothing is repeated needlessly.

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 one-parameter tool with no output schema, the description covers what is produced (hosted checkout URL versus emailed invoice), retry behavior, the no-card-details rule, and the post-payment manual review. An agent can call this correctly and set buyer expectations without further information.

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?

There is a single required parameter with 100% schema description coverage, so the schema fully documents order_token and its privacy constraints. The description only implies the token via 'accepted dataset order' and adds no format or provenance detail, which is an appropriate baseline given the schema does the heavy lifting.

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?

Opening sentence gives a specific verb and resource: the payment step for an accepted dataset order, producing either a Stripe checkout URL or a bank-wire invoice. It is clearly differentiated from siblings like create_4k_checkout and quote_training_dataset by tying it to dataset orders at the payment stage.

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?

States the precondition (an accepted dataset order) and the routing rule: proxy orders under $10,000 go to Stripe checkout, while 4K, research, and larger orders get an invoice. It does not explicitly name the sibling tool to use instead for 4K licensing, so a small inference remains, but the when-to-use 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description goes further by disclosing the actual content returned: eligible catalog counts, years, countries, categories, three pricing tiers with fixed prices, payment rails, review policy, filters, agreement version and hash, and the exact call sequence. With no output schema, this enumeration is the only place an agent can learn what the tool produces.

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 core purpose and then packs the full scope into a single dense sentence. Every listed element earns its place, though the long comma-separated enumeration is slightly harder to scan than a structured list. It is appropriately sized for an orientation tool with no parameters or output 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?

Given that there are no parameters, no output schema, and annotations already cover safety traits, the description must carry the full burden of explaining what the tool provides. It does so comprehensively: catalog eligibility, pricing tiers, payment rails, review policy, filters, agreement version/hash, and call sequence. An agent can decide to start here and know what to expect without opening any other reference.

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 the baseline is 4 and there is no parameter syntax to explain. The description correctly avoids discussing irrelevant inputs and focuses on the information the tool supplies.

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 resource, the AI/ML training dataset licensing program, and enumerates exactly what the tool returns: eligible catalog counts, tiers, prices, payment rails, review policy, filters, agreement version/hash, and call sequence. It distinguishes itself from sibling tools by instructing the agent to 'Start here for any training-data request,' and it explicitly rules out per-clip production licenses from covering training.

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

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

It gives clear routing guidance with 'Start here for any training-data request' and warns that per-clip production licenses never cover training, which tells the agent when not to use those sibling tools. It stops short of naming the specific downstream siblings such as quote_training_dataset or scope_training_dataset, though the 'exact call sequence' framing implies that this tool leads into them.

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, idempotentHint=true, and destructiveHint=false, so the agent knows it's a safe, non-mutating read. The description adds value by disclosing that results are 'spread across different shoots so the results are not near-duplicates,' which is a behavioral guarantee beyond the annotations. It also lists the specific similarity dimensions. However, it doesn't mention any rate limits, authentication, or edge cases, so it's not exhaustive, but with the annotations covering safety, a 4 is appropriate.

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 one tightly-worded sentence that packs the core purpose and criteria, followed by a short clause on use cases. No filler or redundant information. It is front-loaded with the main action, making it easy to parse quickly. Every word earns its place.

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 list-returning tool with no output schema, the description covers the essential aspects: what it does, how similarity is determined, and that it avoids near-duplicates. It doesn't specify the return format (e.g., whether it returns clip IDs or full metadata), but the tool name and context imply a list of clips. Combined with annotations that establish safety, this is adequately complete for an agent to invoke correctly, though a note on the result structure would push it to a 5.

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 100%: limit is described as 'Number of results, 1 to 24 (default 8)' and clip_id as 'Clip to find similar footage for (clip_id from search_footage).' The tool description adds no extra meaning beyond the schema—it doesn't elaborate on parameter behavior or formats. Since the schema already documents both parameters thoroughly, the baseline of 3 is correct; the description does not need to compensate.

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 'find' and the resource 'clips similar to a given clip', then specifies the similarity criteria (shared subjects, scene, location, shot year) and the deduplication behavior. It differentiates itself from search_footage (which searches by explicit criteria) and get_clip_details (which returns a single clip) by focusing on similarity to an existing clip. This gives a precise and unambiguous purpose.

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 includes explicit use cases: 'offer alternatives or to keep a sequence consistent.' It implies the tool is appropriate when you have an existing clip and want related footage, but it does not explicitly state when NOT to use it or name alternative tools. The context is clear enough for an agent to select it appropriately among siblings like search_footage, though a direct comparison would have made it 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?

Annotations only mark the tool idempotent and non-destructive; the description adds meaningful behavior: Stripe verification, a 10-second polling minimum, the purchase_completed gate, and privacy requirements for tokens and links. No contradiction with annotations exists.

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 five compact sentences with no filler. The core action and outputs appear first, followed by prerequisite and operational constraints, so an agent can quickly extract the essential 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 one-parameter tool with no output schema, this description is fully self-contained: it explains the prerequisite, verification behavior, returned items, completion condition, polling interval, and privacy obligations. Nothing critical is missing for correct 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 schema fully documents order_token, so the baseline is 3. The description adds value by confirming the token comes from create_4k_checkout and by extending privacy requirements to the returned links, which goes 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 states the exact job: checking an order after checkout, verifying Stripe payment, and returning the license, receipt, certificate link, and download link. This clearly separates it from checkout creation via create_4k_checkout and from other licensing tools like license_clip.

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 scopes usage to post-checkout order checks and requires the private token from create_4k_checkout. It also gives clear operational guidance about polling rate and when to report completion, though it does not explicitly name tools to use instead.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds functional context by specifying the kind of data returned (counts by various dimensions and pricing) and its role in discovering valid category values. This enriches the agent's understanding beyond the annotations without contradicting them.

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 exactly two sentences, front-loaded with the core content (what the overview includes) and then the usage guidance. Every word earns its place; there is no redundancy or filler. The structure makes it easy for an agent to quickly parse both the tool's function and its recommended use.

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

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

For a zero-parameter, read-only overview tool with no output schema, the description is complete. It tells the agent what data to expect (counts by categories and pricing), how to use it (to discover valid category values), and connects it to related tools. Nothing an agent needs to call it correctly is missing.

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 baseline score is 4 per the rubric. The description correctly notes that it is an overview tool with no inputs; it does not need to explain parameter semantics. The description's mention of what it returns is sufficient for a no-input tool.

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 explicitly states the resource and scope: 'Overview of what footage.cool's library covers: clip counts by shot year, scene category, subject, and location (grouped by region), people versus no-people counts, and pricing.' It also differentiates from siblings by positioning itself as a discovery tool for valid category values used by search_footage and build_rough_cut. This makes the tool's role unmistakable.

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 usage direction: 'Use it to see what exists and to find valid category values for search_footage and build_rough_cut.' This tells the agent exactly when to call this tool and ties it to specific sibling tools, leaving no ambiguity about its purpose relative to alternatives.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: it lists the returned fields, warns that the master's resolution and codec are provided 'when known', and notes the preview is watermarked. This helps the agent set expectations without contradicting 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 dense sentence that front-loads the purpose and then lists the return fields. Every word adds information, and there's no fluff. It is longer than strictly necessary but appropriately detailed for a tool with no output 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?

With no output schema, the description carries the burden of explaining what the tool returns, and it does so comprehensively by enumerating all field categories. It doesn't mention error behavior or response structure, but for a simple single-parameter getter with read-only annotations, this is sufficient.

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 100%, with the clip_id parameter already documented as accepting search_footage IDs, filename-style IDs, or URLs. The tool description does not add parameter-specific meaning beyond that, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Get full details for one footage.cool clip' and then enumerates the exact fields returned (description, tags, location, licensing, etc.). This clearly distinguishes it from siblings like search_footage (search vs. single-clip detail) and check_clip_rights (rights-only vs. full details), even without naming them.

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

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

The description implies when to use the tool—when you need comprehensive metadata for a single known clip—but it does not explicitly state alternatives or when not to use it. For example, it doesn't say to use check_clip_rights when only rights are needed. The usage context is inferred from the verb and scope, not stated.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds real workflow context beyond that: the hash serves as proof-of-presentation for the acceptance step. It doesn't mention auth or rate limits, but for a read-only fetch that is a minor 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?

Two sentences, front-loaded with what is returned, then the usage rationale. Every clause earns its place; nothing is repeated from the title or annotations.

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

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

There is no output schema, but the description enumerates the return payload (full text, version, hash, key_terms summary) and the URL alternative, plus the coupling to accept_dataset_agreement. An agent has everything needed to call it and use the result 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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies no inputs are needed and focuses on return contents instead.

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 ('full Dataset License Agreement text') and enumerates the returned components: version, SHA-256 hash, and key_terms summary. An agent can distinguish this from get_dataset_order or accept_dataset_agreement without opening a schema.

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 show the buyer the key terms and full text (or URL) before acceptance, and explains the downstream linkage: accept_dataset_agreement requires the hash back, which proves the current version was presented. This names the alternative and the condition that selects 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?

Annotations already mark it read-only, idempotent and non-destructive; the description adds genuinely new behavior: a rate/polling constraint and a confidentiality requirement for the token and download links. What it doesn't cover is failure behavior, e.g. what an invalid or expired token yields.

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 compact sentences: first what you get, then the two operating constraints. Every clause earns its place and the highest-value information (the returned fields) is front-loaded.

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

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

There is no output schema, and the description compensates by listing the status components an agent will receive. The remaining gap is the absence of lifecycle/state vocabulary or error semantics, but nothing essential for correct invocation is missing.

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

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

With one parameter at 100% schema description coverage, the schema already explains the order_token and its privacy handling. The description's note about keeping the token and links private reinforces the schema but adds no new syntax, format or source detail, so baseline 3 applies.

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

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

The description opens with a specific verb-and-resource pair ("Status of a dataset order") and enumerates the concrete fields returned: payment, agreement, manual review decision and download manifest URL. That lets an agent distinguish it from get_4k_order and get_dataset_agreement, though the sibling names are never used explicitly.

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

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

It gives a real operational rule: poll no faster than every 10 minutes while waiting for review, which tells the agent both when and how often to call. It does not, however, name an alternative for agreement-only lookups (get_dataset_agreement) or state what to do once the order is delivered.

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?

Beyond the readOnlyHint annotation, the description discloses that no charge occurs, no license is issued, and the Exclusive option requires email quoting. These are behavioral traits (side-effect-free and transactional boundaries) that are valuable for an agent.

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 compact sentences front-load the primary purpose and pricing, then clarify limitations and alternative. No wasted words; every clause adds decision-relevant 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 single-parameter, read-only tool with no output schema, the description covers purpose, price ranges, behavioral guarantees, and alternative tool. Nothing an agent needs to invoke it correctly is missing.

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 already documents clip_id with 100% coverage, including accepted formats and sources. The description adds no additional parameter-level details, matching the baseline of 3 for full schema 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 action (get), resource (licensing options and prices for a clip), and explicitly disambiguates from quote_4k_license by noting that tool starts a purchase. Lists concrete licensing tiers and prices, leaving no ambiguity about what is retrieved.

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 not to use this tool ('This tool never issues a license or takes payment') and points to the alternative quote_4k_license for purchases. This provides clear routing guidance for an agent deciding between 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?

Beyond the sparse annotations, it discloses storage verification, resolution/codec reporting, token expiration, non-charging behavior, AI-training exclusion, and the resolution_notice obligation. These are concrete behavioral facts an agent 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?

Every sentence carries operational information, and the purpose is front-loaded. The length is justified by the absence of an output schema and the need to communicate the quote flow and constraints.

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

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

With no output schema, the description must explain return/behavior, and it does: quote token, resolution/codec, resolution_notice, no charge, and required user-facing steps. It is complete for an agent to invoke and follow up 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 coverage is 100%, so the baseline is 3. The description mostly restates schema prompts (ask for email, let user choose license type) and adds workflow rather than new meaning for usage_scope, expected_distribution, or clip_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 first sentence names a specific action ('Quote a license') and resource ('a clip's clean, unwatermarked master'), and the later 'Does not charge anything' plus 'valid for 30 minutes' clearly distinguish it from checkout tools like create_4k_checkout.

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 clear workflow context: ask for buyer email and license type first, pass on resolution_notice, and show the quote/terms before checkout. It does not explicitly name sibling alternatives or state when not to use this tool, stopping short of a 5.

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?

Beyond the annotations it discloses the substantive behavior: a clip selection is frozen and made unique to this order (consistent with idempotentHint=false), the buyer's email domain is screened with consumer mailboxes refused, no charge is made, and the return payload includes a private order_token and agreement hash. It also flags the private nature of the token, which is meaningful safety context an agent would otherwise not know.

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?

Front-loaded with the purpose in the first sentence, then side effects, then user-facing constraints. Every sentence carries signal, though 'never invent them' duplicates schema wording and could be trimmed.

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 non-idempotent mutation with no output schema, the description covers what is created (quote + agreement hash + private token), cost (nothing), the email-domain gate, and the required human confirmation step. It omits quote expiry/validity windows and any failure modes beyond domain rejection, which would make it airtight.

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 100%, so the baseline is 3. The description reinforces customer_email (work domain, consumer mailboxes refused) and customer_org/intended_use, but that largely restates schema text ('Ask the user; never invent one'), and it says nothing about the tier enum semantics or the media_resolution constraint (4k commercial-only), which the schema already covers.

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 ('Create a fixed-price quote for a dataset order') and immediately enumerates the concrete actions it performs: freezing a clip selection, pricing, email-domain screening, and returning an order_token plus agreement hash. The dataset-order resource clearly separates it from quote_4k_license and the checkout siblings without needing to name them.

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

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

Gives clear in-workflow guidance ('Ask the user for the buyer's work email... never invent them') and an explicit sequencing rule ('Show the quote and the agreement to the user before accepting'), which implicitly points to accept_dataset_agreement as the next step. It does not explicitly state when to prefer this over quote_4k_license or when to first call scope_training_dataset/describe_training_dataset, so it stops short of full alternatives coverage.

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 establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds useful behavioral context beyond that: it is free, requires no email, reserves nothing, and returns an estimated price, which directly reassures an agent about cost and 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 short sentences with no wasted text. The core action is front-loaded, followed by the key cost/side-effect context and usage guidance.

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

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

With no output schema, the description usefully states what the tool returns: clip count, hours, and estimated price. Combined with fully documented parameters and annotations covering safety, the definition gives an agent everything needed to decide whether and how to call 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?

Schema description coverage is 100%, so the schema already documents the tier, media resolution, and every filter field in detail. The description only refers generally to 'a set of filters' and 'the tier and media,' adding no parameter semantics beyond what the schema provides, which matches the baseline 3.

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 action and resource: counting clips and hours matched by filters and returning an estimated price for the tier and media. It positions itself as a pre-quote sizing tool, which distinguishes it from the quoting/checkout siblings, though it does not explicitly name `quote_training_dataset` or any other alternative.

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

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

It explicitly says to use the tool 'to size a request before quoting,' giving a clear usage context. It does not spell out when not to use it or name the quoting sibling directly, so it falls short of full when/when-not/alternatives guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds meaningful behavioral detail: what results contain (metadata, verified resolution, preview URLs, links, prices) and the guarantee that footage is real, not AI-generated.

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, each with a distinct job: defining the collection scope, describing query understanding, and listing return contents. The information is dense but compact, with no filler, and the most critical purpose statement is front-loaded.

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 read-only search tool with no output schema, the description adequately covers what is searched, how queries behave, and what is returned, including previews and prices. The schema supplies parameter defaults and constraints, and annotations cover side effects, so nothing critical is missing.

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 100% across all 11 parameters, including rich query examples and the note that places and years become filters. The description adds one useful query-behavior detail (synonyms and typos) but does not need to explain each parameter because the schema handles it. Baseline 3 is appropriate.

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

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

The description opens with the verb 'Search' and names the exact resource (footage.cool's library), then specifies content categories, 4K masters, creator, regions, and years. This scope clearly distinguishes it from siblings like get_clip_details, get_catalog_overview, and find_similar_footage without needing to name them.

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

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

It provides strong context on when to use the tool: when searching a natural-language query across a specific footage library, with support for place names, years, synonyms, and typos. It does not explicitly exclude alternatives or compare to sibling tools, but the intended main-search role is unambiguous.

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