MaxVideoAI

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it emphasizes 'current pricing' (live data), and explicitly rules out side effects like reserving a price, creating a quote, or spending funds. This reinforces the read-only nature and clarifies scope, though it does not describe response format or validation behavior, which are minor gaps given 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?

Two sentences, zero filler. The positive usage condition is front-loaded, followed immediately by a compact list of exclusions. Every phrase earns its place and no information is repeated from the schema 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?

For a complex one-parameter tool with a detailed nested schema and annotations covering safety, the description fully covers invocation context and boundaries. It does not explain the return value or output structure since there is no output schema, but the name and 'current pricing' phrasing make the outcome reasonably inferable. The missing explicit output description is a minor gap, not a fatal one.

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

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

The input schema has 100% description coverage for the single 'proposals' parameter, including nested property documentation with enums and guidance like 'Never infer this from the mode name or another mode.' The description adds only high-level framing ('concrete proposals, mixed models, clip counts, explicit creative attempts') that does not fundamentally extend the schema semantics. Baseline 3 is appropriate because the schema carries the parameter-information burden.

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-resource pairing: 'use this when the user wants current pricing for one or more concrete video production proposals.' It further distinguishes the tool by naming what it is not for—inventing the creative plan, reserving a price, creating a generation quote, inspecting the wallet, or spending funds—which clearly distinguishes it from siblings like prepare_generation, create_topup_link, and get_account_status.

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

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

The description explicitly states when to use the tool ('when the user wants current pricing for one or more concrete video production proposals') and provides a clear when-not-to-use list. These exclusions effectively route the agent toward alternatives without needing to name them individually, giving complete usage 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 mark it idempotent, destructive, and open-world; the description enriches these with concrete consequences: wallet funds may be spent, trial funds do not, exactly one paid attempt is authorized, and duplicate requests return the existing job. No contradiction with annotations.

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

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

Every sentence provides decision-relevant information: purpose, funding impact, idempotency, retry prohibition, and fresh-approval requirement. It is front-loaded with the core action and contains no filler.

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

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

For a financial, externally-facing mutation, the description covers side effects, idempotency, retry policy, and funding source. The only implicit detail is the exact success payload, but the duplicate-returns-job behavior and sibling get_generation_* tools make the expected outcome usable.

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

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

Schema description coverage is 0%, so the description must supply meaning. It maps quoteId to an exact prepared quote with funding locked in and explains trial vs wallet funding, and it ties confirmed to explicit user approval. It does not name the parameters literally, but the two-parameter schema makes the mapping straightforward.

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 states a specific verb and resource: it confirms one exact prepared quote and contacts an external generation provider. It also implies distinction from prepare_generation/present_generation by stressing the exact quote and locked funding.

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 forbids using the tool to retry failed generations and states that a fresh quote plus new explicit user approval is required for another attempt. That is a clear when-not to use it, with the correct alternative workflow implied.

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

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

With all annotation hints false, the description carries the burden and does so well: it discloses that the tool only creates a handoff, that persistence happens only after upload, and that the handoff is not proof of completion. It also warns against using the handoff to start generation or modify assets, adding safety context absent from 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?

Three sentences, front-loaded with the use case, with each sentence adding non-redundant information: when to use, what it creates, and what not to infer from it. No filler or repetition of schema fields.

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 tool with no output schema, the description gives enough behavioral context for invocation: what the tool returns (a handoff), what happens after upload, and how it connects to list_media. It could specify expiration duration or exact response shape, but these are minor for this level of complexity.

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 contains only 'kind' with an enum but no parameter descriptions (0% coverage). The description compensates by enumerating the accepted media kinds (image, video, audio) and tying them to the 'one private reference' use case, though it doesn't add much beyond restating the enum values.

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

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

Description leads with 'Use this when the user needs to add one private reference,' giving a concrete verb and resource scope, and clarifies it produces a 'short-lived browser handoff' rather than the upload itself. This distinguishes it from sibling tools like import_reference_files or list_media by focusing on a single private reference upload.

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 opens with 'Use this when the user needs to add one private reference by requested media kind,' giving a clear trigger. It also provides negative guidance ('Do not use the handoff alone as proof that upload completed, to start generation, or to modify an existing asset'), though it does not name an alternative tool for those other jobs.

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 mark the tool as non-read-only and non-idempotent, but the description adds crucial behavioral details: the handoff is short-lived, payment is collected externally by MaxVideoAI, and the tool invalidates the old short-lived quote. It also warns about the required post-funding workflow dropdown. This goes well beyond what the annotations or schema convey.

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 with no filler. Every clause contributes essential information: short-lived, no payment handling, invalidation of the old quote, and recommended follow-up. The purpose is front-loaded and the structure makes the side effect and next steps easy to parse.

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 a single parameterhare, no output schema, and no nested objects, the description covers the trigger, side effects, and follow-up actions. The only gap is that it does not explicitly describe the return value (presumably the top-up handoff URL), though the tool name 'link' and the phrase 'web handoff' make the output reasonably inferable.

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 0% schema description coverage, the description must compensate for the lone quoteId parameter. It never explicitly names quoteId or states 'quoteId is the identifier of the prepared quote,' but the phrases 'the prepared quote' and 'old short-lived quote' make that mapping inferable. For a single parameter, this is minimally adequate but not explicitly documented.

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: 'Creates a short-lived MaxVideoAI web handoff' and scopes it to a concrete condition ('when the prepared quote needs more credits'). It also clarifies a likely misconception ('does not take payment'), which distinguishes it from payment-related workflows. The purpose is unambiguous and clearly differentiated from siblings like create_reference_upload_link.

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 an explicit trigger condition ('when the prepared quote needs more credits') and a clear follow-up sequence: after funding, call get_account_status then prepare_generation for an exact quote. It also states an exclusion: this tool does not take payment. However, it does not explicitly name an alternative tool to use instead, so the guidance is strong but not fully explicit about 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 mark it read-only and non-destructive; the description adds behavioral boundaries beyond that by stating it must not reveal private email, collect payments, charge credits, change the wallet, or generate media. It does not describe response shape or potential limitations, but the added exclusions are meaningful.

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 front-loaded sentences: the first enumerates triggering intents, the second enumerates exclusions. Every clause earns its place, and there is no redundant restatement of the title.

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 parameters, read-only annotations, and a clear enumeration of returned data (account, balance, trial state, spending limits, destinations), the description is sufficient for an agent to invoke and interpret the tool correctly. The only mildly opaque term, 'safe account destinations,' is a minor domain detail.

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 are zero parameters and schema coverage is 100%, so the baseline is 4. The description does not need to explain parameters; it adds value by enumerating the account-related data points an agent can expect.

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

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

The description names a clear resource (MaxVideoAI account) and the exact data the tool exposes: connected account, credit balance, trial state, spending limits, and safe account destinations. It also distances itself from sibling tools by excluding media generation, so an agent can distinguish it from get_generation_status and list_media.

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

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

It gives an explicit trigger condition ('when the user asks which MaxVideoAI account is connected...') and an explicit do-not-use list covering private email, payment details, charging credits, wallet changes, and media generation. This leaves no ambiguity about when to select this tool over 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 declare readOnly, idempotent, and non-destructive behavior. The description adds practical behavioral context: the URL is short-lived, requires generation completion, and is ownership-scoped. No contradiction with annotations.

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

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

A single, front-loaded sentence with no filler. Every clause contributes meaning: source context, action, freshness, scope, and ownership constraint.

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 tool with an output schema and strong annotations, the description covers the key constraints: where to call it, what it returns, and what prerequisites apply. The only minor gap is not explicitly naming jobId as the generation ID, but this is easily inferable.

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

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

The input schema provides only a bare jobId string with no descriptionholistically, and schema description coverage is 0%. The description implies jobId refers to a generation ('one completed owned generation') but never explicitly explains that jobId is the generation identifier, leaving some inference to the agent.

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

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

The description clearly states a specific action: create a fresh short-lived attachment URL for a completed owned generation. It distinguishes this from sibling tools like get_generation_status, prepare_generation, and present_generation by naming the exact resource and outcome.

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: use it from the MaxVideoAI result app and only for completed owned generations. It does not explicitly name alternatives or when not to use it, but the context is sufficiently directive.

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 and non-destructive, and the description adds value by framing the read as recovering a 'safe current state' and by disclosing response boundaries (no prompts, provider details, or private media). This is useful behavioral context beyond the annotations, with no contradiction.

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

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

The description is two sentences with no filler. It front-loads the action ('Use this to recover') and packs the key return fields and exclusions into a compact, readable format.

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

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

For a single-parameter, read-only status tool with no output schema, the description is mostly complete: it lists return categories, scopes the resource to owned generations, and notes exclusions. It could add more about error behavior or what 'safe current state' means, but the essentials are covered.

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

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

There is one required parameter, jobId, with 0% schema description coverage, and the description does not meaningfully elaborate on the parameter. The phrase 'one owned generation' hints at ownership scope, but it does not explicitly tie jobId to a generation or explain how to obtain it, so the description does not compensate for the schema gap.

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 ('recover'), a clear resource ('the safe current state... for one owned generation'), and explicitly lists what is returned. It also distinguishes itself from media-fetching tools by stating what it never returns ('prompts, provider details, or private media').

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

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

The description opens with 'Use this to recover...', which gives a clear usage context. It does not explicitly name alternative sibling tools or define when not to use this tool, but the return-boundary statement ('never returns prompts...') provides some exclusion 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 signal safe read-only behavior, and the description adds meaningful scope: only public models, reviewed official prompting sources, exact/current data, and explicit exclusions. This does not contradict the readOnlyHint and adds context beyond the annotations.

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

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

Two sentences, both informative: the first front-loads the intended use and data categories, the second lists exclusions. There is no filler, repetition, or unnecessary detail.

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

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

For a one-parameter read-only lookup, the description covers what data to expect, the constraint that the model must be public and known, and what not to use it for. The schema supplies the ID provenance, and sibling list/recommend tools are evident from context.

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% for the single id parameter, and the schema already states it is an exact public MaxVideoAI model ID returned by list_models or recommend_models. The description adds no further syntax, format, or meaning beyond what the schema provides.

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

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

The description names the exact resource ('one known public MaxVideoAI model') and the kind of data returned (capabilities, constraints, evidence, reviewed official prompting sources, links). It also distinguishes this from list/recommend siblings by requiring a known single model and explicitly excluding hidden models.

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 clear when-to-use trigger ('when the user needs exact current capabilities...') and an explicit 'Do not use' list (pricing, generation, hidden models, provider guarantees). It does not name alternative tools to route to, though the schema's reference to list_models/recommend_models partially compensates.

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 communicate readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds value by revealing that it mutates the library by importing files, requires user authorization, returns reusable asset IDs in input order, and only accepts temporary host file handles. This is useful behavioral context beyond the annotations.

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

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

The description is three sentences with no filler. The main action is front-loaded, followed by usage guidance, return behavior, and exclusions. Every sentence contributes a distinct, decision-relevant piece of 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 state-changing tool with no output schema, the description covers the core context: what is imported, when to use it, what is returned, and what to avoid. It does not cover response format or error/duplicate behavior, but the provided detail is sufficient for correct tool selection and invocation in most cases.

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

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

There is only one parameter and schema description coverage is 0%, so the description must compensate. It does add meaning by clarifying that 'files' refers to temporary host file handles and that results are returned in input order, and it warns against invented URLs. However, it does not explain the nested fields (download_url, file_id, file_name, mime_type) or any validation beyond the schema's structural constraints.

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 ('Import'), names the resource ('image, video, or audio files'), and constrains the source ('temporary host file handles') and destination ('connected private MaxVideoAI library'). It also distinguishes itself from siblings by stating the return is asset IDs in input order and explicitly excluding invented URLs, existing library assets, local filesystem paths, generation, and spending.

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 states when to use the tool: 'Use this when the host provides attachments or authorized generation results as file handles.' It also gives a clear when-not list ('Do not use with invented URLs, existing library assets, local filesystem paths, generation, or spending'). It could name a specific alternative like create_reference_upload_link for non-host-handle sources, but the guidance is already strong.

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 the tool as read-only and non-destructive. The description adds useful behavioral context: assets are private, results are only safe metadata and controlled previews, and storage/provider URLs are not exposed. This complements 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?

Two sentences, front-loaded with the use case and immediately followed by exclusions. Every clause adds information, and there is no filler or repetition.

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?

Provides enough for a safe basic invocation: purpose, return type (safe metadata and previews), and exclusions. However, with no output schema and minimal parameter documentation, it leaves pagination semantics, the limit/cursor relationship, and whether kind can be omitted unresolved.

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

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

Schema description coverage is 0%, so the description must compensate. It gives semantic meaning for 'kind' as a media-kind filter, but it does not explain 'limit' or 'cursor', pagination behavior, or the fact that the schema lists no required parameters while the description says 'required media kind'.

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 the action (list) and precise resource (private MaxVideoAI reference media yielding image/video/audio asset IDs). It also explicitly disambiguates from uploads, exposing URLs, and generation, so an agent can distinguish it from sibling 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?

Opens with an explicit when-to-use condition: user needs reusable private asset IDs. It also gives clear when-not-to-use exclusions: not for uploading files, exposing storage/provider URLs, or starting generation. This provides strong selection guidance even without naming 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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral context beyond annotations: all filtering fields are nullable, null must be sent when a constraint is unstated, and placeholders are forbidden. It also clarifies the data scope as public rather than private or provider-guaranteed, which is useful for invocation.

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

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

Three sentences with the primary usage guidance front-loaded)SkipHere. Every sentence earns its place: when to use, null-handling rule, and explicit exclusions. No filler or redundant restatement of the schema.

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

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

For a read-only filtering tool, the description explains scope, constraints, null semantics, and exclusions, which covers most invocation needs. There is no output schema and the description does not describe the exact return shape, but the phrase 'model capabilities' plus filter context makes the expected result reasonably inferable, leaving only a minor completeness gap.

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; each parameter already has a clear description like 'or null unless the user constrained it.' The description's global instruction that every filtering field is nullable reinforces the schema but does not add substantial new parameter-level meaning beyond what is already present.

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 (list) applied to a clearly bounded resource: 'current public MaxVideoAI image or video model capabilities,' including audio and reference-image support. It further distinguishes itself by explicitly excluding generation, exact pricing, private models, and provider guarantees, so an agent can tell it apart from siblings like get_model_details or prepare_generation.

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 opens with 'Use this when the user needs current public...' and closes with 'Do not use it for generation, exact pricing, private models, or provider guarantees,' giving practical selection guidance. It does not name specific sibling tools as alternatives, but the exclusions effectively route agents away from clearly different operations.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds context about pagination ('bounded page'), user scoping ('same connected user'), and output contents (workspace links, public result links). It does not describe cursor mechanics or order, but it adds useful context 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 a single sentence that front-loads the purpose ('Use this to recover a bounded page...') and packs all essential information without waste. It is efficient and to the point.

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 4 parameters with zero schema descriptions. The description provides a broad overview but omits specifics on how to use the cursor for pagination, the meaning of the status enum, or the exact response shape. It covers some aspects (surface, page bounding) but leaves room for misunderstanding, especially for an agent needing to make precise calls.

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

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

Schema description coverage is 0%, so the description must compensate. It explicitly mentions 'image, video, or Audio' which maps to the `surface` parameter, and 'bounded page' hinting at `limit` and `cursor`. However, it does not explain the `status` filter or detail how cursor pagination works, leaving gaps for the agent.

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 action ('recover a bounded page') and resource ('MaxVideoAI library'), and specifies the content types (image, video, audio) and output elements (workspace links, safe public result links). It does not explicitly differentiate from siblings like list_media, but the resource is specific enough that an agent can infer its scope.

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 opens with 'Use this to...', giving a clear directive for when to invoke the tool (to recover a page of generations). However, it does not mention when not to use it or point to alternatives (e.g., get_generation_status for a single item, list_media for broader media). The guidance is present but not comparative.

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

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

With annotations already indicating this is not read-only and not destructive, the description adds valuable context: it 'saves the quote but does not spend or generate' and produces a 'short-lived' quote. This clarifies the side-effect boundary beyond what the annotations alone convey, though it does not cover rate limits or auth requirements.

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 four dense sentences, with the trigger condition front-loaded and the side-effect boundary stated immediately. Every sentence contributes distinct operational guidance, with no filler or repetition.

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 complex tool with no output schema, the description covers the key decision boundary, side effects, and a critical parameter pitfall. However, it does not explain the shape of the returned quote, how validation failures are communicated, or explicitly name get_model_details as the prerequisite source for the selected mode's live details, leaving some operational gaps.

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

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

Schema description coverage is only 13%, so the description must compensate, but it only provides two parameter-specific rules: optional fields should be sent as null when not required, and video duration must be settings.durationSec, never settings.duration. It offers no guidance on references, outputCount, schemaVersion, or the meaning of the required parameters, leaving a significant semantic gap.

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

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

The description names a specific verb (prepare/validate + quote) and resource (a MaxVideoAI generation), lists the supported workflows, and clearly distinguishes itself from confirm_generation by stating it 'does not spend or generate.' This lets an agent understand the tool's role without opening the 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?

The description explicitly states when to use the tool ('when the user has selected an image model or a supported video workflow... needs validation plus an exact short-lived quote') and gives a clear when-not ('Do not use it as confirmation or skip the selected mode's live model details'). It does not explicitly name the alternative sibling tool, such as confirm_generation, so it falls just short of full alternative routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context: that it requires a completed and owned generation, that it presents media inline, and that it does not trigger generation or billing. This goes 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 two sentences, front-loaded with the core purpose, and wastes no words. It packs the essential usage guidance into a compact format, making it easy for an agent to parse quickly.

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

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

Given the single parameter, presence of safety annotations, and absence of an output schema, the description covers the essential context: when to call, prerequisites, and what the tool does. The only minor gap is parameter explanation, which is already penalized in parameter_semantics. Otherwise, the agent has enough information to decide when and how 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 coverage is 0% — the description gives no information about the jobId parameter. While the name 'jobId' is somewhat self-explanatory, the description does not clarify that it should be the ID of the completed generation, nor its format or constraints. With zero coverage, the description carries the full burden for parameter semantics and fails to do so.

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 presents a completed owned MaxVideoAI generation inline as playable media. It explicitly contrasts with sibling tools by saying it is not for polling, generating, retrying, or charging credits, and directs the agent to get_generation_status or list_recent_generations first. This fully differentiates it from the listed siblings.

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

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

The description provides explicit when-to-use (completed owned generation to show inline) and when-not-to-use (poll, generate, retry, charge credits). It also names the prerequisite calls (get_generation_status or list_recent_generations) and implies alternatives, leaving no ambiguity about tool selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: every optional constraint must be sent as null (never a placeholder), and the tool must not be treated as a quote, generation command, or acceptance guarantee. This clarifies limitations beyond what annotations provide, though it does not describe the return format or whether the tool can ask follow-up questions beyond the hint to ask about missing goals.

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 sentences, each earning its place: the trigger condition, the null rule, the prerequisite to call calculate_project_budget, and two exclusion clauses that disambiguate from sibling tools. It is front-loaded with the core purpose and then adds operational constraints, with no filler or repetition of schema content.

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 13-parameter tool with no output schema and a large sibling set, the description covers the key decisions: when to use, what to ask, how to handle nulls, and which sibling to delegate cost calculations to. It does not explicitly describe the output structure (e.g., a ranked list with alternatives), only implying it through 'best-fit ... plus strong alternatives', which is a minor gap given the absence of an output schema.

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

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

With 100% schema description coverage, the baseline is 3, but the description adds cross-cutting parameter semantics: the universal null-for-unstated rule applies to all 13 optional parameters and prevents placeholder misuse (e.g., 'never use 300 as a placeholder' in maxDurationSec). It also reinforces the relationship between budgetCeilingCents and calculate_project_budget, and ties priorities like lower_cost to that sibling tool, providing guidance that goes beyond per-field schema text.

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 ('recommend') and resource ('MaxVideoAI models') and defines the exact trigger: the user is undecided, asks for advice, or wants a best-fit model plus alternatives. It further distinguishes itself from siblings by explicitly excluding validation, pricing, and execution use cases, and by naming calculate_project_budget as the alternative for cost questions.

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

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

The description provides explicit when-to-use ('user is undecided, asks for advice') and when-not-to-use conditions ('already chose a compatible model and only wants validation, pricing, or execution'; 'not an exact quote, a generation command, or a claim that a provider will accept a job'). It also names the sibling tool calculate_project_budget and instructs to use it before requesting a cheaper/lower-cost alternative, leaving no ambiguity about routing.

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