Search and license 54,000+ drone, aerial, and ocean clips, mostly 4K, from filmmaker Phil Maher.
Scored across 10 tools
Each tool targets a clearly distinct stage of the footage search, planning, licensing, and purchase workflow. Even the two pricing-related tools (license_clip and quote_4k_license) are separated by general options versus a formal purchase quote, and their descriptions explicitly point to the correct next step.
All tool names follow a consistent verb_noun snake_case pattern: build_, check_, create_, find_, get_, license_, quote_, search_. The 4k qualifier is used uniformly across checkout, order, and license tools, making the set predictable and easy to navigate.
Ten tools is well-scoped for a stock footage licensing server. Each tool covers a meaningful step—discovery, details, similarity, overview, rights, pricing, quoting, checkout, order verification, and rough-cut planning—without redundant or superfluous additions.
The tool surface covers the full footage workflow from search and browse through rights screening, quoting, payment, and post-purchase license/download retrieval. Rough-cut planning adds a useful creative step, and no critical operation is missing for the stated domain.
Plan a timed edit from a description: picks and orders clips across different shoots and locations, sets a cut length for each at the chosen pace, and totals the license cost. Returns an edit decision list with preview URLs for a storyboard or rough cut. It does not render video or license anything.
| Name | Required | Description | Default |
|---|---|---|---|
| pace | No | Editing pace: slow (4 to 8s per clip), balanced (3 to 6s), fast (2 to 4s). Default balanced. | |
| query | Yes | Description of the sequence, for example 'baja road trip along the coast' or 'whales and dolphins in the Sea of Cortez'. | |
| people | No | Use 'none' for a people-free cut. Default any. | |
| year_to | No | Latest shot year. | |
| category | No | Optional scene category or curated slug, as in search_footage. | |
| location | No | Optional place filter. | |
| year_from | No | Earliest shot year. | |
| target_seconds | No | Target timeline length in seconds, 20 to 600 (default 60). |
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.
Screen whether a license covers an intended use for a clip and which tier fits: commercial, editorial, documentary, internal_corporate, digital (web and social), broadcast, theatrical, or ai_training. Reports chain of title, people and property flags, and the release policy. Catalog screening, not legal advice.
| Name | Required | Description | Default |
|---|---|---|---|
| clip_id | Yes | The clip to check. | |
| intended_use | No | Intended use: commercial, editorial, documentary, internal_corporate, digital, broadcast, theatrical, or ai_training. Default commercial. AI training needs a separate data license. | |
| expected_distribution | No | Optional expected views or copies. Above 1,000,000 needs the Extended license. |
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.
Create or resume Stripe hosted checkout for a quote. Call ONLY after the user explicitly approves the quoted clip, the master resolution, license type, total price, and terms. Returns a checkout URL for the user and a private order token. The user pays securely on Stripe; never collect card details in chat. Calling again with the same quote returns the same checkout. Creating checkout is not proof of purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| confirmed | Yes | Set true only after the user explicitly approves the quoted clip, master resolution, license, price, and terms. | |
| quote_token | Yes | Private quote_token returned by quote_4k_license. Never put it in public links or logs. |
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.
Find clips similar to a given clip: shared subjects, scene, location, and shot year, spread across different shoots so the results are not near-duplicates. Use it to offer alternatives or to keep a sequence consistent.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of results, 1 to 24 (default 8). | |
| clip_id | Yes | Clip to find similar footage for (clip_id from search_footage). |
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.
Check an order after checkout. Verifies the payment directly with Stripe, then returns the active license, receipt, license certificate link, and a private download link for the clean master. Requires the private order token from create_4k_checkout. Never report the purchase as complete unless purchase_completed is true. Poll no faster than once every 10 seconds. Keep the token and links private.
| Name | Required | Description | Default |
|---|---|---|---|
| order_token | Yes | Private order_token returned by create_4k_checkout. Keep it and the returned links private. |
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.
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. Use it to see what exists and to find valid category values for search_footage and build_rough_cut.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Get full details for one footage.cool clip: description, tags, location, shot year, duration, people and release notice, collection, thumbnail, watermarked preview, clip page, the master's verified resolution and codec when known, and licensing options with prices.
| Name | Required | Description | Default |
|---|---|---|---|
| clip_id | Yes | The clip_id returned by search_footage (numeric, or a filename-style id). A footage.cool clip URL also works. |
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.
Get licensing options and prices for a clip without charging anything: Royalty-Free Standard (from $79), Extended for broadcast (from $199), and Exclusive Buyout (quoted by email). This tool never issues a license or takes payment; quote_4k_license starts a purchase.
| Name | Required | Description | Default |
|---|---|---|---|
| clip_id | Yes | The clip_id returned by search_footage (numeric, or a filename-style id). A footage.cool clip URL also works. |
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.
Quote a license for a clip's clean, unwatermarked master. Verifies the master file in storage and reports its exact resolution and codec: nearly every master is 4K UHD, and when one is lower (HD 1080p or 2.7K) the quote includes a resolution_notice that you must pass on to the user. Prices the chosen license from the site's direct pricing and returns a private quote token valid for 30 minutes. Ask the user for the buyer email and the license type first; never invent an email. Does not charge anything. Show the full quote, including the resolution, and the terms link to the user before asking to check out. AI training is excluded.
| Name | Required | Description | Default |
|---|---|---|---|
| clip_id | Yes | The clip to license. | |
| usage_scope | No | Optional intended use (commercial, editorial, documentary, internal_corporate, digital, broadcast, theatrical). Broadcast and theatrical require rf_extended. | |
| license_type | Yes | rf_standard: all media, worldwide, perpetual, up to 1,000,000 views or copies. rf_extended: adds unlimited distribution, broadcast TV, theatrical, and streaming originals. Let the user choose. | |
| customer_email | Yes | Buyer email for the license certificate and receipt. Ask the user; never invent one. | |
| expected_distribution | No | Optional expected views or copies. Above 1,000,000 requires rf_extended. |
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.
Search footage.cool's library of 54,000+ drone, aerial, ocean, underwater, wildlife, and travel clips (4K UHD masters on nearly all), filmed by Phil Maher mostly in Baja California Sur (Los Cabos, Cabo Pulmo, East Cape, La Paz, Todos Santos), plus the Colorado Rockies and the California coast, 2014 to 2024. Understands place names, years, synonyms (drone = aerial), and typos. Returns clips with metadata, verified master resolution when known, thumbnail and watermarked preview URLs, clip page links, and prices. Real camera and drone footage, not AI-generated.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for more results (default 1). | |
| sort | No | Default 'relevance'. 'best' sorts by visual quality score. | |
| limit | No | Results per page, 1 to 50 (default 10). | |
| query | Yes | What to find, in plain words. Descriptive works best: 'humpback whale breaching aerial', 'turquoise bay with boats cabo pulmo', 'desert highway at sunset'. Places and years in the query become filters. | |
| people | No | 'none' returns clips with no people flagged (easier commercial clearance), 'with' only clips with people. Default any. | |
| year_to | No | Latest shot year (for example 2023). | |
| category | No | Optional scene category (Aerial, Beach, Ocean, Wildlife, People, Road, Landscape, Desert, Urban, Sunset, Architecture, Nature, Mountain, Forest, Agriculture, Other) or a curated slug such as drone, underwater, whales, surfing, cabo-pulmo, los-cabos, colorado. get_catalog_overview lists all of them. | |
| location | No | Optional place filter matched against city, region, and country (for example "Cabo Pulmo", "Colorado", "Mexico"). | |
| year_from | No | Earliest shot year (for example 2019). | |
| max_duration_seconds | No | Longest clip length to include, in seconds. | |
| min_duration_seconds | No | Shortest clip length to include, in seconds. |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_4k_checkout1 field changedInput schema / properties / confirmed / descriptionPrevious value: -"Set true only after the user explicitly approves the quoted clip, master, license, price, and terms."New value: +"Set true only after the user explicitly approves the quoted clip, master resolution, license, price, and terms."build_rough_cutcheck_clip_rightscreate_4k_checkoutfind_similar_footageget_4k_orderget_catalog_overviewget_clip_detailslicense_clipquote_4k_licensesearch_footageSearch and license 217,000+ authentic vintage 8mm home movie clips (1930s-1980s).
Human-made production music for sync — search by brief or reference, preview, score to picture.
Search 18,594 production-music cues by mood, sound and exact runtime. Instant preview links.
Search 2M+ licensed production-music tracks, find similar ones by track or audio, share pick lists.
Add one secure layer between your agents and this server.
