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

With no annotations, the description carries the burden and does substantial work: it discloses that the image is uploaded as a data URL, that some providers require a public HTTPS URL, that omitting generate_audio defers to the provider, and that HeyGen Video 1 mandates audio. It says nothing about cost-related behavior (allow_paid, max_cost_usd) or what dry_run actually returns, which for a paid generation call is a meaningful omission.

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?

Four dense sentences, front-loaded with the core action and capability gate, then the audio and upload caveats. No filler, though the cost/permission flags are crowded out by provider-specific trivia.

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?

A 13-parameter, no-annotation, no-output-schema tool with zero schema descriptions needs far more, especially around the paid-generation controls (allow_paid, max_cost_usd) and output handling. The description covers the image-upload path and audio semantics but leaves the majority of the surface unexplained.

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% across 13 parameters, so the description must compensate and largely does not. It adds real meaning only for generate_audio and the image input (data URL vs. public URL); prompt, duration, resolution, aspect_ratio, model, output_dir, filename, dry_run, allow_paid, and max_cost_usd are all undocumented in both schema and description.

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

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

States a specific verb and resource: animating a local image as the first frame of a video request, which is distinct from a plain text-to-video generate_video or a static edit_image. It never names a sibling explicitly, so the differentiation is inferable rather than stated.

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

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

Gives a hard precondition (only for models publishing supported_frame_images.first_frame) and a provider-specific caveat about audio, which constrains usage. However, it never says when to choose this over generate_video or edit_image, nor what to do when the model capability check fails, so the when/when-not guidance is only 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 no annotations, the description carries the full burden and does well: it discloses streaming behavior, temporary-file-plus-exclusive-rename semantics (implying non-corrupting writes), the authentication requirement of the endpoint, and that external URLs are not followed (a real SSRF-style safety disclosure). It omits permission scopes, overwrite behavior when filename already exists, and error modes, so 4 rather than 5.

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 with the core action first and behavioral constraints second; no filler, no restatement of the tool name.

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 zero annotation coverage, 0% schema description coverage, and no output schema, the description must do more: it never explains the optional parameters and never says what is returned (a local path? bytes?). Given the structured data provides nothing, this leaves the agent unable to invoke the tool confidently beyond the required job_id.

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% across 4 parameters. The description only implicitly maps job_id to the {id} path segment; it says nothing about index (which video variant), filename (does it override naming?), or output_dir (where files land). An agent must guess at three of four parameters.

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

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

States a specific verb (streaming download) and resource (a completed video via /videos/{id}/content), which is clearly distinct from siblings like get_video_status or generate_video. It never names a sibling to differentiate against, so it stops short of 5.

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

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

The precondition 'vídeo concluído' (completed video) implies when the tool is applicable and usefully guards against calling it mid-render. However, it names no alternatives (e.g. why not list_assets) and gives no explicit exclusions or error guidance for incomplete 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?

No annotations exist, so the description carries the full burden; it does add real value by stating the source image stays intact and the edited result is written as a new resource, which signals non-destructive behavior. However, it is silent on cost implications despite dedicated allow_paid and max_cost_usd parameters, and says nothing about permissions, failure modes, or whether dry_run is honored.

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

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

Two short sentences with no filler, and the key constraint (source image preserved, output is a new asset) is front-loaded. The phrase 'input_references do endpoint /images' is slightly jargon-heavy but does not waste space.

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

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

An 11-parameter image-editing tool with cost controls, a dry_run flag, output routing, and no annotations or output schema demands far more description than two sentences. The critical cost-safety parameters (allow_paid, max_cost_usd) and the dry_run switch are never mentioned, so an agent could invoke a paid operation unintentionally.

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% across 11 parameters, yet the description only gestures at input_image_path and leaves prompt, model, size, resolution, aspect_ratio, output_dir, filename, dry_run, allow_paid, and max_cost_usd entirely unexplained. An agent cannot tell from the description what units 'size' takes, what 'resolution' means alongside it, or what the paid-operation guardrails do.

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

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

The description names a specific verb and resource ('Edita uma imagem local'), and clarifies the mechanism ('usando input_references do endpoint /images'). It does not differentiate itself from close siblings such as generate_variations or animate_image, which also produce derived images, so the agent must infer the boundary.

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

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

There is no explicit statement of when to use this tool versus generate_image, generate_variations, or animate_image, all of which operate on images. The only implicit signal is 'imagem local', which hints the input must be an existing local file, but no exclusions or prerequisites are given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that it returns 'unknown' when catalogs cannot support a reliable calculation and avoids a fixed pricing table, but it does not state whether the tool is read-only, what response shape to expect, or other operational limits.

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

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

The two sentences are front-loaded and contain no filler. It is appropriately terse, though its brevity becomes a liability for such a parameter-heavy tool.

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 10 parameters, no annotations, no output schema, and zero schema descriptions, the description is far too thin. It mentions the unknown fallback but does not explain cost units, response format, or how the parameters affect the estimate.

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 10 parameters with 0% schema description coverage, and the description does not explain any of them. Terms like 'type', 'model', 'count', 'duration', 'resolution', 'aspect_ratio', and the image/video-specific counts are left entirely undocumented.

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

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

States a specific verb and resource: 'Estima o custo' using OpenRouter metadata. The purpose is clear, but it does not distinguish itself from sibling generation tools or explicitly say it estimates image/video generation cost.

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

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

The description gives no explicit when-to-use guidance, exclusions, or alternatives. At best, usage is implied by the sibling tools that generate images and videos, but the description itself does not route the agent.

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

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

With no annotations, the description carries the full load and does disclose meaningful traits: the model gets validated, every result is written to disk inside a restricted local root, and a paid-usage flag is mandatory. It still omits cost behavior (max_cost_usd is only in the schema), overwrite semantics for filename/output_dir, and whether dry_run suppresses the paid call.

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-loaded with purpose before constraints. No filler, though the paid-gate sentence could be merged to tighten further.

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 an 11-parameter generative tool with no annotations and no output schema, the description covers the mutation and the paid gate but leaves output shape (URLs? file paths? metadata?), cost guardrails, and the resolution/aspect-ratio relationship unexplained. Adequate as a minimum but incomplete.

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% across 11 parameters, so the description must compensate and it only explains allow_paid. The meaning and valid values of size vs resolution vs aspect_ratio, n's cap, dry_run, filename and output_dir interactions, and the cost ceiling are all left entirely undocumented.

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

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

States a specific verb and resource ('Gera imagens') plus the mechanism (dedicated OpenRouter /images endpoint) and a side effect (persists results under an authorized local root). It doesn't explicitly distinguish itself from sibling mutators like edit_image or generate_variations, but the purpose is unambiguous.

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

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

It gives one real precondition ('A geração exige allow_paid=true'), which is genuinely useful routing information. However, it never says when to prefer this over edit_image, animate_image or generate_variations, nor when not to call it.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses that the tool uses n when the model publishes it, otherwise sends exactly count requests after explicit authorization, but it omits cost implications, output/file side effects, and permissions for a 12-parameter generation tool.

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

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

The description is two sentences with no wasted words and front-loads the core purpose. The second sentence is dense but still concise; clarity could be improved by defining 'n' in context.

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

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

This is a complex tool with 12 parameters, no annotations, no output schema, and 0% schema description coverage. The description covers only the generation purpose and a narrow request-count rule, leaving most operational and parameter details 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 description coverage is 0%, so the description must compensate for all 12 parameters. It only explains the count parameter and the model-specific 'n' behavior, leaving prompt, size, model, dry_run, filename, allow_paid, output_dir, resolution, aspect_ratio, max_cost_usd, and input_image_path undocumented.

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

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

The description states a specific verb and resource: 'Gera um conjunto limitado de variações de um prompt ou imagem.' This is clear enough to distinguish it from generating a single image, though it does not explicitly reference sibling tools like generate_image or edit_image.

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

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

There is no guidance on when to use this tool versus alternatives such as generate_image, edit_image, or animate_image. The mention of 'autorização explícita' is a behavioral constraint, not a usage condition.

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

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

With no annotations, the description carries the full burden, and it does disclose three meaningful traits: the operation is asynchronous, a job record is persisted, and paid generation requires allow_paid=true. It still omits cost implications (max_cost_usd exists but is unexplained), what a failed/queued job looks like, and how the job is later retrieved via get_video_status.

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 compact sentences with the core operation front-loaded and no filler. Dense, though the model-specific constraint is packed into a sentence alongside the audio semantics, slightly blurring the focus.

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 an 11-parameter, no-output-schema, no-annotation mutation tool, the description leaves most of the surface unexplained. An agent cannot infer valid values for resolution, aspect_ratio, duration, model, or the cost guard from either the schema or the description.

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% across 11 parameters, so the description must compensate and largely fails. It explains only generate_audio, allow_paid, and a model-specific constraint (HeyGen Video 1), leaving prompt, duration, resolution, aspect_ratio, max_cost_usd, dry_run, filename, and output_dir entirely undocumented.

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

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

States a specific verb and resource ('Inicia text-to-video') plus the async persistence behavior, so the agent knows exactly what is produced. It does not distinguish itself from siblings like animate_image (which also produces video) or generate_image, so it stops short of a 5.

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

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

Gives real conditional guidance: generate_audio is optional and omission delegates to the provider, and allow_paid=true is a hard prerequisite for generation. However, it never says when to choose this over animate_image or generate_variations, nor when dry_run should be preferred.

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

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

No annotations are provided, so the description carries the full behavioral burden; it does disclose the important trait that this is a read-only status lookup that never creates a generation. It omits whether the call is retryable, what happens for invalid/expired job IDs, or whether the job state may be terminal.

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

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

Two short sentences, front-loaded with the action and scope, with the disambiguating constraint placed immediately after. Nothing is wasted.

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

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

For a single-parameter read tool with no annotations, the description covers action, scope, and the key non-creating constraint. The main remaining gap is that with no output schema, it never indicates what 'estado' contains (status values, progress, output URL).

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

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

Only one parameter and schema description coverage is 0%, so the schema alone says nothing about job_id. The description partially compensates by clarifying that the ID may be either local or remote, but it gives no format, example, or origin for those ID types.

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

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

States a specific verb and resource ('Consulta o estado de uma tarefa de vídeo existente pelo ID') and scopes it to existing jobs. The closing clause 'Nunca cria uma nova geração' implicitly separates it from generate_video, though no sibling is named explicitly.

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

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

The negative constraint ('Nunca cria uma nova geração') tells the agent this is not a generation call, which is useful routing. However, it never says when to call it instead of download_video or how it fits after generate_video (polling an existing job), so usage is only 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 no annotations, the description must carry the behavioral burden; it does disclose that no binary content is returned, which sets the response expectation. It is silent on read-only safety, default page size, ordering, and what project_root scoping means, so several behavioral traits remain undisclosed.

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

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

A single efficient sentence with the resource and the non-binary constraint front-loaded and no filler. It is arguably too terse for what it omits, but there is no wasted text.

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?

Three parameters at 0% schema coverage, no annotations, and no output schema, so the description is the only channel for guidance — yet it explains neither the project_root scoping requirement nor the limit/pagination behavior, leaving the agent to guess at two of three inputs.

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% and the description adds nothing about any of the three parameters. The 'type' enum is self-explanatory, but 'limit' defaults/caps and especially 'project_root' (no enum, no description, no hint that it scopes which project's assets are listed) are left entirely unexplained in both places.

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 ('Lista') plus a precise resource ('metadados de imagens e vídeos gerados pelo MCP') and adds the key scope qualifier 'sem devolver conteúdo binário'. An agent can tell this is a metadata-listing tool rather than a generation or download tool, though no sibling is named explicitly.

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

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

Usage is only implied: the phrase 'sem devolver conteúdo binário' hints that actual file retrieval belongs to a different tool (likely download_video), but that alternative is never named and no when-to-use condition is stated. Adequate for an obvious listing tool, but it leaves the agent to infer the boundary with siblings.

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

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

With no annotations, the description must carry behavioural disclosure. It does add a useful data-provenance caveat ('expõe somente capacidades e preços publicados pelos endpoints'), implying no local inference or estimation, but it never states the operation is read-only, that results may be cached, or what the response shape is.

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

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

Two short sentences, front-loaded with the verb and resource, with no redundant restatement of the tool name. Nothing is wasted.

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

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

For a three-parameter tool with zero schema description coverage and no annotations or output schema, the description is too thin. An agent cannot learn from it what search does, what refresh invalidates, or what the returned catalog entries contain.

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% and the description never mentions type, search, or refresh. Only an indirect hint exists ('modelos de imagem e vídeo' loosely maps to the type enum), leaving the search filter and especially the refresh/cache-reset flag completely unexplained.

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

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

States a specific verb (consulta) and a specific resource (catálogos atuais de modelos de imagem e vídeo do OpenRouter), which clearly separates it from the generation/estimation siblings. It does not explicitly name an alternative, but the read-only catalog framing is unambiguous.

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

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

Usage is only implied: 'catálogos atuais' suggests discovery of available models, but there is no statement about when to prefer this over estimate_cost or before calling generate_image/generate_video. No exclusions or prerequisites are given.

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