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

With no annotations, the description carries the full behavior burden. 'Durable job' hints at asynchronous, persistent execution, but nothing is said about side effects, return values, how to track the job, polling expectations, or failure behavior. This is thin coverage for a job-submission operation.

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

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

One short sentence with no filler. The verb, resource, and key qualifier ('durable') are all front-loaded, making the intent immediately graspable.

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 job-generation tool with no output schema and no annotations, the description omits critical details: how the agent receives a job reference, how to check status (though sibling tools like media.job.status exist), and what input 'prompt' expects. An agent could not successfully invoke this tool based solely on the provided definition.

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 requires 'prompt' but defines no properties, and the description does not mention the prompt or any other parameters. An agent receives no guidance about what the prompt should contain, its format, or optional parameters, despite additionalProperties being allowed. The description fails to compensate for the schema's missing parameter definitions.

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 ('Submit') and identifies the resource ('durable music generation job'), making the core operation clear. It does not explicitly name sibling tools such as media.audio.voice or media.compose, so an agent might need to infer the distinction, but 'durable job' does suggest a submitted, asynchronous task rather than a synchronous 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?

No guidance is provided on when to use this tool instead of alternatives like media.audio.voice, media.compose, or media.video.generate. There is no mention of typical use cases, prerequisites, or exclusions, leaving the agent to guess about context.

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 provided, the description carries the full behavioral burden. It only reveals that the job is 'durable' and submitted asynchronously, but it does not disclose whether a job ID is returned, how results are retrieved, whether the operation is non-blocking, what failure modes exist, or any rate/cost limitations. This is insufficient for a tool with no other behavioral metadata.

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 entire description is one sentence and every word contributes: it identifies the action, the resource, and the job's durable/asynchronous nature. There is no fluff, repetition, or irrelevant 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 tool with no annotations, an empty property schema, no output schema, and a single required parameter, the description is too sparse. An agent would not know what the required 'text' should look like, what the tool returns, or how to observe the result of the 'durable job' (e.g., via media.job.status).

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 requires 'text' but provides no property description in 'properties' (which is empty). The description never explicitly names 'text' or explains its expected format, length limits, or language support. 'TTS' hints that text is the content to synthesize, but the core input remains undocumented at both schema and description levels.

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 ('Submit') and resource ('durable voice/TTS generation job'), clearly identifying it as a text-to-speech/voiceover job submission tool. This distinguishes it from sibling tools like media.image.generate, media.video.generate, and media.audio.music, though it does not explicitly name an alternative.

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

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

The intended use case—voice/TTS generation—is implied by the phrase 'voice/TTS', which differentiates it from music or visual generation tools. However, there is no explicit when-to-use guidance, no exclusions, and no indication of when to prefer this over job-control siblings like media.job.run_once or media.audio.music.

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 available, the description carries the full burden of disclosing behavior. The verb 'Return' implies a read-only operation, and the manifest framing suggests no side effects, but the description does not explicitly state that it has no side effects, how the manifest is structured, or whether it reflects provider-specific capabilities. This is adequate but not rich.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the essential action and resource scope immediately.

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-input tool this is minimally viable: an agent can invoke it without parameters and expect a manifest. However, there is no output schema and the description does not explain what a 'capability manifest' contains or how the V1-V6 versions are represented, leaving meaningful ambiguity about the return format.

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, and the input schema is empty, so parameter documentation is unnecessary. The description adds the useful detail that the returned manifest covers V1 through V6, which is the only semantic context needed for a no-input call.

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 ('Return') and a specific resource ('V1-V6 capability manifest'), so an agent can tell it returns capability information. It does not explicitly differentiate from siblings like media.provider.status or media.job.status, but the version-scoped manifest is reasonably distinctive.

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?

No guidance is given about when to call this tool versus alternatives, or when it should be used as a prerequisite for other media operations. The description only states what the tool does, leaving the agent to infer use cases.

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 burden of behavioral disclosure. It states that a Character Bible is created, but does not disclose whether the lock is permanent, whether it affects later media generation, whether it can be replaced, or what side effects it has. The word 'lock' suggests a possibly restrictive behavior that is never explained.

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 short sentence with no filler, so it is concise. However, it is under-specified rather than efficiently informative. The phrase 'Character Bible / identity continuity lock' is not structured to front-load the most actionable meaning.

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 no annotations, no output schema, and an input schema that lacks property definitions, this description is severely incomplete. It does not explain return values, side effects, required project context, or how the lock affects other media operations. An agent would struggle to know the expected effect or how to verify success.

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

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

The description adds no meaning for the required parameters 'projectId', 'name', and 'description', and the input schema defines no properties despite requiring these fields. The parameter names are somewhat self-explanatory, but the description does not clarify format, constraints, or relationships between them. Because there are required parameters and zero schema-level property descriptions, the description should have compensated but did not.

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 ('Create') and names a distinct resource ('Character Bible / identity continuity lock'). It is clear enough to be distinguished from sibling tools, none of which cover character identity management. However, 'identity continuity lock' is jargon and could be more explicit about what locking entails.

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?

No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or prerequisites, and there is no explicit context for when an agent should call this tool versus other media creation tools. Usage is only vaguely implied by the phrase 'identity continuity lock'.

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 and no output schema, the description carries the full burden of explaining behavior, but it only says 'Submit an FFmpeg composition/render job.' It does not state whether this is asynchronous, whether it returns a job ID, what side effects occur, or whether it validates inputs before queuing. This is a significant gap for a job-submitting 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 a single focused sentence with no filler, fluff, or repetition. It is front-loaded with the core action and resource, making it easy 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?

For a job-submission tool with no annotations, no output schema, and an effectively empty parameter schema, this description is too thin. It does not mention what the return value is, whether results are fetched via media.job.status, or what constraints apply to clips and outputPath. An agent would need additional documentation 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?

The input schema provides only the required names clips and outputPath with no property descriptions, so the description's mention of 'FFmpeg composition/render' adds useful context for inferring their meaning. However, additionalProperties is true, and the description does not explain accepted formats, required clip structure, or output path conventions, leaving substantial ambiguity.

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 identifies a specific action ('Submit') and a specific resource ('an FFmpeg composition/render job'), so an agent knows this tool is about launching rendering work. It does not explicitly distinguish itself from related tools like media.video.generate or media.job.run_once, but the phrase 'FFmpeg composition/render job' provides reasonable specificity.

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 guidance on when to use this tool instead of siblings such as media.video.generate, media.job.run_once, or media.director.review. There is no mention of prerequisites, queuing semantics, or which workflow step it belongs to, so an agent must infer usage from the name and context.

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, but it only says the QA is 'deterministic.' It does not disclose whether the operation is read-only, whether it creates background jobs, mutates project state, or requires prior generation. This is a significant gap for a review action.

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 focused sentence with no filler. 'Deterministic' adds meaningful nuance, and the core action is front-loaded. It could be slightly more informative, but as conciseness goes, it is well structured.

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 no annotations, so the description must explain what happens when the tool is called. It does not clarify whether results are returned directly, whether a job is spawned, what project state is required, or what side effects occur. An agent can guess the intent but not the operational behavior.

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 lists required projectId but defines no properties, and context reports 100% schema coverage, so the baseline is 3. The description adds no parameter-level meaning beyond implying the project to review, which is fairly self-evident from the parameter name.

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 ('Run') and resource ('deterministic continuity/shot QA'), making the tool's purpose clear and distinct from generation, status, or flow tools. It does not explicitly contrast with a sibling, but the operation is well identified.

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 like media.video.generate, media.job.status, or media.flow.handoff. The phrase implies a post-production QA step, but prerequisites and when-not-to-use conditions are absent.

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

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

No annotations are provided, so the description carries the full burden of explaining behavior. It says only that the tool 'prepares' a package, without disclosing side effects, whether files or records are created, whether permissions are needed, or what the caller should expect afterward. This is slightly more than a tautology but still far from transparent.

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 short, but brevity here results from omission rather than efficient writing. The vague qualifier 'optional' and the unexplained term 'handoff package' create ambiguity that more detail would resolve, so the description is under-specified rather than appropriately concise.

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 annotations and no output schema, the description is the only source of context, and it is not enough. It omits the meaning of projectId, the shape or destination of the handoff package, the expected return value, and the relationship to sibling tools, leaving the agent to guess at nearly every operational 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?

The input schema requires projectId but does not define it under properties, and additionalProperties=true leaves the parameter surface open. The description adds no information about what projectId refers to, why it is required, or what optional parameters might be accepted, so an agent cannot confidently construct a valid invocation.

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 identifies a specific action ('Prepare') and a resource ('Google Flow handoff package'), but it does not explain what a handoff package contains or what 'optional' means. It also does not distinguish this tool from the many media.* siblings, leaving the agent to guess how it fits into the workflow.

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 guidance about when to call this tool, when not to call it, or which sibling tool should be used instead. The word 'optional' hints that the step is not always required, but it does not state what conditions make it necessary.

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 reveals that the operation is a job submission and that the job is durable, but it does not disclose whether a job ID is returned, how to check status, failure modes, permissions, or side effects.

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

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

The description is a single tight sentence with no filler, which is efficient. However, it is under-specified rather than appropriately sized, given the ambiguous schema and lack of behavioral 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?

With no annotations, no output schema, and a nearly empty parameter schema, the single sentence is insufficient. An agent cannot tell what the submit call returns, how to track the resulting job, or what parameters are expected beyond the bare name 'prompt'.

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 declares a required 'prompt' but leaves properties empty and allows additional properties, so the parameter's type and format are essentially undocumented. The description never explains what the prompt should contain or what additional options are accepted, leaving the agent to guess.

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 ('Submit') and resource ('a durable image-generation job'), making the tool's core purpose clear. It is naturally distinguished from siblings like media.video.generate or media.subtitle.generate by the image focus, though the term 'durable' is unexplained jargon.

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 about when to use this tool versus alternatives such as media.video.generate, media.compose, or the job-related siblings. 'Durable' hints at asynchronous usage, but no explicit conditions, alternatives, or exclusions are provided.

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 of disclosing behavior, but it only restates the intent. It does not mention whether cancellation is immediate, asynchronous, irreversible, or what happens to a job that is already running or completed.

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 no filler words. However, it is so minimal that conciseness is achieved at the expense of useful detail.

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

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

For a destructive operation with no annotations and no output schema, the description is severely incomplete. It fails to explain the durable job lifecycle, side effects, jobId source, or error behavior, leaving an agent without enough context to invoke the tool safely.

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 requires jobId but does not define it in properties, and the description adds no parameter meaning. An agent cannot determine the expected type or source of jobId from either the schema or the 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?

The description states a specific action ('Cancel') and a specific resource ('a durable job'), which distinguishes it from sibling tools like job.status, job.list, and job.run_once. It is clear about what the tool does, though the term 'durable job' is not defined.

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?

No guidance is provided about when to use this tool versus alternatives, when cancellation is allowed, or what state the job must be in. The description simply states the action without contextual routing or exclusions.

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 of behavioral disclosure. It states only that it lists durable jobs, omitting details such as whether results are paginated, what fields are returned, whether only active jobs are included, or that the operation is read-only.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise, though it sacrifices potentially valuable context that could be included without much bloat.

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 no output schema and no annotations, the description is too thin. 'Durable jobs' is undefined, and there is no indication of return shape, filtering, or how this listing relates to the other job-management tools. An agent may struggle to know what invoking this actually returns.

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 schema already fully describes the input surface (none). The description adds nothing beyond the schema, but there is nothing to add; the baseline of 4 for zero-parameter tools 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 ('List') and a resource ('durable jobs'), making the core operation clear. It is implicitly distinct from sibling tools like status, cancel, and run_once, though it does not explicitly differentiate itself or define what 'durable' means.

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 media.job.status or media.job.run_once. The tool name suggests listing, but the description provides no context about appropriate use cases or exclusions.

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 behavioral disclosure. It does add the useful non-blocking trait, but it fails to disclose return values, error behavior, side effects, idempotency, or whether repeated calls are safe. This is a meaningful gap for a state-advancing operation.

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 focused sentence that front-loads the action and scope. Every word earns its place and there is no redundant phrasing.

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 job-advancing tool with no annotations, no output schema, an underspecified input schema, and a close sibling media.job.tick, the description is too terse. It does not explain what a step produces, how a durable job progresses, or what response the agent should expect.

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 oddly declares jobId as required but defines no properties, so the schema itself gives almost no parameter semantics. The description does not mention jobId, its format, or how to identify the job, so the agent is left to infer from the tool name and the word 'job'.

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 ('Advance') and resource ('one durable job') with explicit scope ('by one non-blocking step'). It is clear about what the tool does, but it does not differentiate itself from the similar sibling media.job.tick, so it misses the highest level of clarity.

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 about when to use run_once versus alternatives such as media.job.tick or media.job.status. The only hint is the action itself, which gives implied use rather than explicit selection criteria or exclusions.

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 word 'read' indicates a non-mutating operation, and 'durable' hints that job state is persisted. However, with no annotations, the description carries the full burden of behavioral disclosure and does not explain return shape, error behavior, or whether status is pollable or one-shot.

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 extremely concise, front-loaded, and contains no filler or redundancy. Every word ('read', 'durable', 'job', 'status') contributes to the core meaning.

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 no annotations and no output schema, this description is too thin. It lacks context about where a jobId comes from, what status values may be returned, how to interpret 'durable', and how this relates to sibling tools like media.job.list or media.provider.status.

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 reported as high, so the baseline is 3 even though the description adds no parameter details. The required 'jobId' is fairly self-explanatory, but the description does not clarify how to supply it or that it refers to a previously created job.

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 ('read') and resource ('durable job status'), clearly indicating this tool retrieves job status. It is understandable on its own, though it does not explicitly distinguish itself from siblings like media.job.list or media.provider.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 gives no guidance on when to use this tool versus alternatives. It does not mention siblings such as media.job.list, media.job.cancel, or media.provider.status, nor any exclusions or preconditions.

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 behavioral burden. It discloses the core action, but not side effects, idempotence, whether it mutates state, whether it affects all jobs globally, or what happens if no jobs are due.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and it is appropriately sized for the operation described.

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

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

The description is extremely terse and does not explain how 'due' is determined, what 'step' means, or how this fits with the other media.job.* tools. With no annotations and no output schema, the description leaves too much to inference for an agent to call it confidently.

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 and the schema is empty, so there is nothing for the description to add beyond the baseline. A score of 4 reflects the 0-parameter baseline with no semantic gaps.

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 ('Advance') and resource ('due jobs') with a clear scope ('by one step each'). It is distinguishable from media.job.run_once and media.job.status, though it does not explicitly differentiate itself from those 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?

There is no guidance about when to use this tool versus media.job.run_once, media.job.status, or media.job.cancel. The word 'due' implies a scheduling condition, but no explicit when-to-use or when-not-to-use context is provided.

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 burden of behavioral disclosure, but it only states the action without noting side effects, idempotency, permissions, or what a manifest creation entails. The wording is minimal and does not reveal behavioral traits beyond the obvious write operation.

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, tightly written sentence with no filler words. It is efficient, though perhaps too sparse to fully support tool invocation.

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 creation tool with no annotations, no output schema, and two unexplained required parameters, this description is insufficient. An agent cannot tell what a valid 'brief' looks like, what the response will be, or whether creating a manifest has side effects or prerequisites.

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 lists required fields 'name' and 'brief' but provides no property descriptions, and the description does not explain what these fields mean or how they should be formatted. The schema coverage signal is high only because the properties object is empty, so the description adds no meaningful parameter guidance.

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 ('Create') and names the resource ('a media project manifest'), which clearly distinguishes it from read-oriented siblings like media.project.list and media.project.get. The term 'manifest' is somewhat specialized and could be clearer, but the primary 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?

No guidance is provided about when to use this tool versus alternatives such as media.storyboard.plan or media.compose. There is no mention of prerequisites, exclusions, or conditions that would route an agent to this tool over 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?

Without annotations, the description carries the burden of behavioral disclosure. 'Read' clearly implies a non-mutating retrieval operation, which is important context. However, it does not describe what is returned, how failures are handled, or any access considerations, so transparency is only minimal.

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 focused sentence with no filler or redundant phrasing. It is concise and front-loaded, though it sacrifices useful detail by being so terse.

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

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

For a simple read operation, the core purpose is present and an agent can probably invoke it with projectId. But there is no output schema and no mention of the return value, projectId semantics, error behavior, or when to prefer list/get, leaving the definition minimally viable rather than complete.

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

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

The schema requires projectId but defines no properties, and the description never mentions projectId or how to identify which media project to read. Even though schema description coverage is reported high, that is only because the properties object is empty; the one meaningful required parameter is effectively 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 clear verb ('Read') and resource ('a media project'), so an agent can understand the basic operation. It could be more specific by mentioning retrieval by projectId, but 'a' plus 'read' loosely distinguishes it from media.project.create and media.project.list.

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?

No guidance is given about when to use this tool versus siblings like media.project.list or media.project.create. There is no statement of what kind of project lookup this is for, nor any exclusion or alternative routing. The agent must infer usage from the tool name and sibling set.

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, and the description only says 'List media projects,' which implies a read-only operation but adds no detail about pagination, ordering, result shape, permissions, or side effects. The description is not misleading but is behaviorally minimal.

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 terse sentence with no wasted words. It is appropriately sized for such a simple zero-parameter listing operation.

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 list tool, the description is minimally adequate, but with no output schema and no annotations, it provides no return-format context or broader discovery guidance. An agent can call it, but not know what shape the results take or how this listing relates to get/create.

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 and the schema coverage is trivially 100%, so the description has nothing meaningful to add. The additionalProperties: true flag is slightly ambiguous, but with no defined parameters, this is not a significant 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 verb, 'list', and a specific resource, 'media projects'. The plural 'projects' clearly differentiates it from sibling tools like media.project.get and media.project.create.

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 about when to use this tool versus alternatives. No conditions, exclusions, or sibling comparisons are provided, so an agent must infer when listing projects is appropriate.

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 behavioral transparency burden. 'Read' establishes a non-mutating operation, and 'without paid generation' clarifies that no costly generation side effect will occur. It does not detail return values or possible error modes, but for a zero-parameter status check the key behavioral traits are disclosed.

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 six-word sentence with no filler. It front-loads the core action ('Read provider readiness') and appends the cost-relevant qualifier ('without paid generation'), making every word purposeful.

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 zero-parameter read-only status tool, the description is largely complete: it says what the tool reads and that it does not trigger paid generation. However, because there is no output schema and no annotation support, the description could more explicitly describe what the returned readiness data looks like (e.g., per-provider states, booleans, or error conditions).

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 there is no parameter surface to document. The schema coverage is effectively complete, and the description adds no parameter-specific meaning because none is needed.

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 verb ('Read') and resource ('provider readiness'), and the qualifier 'without paid generation' distinguishes it from the generation-focused sibling tools. It is immediately apparent what this tool does and how it differs from media.image.generate, media.video.generate, and media.job.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?

'Without paid generation' implies this tool is a safe pre-generation check that does not incur costs, but it does not explicitly say when to use it versus alternatives, nor does it name any sibling tools. The usage context is implied rather than explicit.

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

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

There are no annotations, so the description must convey side effects or constraints. It only states a planning action, giving no indication of whether this creates resources, modifies project state, or is read-only. The lack of any behavioral disclosure leaves the agent guessing about consequences.

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, concise sentence with no redundant words. It efficiently communicates the core action and a key constraint (shot duration), earning high marks for brevity and clarity.

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 sparse schema (empty properties) and lack of annotations, the description does not provide enough context for an agent to use the tool correctly. It omits parameter meanings, output format, and any relationship to other tools, making it incomplete for practical 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 input schema lists required fields (projectId, totalDurationSec) but the properties object is empty, so no parameter descriptions exist. The description does not mention these parameters or explain their purpose, leaving the agent without any semantic understanding of how to fill them.

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 purpose: planning a multi-shot storyboard with a specific shot duration limit. This is specific enough to distinguish it from generic 'plan' tools, though it lacks detail on the output and how the storyboard is structured.

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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or relationships with sibling tools like media.compose or media.video.generate. The agent receives no context for selecting this tool.

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 must carry the full burden of behavioral disclosure. Beyond saying an SRT sidecar is generated, it does not state whether this is a mutating operation, whether it overwrites an existing subtitle file, whether it triggers an asynchronous job, or what the output/return behavior is. Given the rich sibling job tools (media.job.status, media.job.run_once), a generated artifact might be async, and this is 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?

One information-dense sentence with no filler. It front-loads the main action and artifact while adding the source constraint at the end. 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?

With no output schema, no annotations, and a loose input schema (required projectId only plus additionalProperties true), the one-liner is not complete enough. An agent is left unsure whether the tool returns the SRT content directly, writes a file, or enqueues a job, and it does not know how to provide or expect the 'storyboard dialogue' input.

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 reported as 100%, so the baseline is 3 even without explicit parameter details. The description adds a little context by naming 'storyboard dialogue' as the source, but it does not explain the required projectId or the meaning of additional allowed properties. The parameter semantics are therefore acceptable but not enriched.

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 ('Generate'), a concrete resource ('SRT sidecar'), and a clear source ('storyboard dialogue'). It is immediately distinguishable from sibling generation tools like media.image.generate or media.video.generate because none of them claim subtitle creation.

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 phrase 'from storyboard dialogue' implies the tool should be used when the user wants subtitles derived from a storyboard, but the description never explicitly frames when to use it or when not to. It also does not mention any alternative tools or prerequisites such as an existing storyboard or plan.

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 the call is asynchronous ('return immediately with a job id') and that jobs are durable, which is valuable. It does not describe failure behavior, cost, retention, or how to track the job afterward, leaving some behavioral ambiguity.

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

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

The description is a single, front-loaded sentence with no filler. It conveys the core action, the async behavior, and the return value efficiently.

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 job-submission tool, the description gives the essential async contract but misses the prompt parameter semantics and any mention that job progress/results should be checked via a sibling tool like media.job.status. With no output schema and no annotations, it is minimally useful but not fully self-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?

The schema marks 'prompt' as required but leaves properties empty, and the description does not mention the prompt or explain its format. The agent is left to guess what a prompt should contain and whether additional parameters are accepted or expected. This is a significant gap for the only required parameter.

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 (submit a durable video-generation job) and the immediate result (a job id), making the tool's main purpose obvious. However, it does not explicitly distinguish itself from siblings like media.video.regenerate or media.image.generate; the distinction is only implicit in the name and phrasing.

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 about when to use this tool versus alternatives such as media.video.regenerate or media.image.generate. The phrase 'durable' hints at background processing, but no explicit context, prerequisites, or exclusions are provided.

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 provided, the description carries the full burden of behavioral disclosure. It only says 'Create a replacement video job' but does not explain whether this replaces an existing job, creates a new job, cancels prior work, is asynchronous, or requires previous generation results. The actual side effects are unknown.

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 concise sentence with no redundant wording. It is front-loaded and easy to parse, though the brevity leaves key details unaddressed.

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 no annotations, so the description must explain the operation's inputs, effects, and return expectations. It does not mention what 'replacement video job' means, what 'one shot' refers to, or what happens after creation. The tool is likely useful only with external context not present in 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?

The schema requires 'jobId' but does not define it in properties, and the description never mentions it. The phrase 'for one shot' hints at the target, but the description adds no meaning for the required parameter. The context signal showing 0 parameters conflicts with the required parameter, making clarification even more necessary.

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 clear action and resource: 'Create a replacement video job for one shot.' This is specific enough to distinguish the tool from media.video.generate, though 'one shot' is slightly ambiguous without more context about what a shot is.

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?

No explicit guidance is given about when to use this tool versus media.video.generate, media.job.run_once, or other job-related tools. 'Replacement' implies a redo scenario, but the conditions, prerequisites, or failure cases that should trigger this tool are not described.

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