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

The readOnlyHint annotation already declares the operation safe, and the description adds value by explaining the behavior as a credential/account lookup and a preflight check for expected account/endpoint. It does not overpromise side effects or contradict annotations.

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

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

Two compact sentences with no filler: the first states exactly what is returned, and the second explains when to call it. The information is front-loaded and every clause earns its place.

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

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

For a zero-parameter, annotation-covered, output-schema-backed info tool, the description fully equips an agent to decide when to call it and what to expect. Nothing important is missing.

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

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

With zero parameters, there is no parameter semantics burden on the description. The empty schema provides complete coverage, so the baseline of 4 applies.

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

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

Description states a specific verb ('Return') and a specific resource (the Move API client/account) with scope tied to the current credential. This clearly distinguishes it from siblings like move_update_client, which modifies client settings, and from data-list tools.

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

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

Explicitly directs the agent to 'Use this first' as an authentication/endpoint confirmation before other calls. It gives a clear context of use but does not name alternatives or explicit when-not cases, which are less relevant for a zero-parameter info 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?

The description reveals a key behavioral trait beyond the annotations: this tool does not upload content itself; it returns a presigned PUT URL for a later upload. It does not mention URL expiration or what happens to an unused reservation, but annotations already cover read-only, idempotency, and destructiveness.

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, front-loaded with the core behavior, and uses a single additional sentence for routing guidance. Every sentence adds value, and there is no redundant restating of the tool name or schema fields.

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

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

With output schema present and annotations provided, the description covers the important workflow and distinguishes the tool from its sibling. The main gap is the unexplained optional parameters, but they are not required for a valid call and the core behavior is sufficiently clear.

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

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

Schema description coverage is only 33%, and the description does not compensate by explaining the name or metadata parameters. Only file_type is documented, in the schema. An agent needing to understand optional parameters like name or metadata receives no guidance from 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: reserve a file slot and obtain a presigned PUT URL for uploading bytes. It clearly distinguishes this from the one-step alternative, move_upload_file, so the agent knows exactly what this tool does and how it differs.

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

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

The description explicitly tells the agent to prefer move_upload_file when the video is on the local machine, which implies move_create_file is for cases where the file is not local or a separate upload step is needed. This is direct, actionable routing guidance with a named alternative.

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 description adds an important behavioral detail beyond the annotations: 'This consumes processing credits.' This warns the agent about a real side effect and cost not captured by readOnlyHint, idempotentHint, or destructiveHint. While it doesn't detail all side effects, this is a meaningful disclosure for a state-changing job-creation 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 two short sentences with no filler. The primary purpose is front-loaded, and the additional credit-consumption warning earns its place. This is a model of concise, structured writing.

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

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

For a tool with 8 parameters and important job-creation semantics, the description is too thin. It omits prerequisites, default output behavior, clip window options, and asynchronous job lifecycle context. The output schema and annotations help, but they do not fill the gaps left by the sparse 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 low at 38%, so the description carries responsibility for explaining parameters, but it does not mention take_id, options, outputs, clip_window, or number_of_actors. The only parameter-related context is implicit in 'multi-camera mocap job.' The description adds no semantic value beyond the schema and fails to compensate for the coverage 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 clearly states the action: 'Start a multi-camera mocap job.' It uses a specific verb and resource, and the phrase 'multi-camera' distinguishes this from the sibling single-camera job tool. This goes beyond a tautology and gives an agent a clear understanding of the tool's core function.

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

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

The description provides no guidance about when to choose this tool over alternatives like move_create_single_cam_job or move_update_job. It lacks explicit conditions, exclusions, or references to sibling tools. The intended use is only implied by the tool name and the generic 'Start a...' phrasing.

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

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

Annotations already carry the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description only needs to add context beyond them. It adds the dependency on an existing calibration volume, which is genuine behavioral context. However, it does not disclose consequences such as repeated calls creating duplicate takes or any downstream processing triggered by creation. The added context is real but 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?

A single eleven-word sentence that front-loads the verb and resource, with zero filler. It is efficient, though terse enough that it leans on the schema for 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?

An output schema exists and safety-relevant annotations are present, so return values and mutability do not need explanation. Given the moderate complexity (nested $defs for Source, SyncMethod, and ClipWindow, plus a cross-tool dependency on volume creation), the one-line description covers the core prerequisite but omits guidance on the single-camera alternative and the volume-finished workflow. Acceptable but with clear gaps.

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

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

The description adds no parameter-level meaning; 'existing calibration volume' loosely maps to volume_id, which the schema already documents thoroughly ('Id of a FINISHED volume from move_create_volume_with_human'). With 50% schema coverage, the critical parameters (volume_id, sources, sync_method) carry rich schema descriptions, and the undocumented ones (name, expand, metadata) are low-risk and self-explanatory from their titles. The description neither compensates for nor worsens the coverage 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 (Create), a specific resource (multi-camera take), and a distinguishing constraint (against an existing calibration volume). The 'multi-camera' qualifier clearly differentiates it from the sibling move_create_single_cam_take, and the 'take' resource separates it from the job-creation tools. This is substantive, not a tautology.

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 constraint 'against an existing calibration volume' implies the primary prerequisite and therefore when the tool is applicable, and the schema reinforces this by requiring a FINISHED volume from move_create_volume_with_human. However, the description never explicitly states when to prefer this over move_create_single_cam_take, nor how it relates to move_create_multi_cam_job. Usage context is implied rather than stated.

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

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

Annotations already indicate a non-read-only, non-idempotent operation, so the description adds value by disclosing that the operation 'consumes processing credits.' This is a material side effect beyond the annotations. However, it does not mention other behaviors like asynchronous job execution or that repeated calls could create duplicate jobs.

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 short sentences with no filler. The action is front-loaded and the cost warning is a useful second sentence. Every part earns its place.

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

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

For a job-creation tool with 7 parameters and side effects, the description is minimally viable but has gaps. It does not mention that the take must already exist, that job progress can be checked via move_get_job, or how to choose between single-camera and multi-camera jobs. The output schema may cover return values, but usage context is still thin.

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 provides no parameter-level guidance and the schema coverage is only 43%, so the description was expected to compensate but does not. It does not explain take_id, options, outputs, clip_window, or how defaults behave, even though some of this is partially present in the schema.

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

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

The description uses a specific verb ('Start') with a clear resource ('a single-camera mocap job'), and the 'single-camera' qualifier distinguishes it from move_create_multi_cam_job. It also adds a meaningful consequence ('This consumes processing credits') without muddying the core purpose.

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

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

The description implies this is for starting a single-camera mocap job, which helps separate it from the multi-camera sibling, but it does not explicitly say when to use it versus alternatives. It also omits prerequisites such as the need for an existing take or how this relates to move_get_job or move_update_job.

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

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

Annotations already signal a mutating, non-idempotent create operation, and the description aligns by saying 'Create'. It adds a useful constraint that files must already be uploaded, but it does not disclose additional side effects or failure modes. No contradiction with annotations.

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

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

The description is one concise sentence, front-loaded with the action and object, with no filler or redundant restatement of the tool name. 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?

The description is minimally sufficient for tool selection and basic invocation, and the schema supplies the nested Source/CameraSettings details. However, it leaves optional-parameter semantics and the distinction from job/multi-cam workflows to be inferred, so it is not fully complete for a tool of this complexity.

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

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

Schema description coverage is only 25%, so the description should compensate for the undocumented name, expand, and metadata parameters, but it does not. 'Already-uploaded files' only lightly reinforces the file_id provenance already described in the Source schema.

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

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

The description uses a specific verb ('Create'), identifies the exact resource ('single-camera take'), and specifies the source precondition ('already-uploaded files'). This clearly distinguishes it from siblings like move_create_multi_cam_take and move_create_single_cam_job.

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 already-uploaded files' implies the tool should be called after files have been uploaded, but it does not explicitly name alternatives or state when not to use it, such as for multi-camera takes or job creation. Usage routing is therefore 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?

Beyond the annotations, the description discloses that this operation consumes processing credits and is asynchronous, requiring polling of move_get_volume. This adds meaningful behavioral context about cost and expected follow-up that annotations do not convey.

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

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

The description is compact and front-loads the core purpose in the first sentence. Every subsequent sentence adds critical workflow information: credit consumption, polling, and the required follow-up take creation. No filler.

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

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

For an 8-parameter tool with an output schema, the description sufficiently orients the agent: it explains the async lifecycle, cost implication, and how this step connects to the multicam workflow. It could mention sync_method or area_type constraints, but those are already documented in the schema.

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

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

The description adds little parameter-level detail, but the schema already documents key parameters like human_height, sources, camera_settings, area_type, and sync_method. It reinforces that device_labels and lenses must stay consistent, which helps across the workflow, but leaves some params like name, expand, metadata, and clip_window to the schema alone.

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: 'Calibrate a multicam setup from footage of a person of known height.' It also identifies the tool as step one of the multicam workflow, which clearly separates it from sibling tools like move_create_multi_cam_take.

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

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

The description gives clear workflow context: use this first, then poll move_get_volume until FINISHED, then create a multicam take with matching device_labels and lenses. It does not explicitly mention alternatives or when not to use it, but the sequential guidance is strong enough to route an 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?

The description adds no behavioral detail beyond the annotations. It does not state whether server-side files are modified, whether local files are overwritten by default, whether authentication is required, or any side effects. The annotations declare idempotentHint and destructiveHint, but the description itself contributes little behavioral transparency.

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 appropriately concise, though it sacrifices 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?

The tool is simple, but the description leaves important gaps: no usage guidance versus move_download_job_outputs, no parameter semantics for two of three parameters, and no behavior around overwrite or local file handling. The output schema exists, so return values are not required, but the remaining ambiguity is significant.

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

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

Schema description coverage is only 33%, and the description does not compensate. file_id and overwrite have no descriptions in the schema and are not explained in the tool description. Only dest_path is clarified, and that is already done in the schema.

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

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

The description clearly states the action ('Download'), the object ('a Move file'), and the destination ('to this machine'). It is specific enough to distinguish from upload and create tools, though it does not explicitly differentiate among related download/get siblings such as move_download_job_outputs.

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 on when to use this tool versus alternatives. The phrase 'typically a job output' creates ambiguity because a dedicated move_download_job_outputs sibling exists, but the description does not say when to choose one over the other.

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

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

Annotations already indicate idempotency and non-destructiveness. The description adds useful context by saying outputs are written 'to this machine' and only for finished jobs, but it does not disclose behavior around overwrite conflicts, partial failures, or whether the download preserves directory structure. It 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?

A single sentence that starts with the verb, front-loads the key distinction ('FINISHED'), and includes only necessary qualifiers. Every word contributes meaningful guidance without unnecessary elaboration.

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 output schema exists, return values need not be described. The description plus schema covers the key usage conditions: finished job, all outputs by default, optional key filtering, and destination directory. It falls slightly short only because failure conditions and overwrite semantics are left implicit.

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 helps clarify job_id by saying the job must be finished and clarifies the default scope as 'every output file.' The schema already documents keys and dest_dir. However, overwrite has no description in the schema, and the description does not compensate for that gap.

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

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

The description names a specific verb ('Download'), a clear resource ('every output file of a FINISHED job'), and a destination ('to this machine'). This makes the tool's function immediately apparent and distinguishes it from siblings like move_get_file or move_download_file, which target individual files rather than job outputs.

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 clearly states that the job must be FINISHED, providing a concrete precondition for use. It implies that this tool is for batch-downloading all job outputs rather than individual files, though it does not explicitly name alternatives or say when not to use it.

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

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

Annotations indicate readOnlyHint=false and openWorldHint=true, implying potential side effects, but the description does not disclose what happens when a share code is generated (e.g., persistence, expiry, access implications). It adds little beyond the annotations already convey.

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

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

The description is a single, front-loaded sentence with no wasted words. It communicates the core action and target resource 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 simple one-parameter tool with an output schema, the description is mostly sufficient for basic invocation. However, it lacks usage guidance and behavioral transparency, so an agent may not understand side effects or when to prefer this over sibling tools.

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 has one parameter (file_id) with no description, and schema description coverage is 0%. The description adds some meaning by clarifying the file_id refers to a 'job output file', but it does not explain format, constraints, or how to obtain the value.

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 ('Generate') and a specific resource ('a shareable code and URL for a job output file'). It clearly distinguishes this tool from siblings like move_get_file or move_download_job_outputs by focusing on creating a share artifact.

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 guidance on when to use this tool versus alternatives, nor any mention of prerequisites or conditions. The phrase 'for a job output file' is context but does not help the agent decide between this and other file-related tools.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context by explaining that input files receive a PUT upload URL and job output files receive a time-limited download URL, which goes beyond the annotation hints.

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 very concise, front-loads the main purpose in the first sentence, and adds only the necessary distinction between input and output file URL behavior. Every sentence 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?

Given the single required parameter, the readOnly annotation, and the presence of an output schema, the description covers the key nuance about presigned URL types. It could be slightly more complete by mentioning expiration or explicitly pointing to upload/download siblings, but overall it is sufficient for correct usage in most contexts.

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%, but the description adds no specific meaning for the file_id parameter. Although file_id is self-explanatory, the description does not compensate for the low coverage, nor does it clarify how the ID is used or where it comes from.

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 fetches a file and returns a fresh presigned URL, which distinguishes it from a direct content download. However, it does not explicitly name or contrast sibling tools like move_download_file or move_upload_file, so the differentiation is functional but not explicit.

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 explains the behavior of the presigned URL for input files versus job output files, implying this tool is for obtaining a presigned URL rather than transferring content directly. It does not explicitly state when to use this tool instead of move_download_file or move_upload_file, leaving the choice somewhat inferred.

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

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

Beyond the readOnlyHint annotation, the description discloses the asynchronous behavior, the specific lifecycle states, and typical processing duration. This materially helps the agent understand what to expect and that polling is appropriate, with no contradiction against annotations.

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

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

The description is compact and front-loaded, with each sentence adding useful information: the core action, the returned state fields, and the polling behavior. No redundant or filler content is present.

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

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

For a read-only polling tool with an output schema, the description is complete: it covers the resource, the key returned aspects, the states, and the correct calling pattern. The expand parameter's behavior is already documented in the schema, so no further return-value explanation is needed.

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

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

Schema description coverage is only 50%: expand is documented, but job_id only has a title and no meaningful schema description. The tool description does not compensate by explaining job_id's role or format, even though 'Fetch a job' implies it identifies the 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 and resource ('Fetch a job') and adds the distinctive focus on state and percentage progress. It is clear and not a tautology, but it does not explicitly differentiate from sibling tools like move_list_jobs or mention that it operates on a single job_id.

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 explicit guidance to poll instead of blocking and sets expectations that processing takes minutes, which tells the agent when to call it. It does not name alternatives or exclusion conditions, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true, and the description does not contradict that. It adds little behavioral detail beyond the purpose, such as response shape, error cases, or expand behavior, though an output schema is present and the operation is simple.

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 to identifying the operation and target resource.

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 tool with an output schema, read-only annotations, and a self-explanatory required take_id parameter, the description is mostly sufficient. It does not explicitly route the agent away from list/update siblings, but the operation is simple enough that an agent can call it correctly with the provided schema and annotations.

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 50%: the expand parameter is well documented, while take_id has no schema description. The phrase 'by id' lightly reinforces take_id's role, but the description does not add new meaning to either parameter beyond what the schema provides.

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

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

The description 'Fetch a take by id' uses a specific verb and resource, clearly identifying a single-take read operation. The 'by id' qualifier distinguishes it from sibling list/update tools without requiring schema inspection.

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

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

The description implies this tool is for retrieving one take when its id is known, but it does not explicitly contrast it with alternatives like move_list_takes for browsing or move_update_take for modifications. Usage context is present but exclusion conditions are not stated.

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

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

Annotations already mark the operation read-only and open-world; the description adds useful domain context about volume lifecycle and the FINISHED state requirement. There is no contradiction between the description and the annotations.

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

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

Two sentences, with the core fetch action first and the state prerequisite second. Every word earns its place, and the description is short enough for an agent to ingest 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 simple read operation with an output schema and readOnly/openWorld annotations, the description is nearly complete: it names the resource, the returned state, and the business prerequisite. It could add an explicit note about expand behavior or error cases, but those are secondary given the schema and annotations.

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 does not explain the expand parameter, but the schema already documents it with an enum and default. 'Fetch a calibration volume' maps naturally to the required volume_id and adds the 'calibration' semantic, partially compensating for the low schema coverage.

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

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

The description opens with the specific action 'Fetch a calibration volume and its processing state,' clearly identifying the resource and what is returned. It does not explicitly contrast with the sibling list_volumes tool, so it misses the top score but remains 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?

The second sentence gives concrete context: a volume must be FINISHED before it can back a multicam take, implying this tool is used to check that readiness. It does not name alternative tools or explicitly say when not to use it, but the usage context is clear.

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

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

Annotations already carry readOnlyHint=false and destructiveHint=false; the description adds useful context that mutations are allowed only if writes are enabled and that the accepted document is arbitrary. This goes beyond the annotation flags without contradicting them.

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

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

The description is short, front-loaded with purpose, and followed by routing and a precondition. The schema reference is a single line and useful; no sentence 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 generic GraphQL runner, the description includes routing, mutation gating, and a schema reference link. An output schema exists, so return-value documentation is not needed; a small gap is not spelling out the broader side-effect implications of arbitrary mutations, but annotations cover the destructive profile.

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

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

Schema description coverage is 100%, so the parameters are fully documented in the schema. The description adds no additional meaning about the query or variables format; the schema's note about AWSJSON arguments already covers the subtle part.

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 opening line 'Run an arbitrary GraphQL document against the Move API' names a specific verb, resource, and scope, making the tool's function immediately clear. It also distinguishes itself from the typed siblings by stating 'this is for fields they do not expose.'

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 explicit routing guidance: 'Use the typed tools first; this is for fields they do not expose.' It also adds a precondition for mutations ('writes to be enabled'), so an agent knows not only when to call it but what must be true before doing so.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful scoping that results are supported lens ids for a specific field and explains the consequence of not declaring them correctly, but it does not disclose return format, ordering, or other behavioral details. With annotations present, 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 two short sentences with no filler. The primary purpose is front-loaded, and the second sentence provides a meaningful reason for the tool's existence without redundancy.

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

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

For a zero-parameter, read-only list tool with an output schema present, the description is complete. It names the exact field the ids belong to and explains why the lookup matters. Nothing essential is missing.

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

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

The tool has zero parameters, so there is no parameter semantics to document. The description still adds contextual meaning by tying the list to `Source.camera_settings.lens`, which is enough for a parameter-less tool.

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

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

The description states a specific verb and resource: 'List supported camera lens ids' scoped to `Source.camera_settings.lens`. This clearly distinguishes it from sibling list tools such as move_list_takes, move_list_jobs, and move_list_volumes.

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

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

The description provides clear context by explaining that 'Multicam accuracy depends on declaring the lens each camera used,' which implies the tool should be used when configuring camera lens settings. It does not explicitly name alternatives or exclusions, but no direct alternative exists among the 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?

Annotations already declare readOnlyHint and openWorldHint. The description's extra claim about filtering to one take duplicates the schema description of take_id, and it does not disclose pagination, expansion, or sorting behavior. No contradictions, but no meaningful additional behavioral context.

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 the verb and object front-loaded. It contains no filler, though it is probably too terse to cover the tool's parameter-dependent behavior.

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?

Despite having five optional parameters and an output schema, the description only covers the basic list action and take filter. It omits pagination, expand options, and sorting, and does not reference the output schema or open-world behavior, leaving the agent to infer important context from elsewhere.

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

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

Schema description coverage is only 40%, so the description needed to explain first, expand, and sort_direction, but it only restates the take_id filter already documented in the schema. It adds no new meaning for the majority of 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?

The description clearly states the action ('List') and resource ('jobs'), and adds a scoping condition ('optionally filtered to one take'). This distinguishes it from sibling move_get_job (single job fetch) and move_list_takes (different resource).

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 prefer this tool over alternatives such as move_get_job or move_list_takes. It implies usage only by naming the list operation, but does not state exclusions or conditions.

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

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

Annotations already declare readOnlyHint and openWorldHint, and the description is consistent with them. It adds useful account-scoping context, but it does not disclose additional behavioral details such as permissions, limits, or result characteristics; the output schema covers the return structure.

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 sentence with no filler. It is front-loaded with the action and resource, and every word contributes to the 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 zero-parameter read-only list tool with an output schema and annotations, this description is fully adequate. An agent knows exactly what resource is listed and the account scope.

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 no parameters and schema coverage is 100%, so the description carries no parameter documentation burden. Baseline 4 is appropriate for a zero-parameter tool.

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

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

States a specific verb ('List'), a specific resource ('skeleton rigs'), and a scope ('available to this account'). This resource is distinct from sibling list tools such as move_list_takes, move_list_jobs, and move_list_volumes.

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 is implied by the resource and scope, but the description does not explicitly state when to use this tool over alternatives or mention any exclusions. An agent can infer it should be used when account-available skeleton rigs are needed.

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

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

Annotations already state readOnlyHint=true and openWorldHint=true, so the read-only safety profile is covered. The description adds a modest behavioral detail about ordering based on sort_direction, but it does not disclose default ordering behavior, pagination characteristics, or expand semantics. No contradiction with annotations.

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

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

The description is a single concise sentence with no filler. It front-loads the core operation ('List takes') and adds an important ordering qualifier, though it is terse enough that some behavioral and parameter details are left to the schema.

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

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

The schema covers the cursor parameter and sort direction, and an output schema exists, so an agent can infer how to invoke the tool. However, the description is thin on usage guidance and leaves first/expand semantics undocumented both in the schema and description, making the overall package adequate but not 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?

Schema description coverage is only 50%, with first and expand lacking descriptions in the schema. The tool description mentions sort_direction but does not compensate for the undocumented parameters. The 'after' cursor is documented in the schema, but the description adds no semantic value for the remaining 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?

The description names a specific verb and resource ('List takes') and adds an ordering behavior ('newest first when sort_direction=DESC'). It is clear enough to distinguish from move_get_take, which is singular and focused on one take, though it does not explicitly call out that distinction.

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 alternatives such as move_get_take for a single take or move_create_take for creating a take. The only implied usage is the verb 'List', with no explicit when-to-use or when-not-to-use 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?

Annotations already declare readOnlyHint and openWorldHint, so the description's main job is to add domain context beyond those signals. It adds the scoping qualifier 'calibration volumes', but it does not disclose pagination behavior, expansion options, or other operational traits beyond what the annotations already imply.

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 very concise and front-loaded, with no wasted words. However, it provides only the minimum viable information and lacks useful operational context expected from a paginated list 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?

Even though an output schema and annotations are present, the description omits the relationship to sibling volume tools, the intended meaning of 'calibration volumes', and any guidance on pagination or expansion. For a tool with four optional parameters, this is 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 only 25%, with 'after' being the only parameter described in the schema. The description provides no parameter-level meaning and does not compensate for the low coverage of first, expand, or sort_direction.

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 ('calibration volumes'), so an agent can tell that this is a read-only listing operation. It does not explicitly distinguish itself from move_get_volume or move_create_volume_with_human, 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?

There is no guidance about when to use this tool versus alternatives such as move_get_volume or move_create_volume_with_human. The intended usage must be inferred entirely from the tool name and the sparse description.

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 description says 'Replace', which conveys that the existing metadata object is entirely overwritten rather than merged. This adds meaningful behavioral context beyond the annotations, and the annotations already cover idempotency and non-destructiveness.

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 sentence, front-loaded with the operative verb, and contains no filler. It earns every word.

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 one-parameter update with an output schema and annotations covering safety, the description is nearly complete. It could add explicit notes about replacement semantics or field requirements, but 'Replace the metadata object stored on the client (account)' is sufficient for correct invocation.

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

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

The description identifies the single parameter as the metadata object stored on the client, which gives the bare object schema some meaning. However, schema coverage is 0% and the metadata object allows arbitrary properties, so the description doesn't compensate with key conventions, constraints, or examples.

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 ('Replace') and names the exact resource ('the metadata object stored on the client (account)'). It clearly distinguishes this from sibling tools like move_client_info and other move_update_* tools by target and action.

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 clearly identifies the client/account as the target and 'replace' as the operation. It doesn't explicitly mention when not to use it, but the sibling tool names make the alternative read/update paths obvious, and there is no competing client-update 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?

Annotations already convey that the operation is not read-only, is idempotent, and is not destructive. The description adds no behavioral context beyond that, such as whether metadata is merged or replaced, whether null values clear fields, or whether the operation can affect existing file data in unexpected ways.

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. The action and target are front-loaded, and the scope is stated directly as 'name and/or metadata'.

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 presence of an output schema and annotations partially compensates for the brief description. However, the lack of parameter-level detail and usage guidance leaves some gaps for an agent deciding how to construct a valid update call, though the required file_id is still structurally obvious from the schema.

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

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

With 0% schema description coverage, the description must compensate, but it only mentions 'name' and 'metadata' and omits 'file_id' entirely. It does not explain the meaning of null defaults, the structure of the metadata object, or the relationship between the 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?

The description uses the specific verb 'Update' with the resource 'file' and narrows the scope to name and/or metadata. This clearly distinguishes it from sibling tools like move_get_file, move_create_file, move_upload_file, and move_download_file.

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 context is implicitly clear: use this tool when an existing file's name or metadata needs to be modified. However, there is no explicit guidance about when to choose this over alternatives, nor any mention of preconditions like the file needing to already exist.

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

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

Annotations already convey read-only=false, idempotent=true, destructive=false. The description adds that the update is partial ('name and/or metadata'), but does not disclose side effects like whether metadata is merged or replaced, or how the expand parameter alters the response. No contradiction with annotations, but limited added behavioral context.

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

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

A single, front-loaded sentence with zero filler. Every word earns its place; it is concise while still stating resource and fields.

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

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

For a mutation tool with four parameters, no schema descriptions, and output schema present, the description covers only half the parameters. The missing expand semantics and lack of metadata-merge behavior are notable gaps, but annotations cover safety and the output schema covers return values, making it minimally adequate.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions name and metadata, but omits the required job_id and entirely omits the expand parameter, which controls response shape. An agent cannot understand the expand options from the description alone.

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 ('Update'), a specific resource ('a job'), and the exact fields involved ('name and/or metadata'). This differentiates it from sibling update tools (move_update_take, move_update_client, move_update_file) by resource, so an agent can select it unambiguously.

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?

Clear context: use when you need to rename a job or change its metadata. It does not explicitly name alternatives or when-not-to-use, but the job resource scope is enough to route selection among update_* siblings. Lacks explicit exclusions, so not a 5.

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

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

The description aligns with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) but adds no behavioral detail beyond them. It does not disclose partial-update semantics, whether metadata is merged or replaced, or any authorization or rate-limit considerations.

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 or redundant information. It is appropriately concise, though the brevity contributes to gaps in other dimensions.

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 four-parameter update tool with zero schema descriptions, the description is incomplete: it omits the purpose of the expand parameter and does not explain how metadata updates are applied. The output schema covers return values, but the description still leaves meaningful gaps for correct invocation.

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

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

With 0% schema description coverage, the description needed to compensate, but it only clarifies that 'name' and 'metadata' are updatable. The required take_id is left implicit, and the expand parameter is not explained at all, leaving the agent without enough information to use all parameters correctly.

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 names the action ('Update'), the resource ('a take'), and the specific fields ('name and/or metadata'). This differentiates it from sibling tools like move_get_take or move_create_single_cam_take, though it does not explicitly mention the expand parameter.

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 alternatives such as move_update_job or move_create_single_cam_take. There are no context signals, exclusions, or prerequisites described beyond the bare action.

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

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

Annotations already signal that this is not read-only, not idempotent, and not destructive. The description adds that the operation combines file creation and upload in one step and returns the file id. However, it does not disclose side effects such as duplicate file creation behavior, whether an existing file with the same name is replaced, or upload failure implications.

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

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

The description is two sentences with no filler. The primary action is front-loaded, and the return-value guidance is concise and directly actionable.

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 gives the core purpose, the required input concept, and the downstream use of the returned file id, with the output schema available to cover return details and annotations covering mutation behavior. It is not fully complete because the optional parameters are not explained and sibling-selection guidance is implicit rather than explicit, but the main call path is well covered.

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

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

Schema description coverage is only 50%, with `name` and `metadata` left undefined. The description does not compensate: it only says 'local video,' which largely restates the schema's local_path description, and offers no guidance on the optional parameters or acceptable metadata structure.

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 combined action: 'Create a Move file and upload a local video to it in one step.' This clearly identifies the tool's resource and behavior, and distinguishes it from siblings like move_create_file by emphasizing the one-step upload behavior. It also adds the return value context, making the tool's purpose unmistakable.

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

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

The description clearly frames the intended workflow: use this tool when you need to create a file and upload a local video, then use the returned file id as Source.file_id when creating a take or volume. It does not explicitly name alternatives such as move_create_file or state when not to use it, so it stops short of a 5, but the context is clear.

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

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

Annotations already declare idempotentHint=true and readOnlyHint=false, so the 'Create or update' wording aligns with these and adds only the explicit upsert concept. The description does not disclose additional behavioral traits such as side effects on existing subscriptions, credential handling, or failure modes. It does not contradict the annotations.

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

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

A single, grammatically simple sentence with the action and object front-loaded. Every word earns its place, and there is no redundant or vague 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?

The tool has six parameters, an output schema, and useful annotations, so the short description is not entirely responsible for context. Still, the description does not mention required parameters, the role of uid in updating, or the optional nature of events/secret. The schema partially fills these gaps, but the description itself is somewhat sparse for an upsert operation.

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 67%, with clear descriptions for uid, url, events, and secret. The description adds no parameter-level meaning, but the schema already handles most semantics. The two undocumented optional fields (metadata, description) are self-explanatory, so the lack of compensation in the description is acceptable.

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

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

The description states a specific verb ('Create or update'), a resource ('webhook endpoint'), and scope ('for this client'). It clearly captures the upsert functionality and, since no sibling tool targets webhooks, it effectively differentiates the tool from its siblings.

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

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

The intended usage is implied from the description: use it to create or update webhook endpoints. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention prerequisites or exclusions. There are no sibling webhook tools, so the ambiguity is lower, but guidance beyond the core function is absent.

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