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

The annotations already declare readOnlyHint, destructiveHint=false, idempotentHint=false, and openWorldHint, so the safety profile is fully covered by structured data. The description adds nothing beyond the title it repeats — no note on whether results are paginated, how 'currently running' is defined, or whether the set can change between calls (relevant given idempotentHint=false).

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 tight sentence with no filler, and the scoping phrase ('currently running') is front-loaded. It is efficient, though the brevity borders on under-specification rather than true concision.

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 parameterless read-only listing tool with no output schema, the agent still lacks the return shape (e.g. whether items carry job IDs usable with axcel_job_status or axcel_download_job) and any account/scope caveats. It is the minimum viable content for this complexity level, 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 tool takes zero parameters, so the schema-description baseline of 4 applies. There are no arguments whose meaning the description would need to disambiguate.

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 resource and scope ('jobs currently running on the Axcel account'), which tells an agent exactly what the call returns. It does not, however, distinguish itself from near-neighbours like axcel_job_status, axcel_history_list, or axcel_sequence_list, so sibling differentiation is left to inference.

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 when-to-use guidance and no alternatives named. An agent must guess that this is the polling/list counterpart to axcel_job_status for a single job, which is only weakly implied by the plural 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. 'This MCP never buys anything' adds a small amount of context about absence of purchase side effects, but largely restates the read-only hint without describing the returned price shape or freshness.

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

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

Two short sentences with no filler, and the scope statement ('read-only list of plans and prices') is front-loaded ahead of the caveat. 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?

For a zero-parameter, read-only listing tool with no output schema, saying it returns plans and prices is close to sufficient, and the safety annotations cover the rest. It stops short of describing what a plan record contains or whether results are cached, which would fully close the loop.

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 takes zero parameters, so the schema-carries-nothing baseline of 4 applies. The description correctly adds no parameter claims, and there are no undocumented inputs to compensate for.

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 resource (Axcel plans and prices), so an agent immediately knows what it returns. It does not name or contrast against any sibling, but none of the surrounding tools are billing-related, so the risk of confusion is low.

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?

'Read-only list of Axcel plans and prices' implies the usage context (checking pricing), but there is no explicit when-to-use or when-not-to-use guidance and no named alternative. The closing sentence hints at scope limits but is framed as a behavioral claim rather than a usage rule.

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 declare this is a non-read-only, non-destructive, non-idempotent operation, so the safety profile is partly covered. The description adds genuinely useful behavior beyond that: it normalises size/fps/audio, optionally trims the repeated first frame, applies crossfades, and depends on ffmpeg being available. It omits what happens to an existing output file, which is the main remaining gap.

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 dense sentence, front-loaded with the core operation and parenthetically carrying the behavioral detail. No filler, no repetition of the title, 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 7-parameter media mutation with no output schema, the description covers what the output is (one MP4), what gets normalised, the optional effects, and the ffmpeg prerequisite. It is close to complete, with only output-overwrite/error behavior left unstated.

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 71%, so the schema already documents clips, output, width, trimHead, and crossfade. The description reinforces the intent of trimHead ('repeated first frame') and crossfade but adds no format, default, or interaction detail beyond the schema; fps and height remain undocumented in both places.

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

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

States a specific verb and resource: 'Join clips into one MP4'. This is unambiguous and cannot be confused with siblings like axcel_extract_frame or axcel_generate_video. It stops short of a 5 because it never names or contrasts with an alternative tool, though none of the siblings overlap in 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?

Usage is only implied: the tool concatenates clips, and 'Needs ffmpeg' gives one prerequisite. There is no explicit when-to-use/when-not guidance, no mention of when to prefer it over generating a single video, and no stated constraints on input homogeneity beyond normalisation.

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 the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the description only needs to add context. It adds that a manifest with SHA-256 and media info is produced, which is useful, but says nothing about where files land, auth requirements, or overwrite behavior for the outputDirectory.

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

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

A single efficient sentence with the core action front-loaded and no wasted words. It is terse almost to a fault, but nothing is redundant.

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 the description only sketches the manifest artifact, not the actual downloaded media or return shape. Combined with three undocumented parameters and no annotations covering file-system side effects, the definition is too thin for a tool that writes files to disk.

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

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

Schema description coverage is 0% and the description mentions none of the three parameters (jobId, fileName, outputDirectory) or their formats. For a tool whose schema documents no parameters, the description fails to compensate, leaving fileName/outputDirectory semantics unexplained.

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

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

States a specific verb (Download) and resource (a finished job), and clarifies the media types (video or image) plus the accompanying .axcel.json manifest. It is clearly distinguishable from axcel_folder_download_zip, though it does not explicitly name that sibling.

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 word 'finished' implies the job must be complete before download, but there is no explicit when-to-use guidance and no mention of alternatives such as axcel_view or axcel_folder_download_zip. The agent must infer 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?

With annotations present (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the safety profile is mostly covered by structured data. The description usefully adds the external ffmpeg dependency and that a PNG is written to disk, but says nothing about overwrite behavior when outFile already exists or any auth requirement despite login tools being siblings.

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 tight sentence front-loads the action, its inputs, its output format, the motivation, and the dependency—no filler.

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

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

For a 4-param, no-required, no-output-schema tool, the description covers source, output artifact, position, and the ffmpeg prerequisite. The only real omission is what the tool returns (e.g. the written path) and conflict behavior on existing files.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the position values ('last, first or at N seconds') that the schema already defines, and adds no format or default detail beyond it.

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?

Names a concrete verb (save/extract) and resource (one frame as PNG), specifies the two source kinds (local video or finished job) and the three position modes. No sibling tool does frame extraction, and the output format is 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 clause 'e.g. to start the next scene from it' implies the intended workflow (feeding a sequence), but there is no explicit when-to-use/when-not guidance and no naming of alternatives such as download_job or sequence_start.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered and the description does not contradict it. The description adds context on what content the guide delivers (its workflow scope), but says nothing about return size, pagination, or how section content is retrieved beyond the schema.

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?

Front-loads the purpose, then the usage condition, then the parameter note. The long parenthetical enumerating workflow stages is dense but legitimately signals scope; it is a bit run-on but not wasteful.

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, single-parameter guide tool with no output schema, the description covers what it does, when to call it, and what the parameter selects. Nothing essential for correct invocation is missing, though the return shape of the skill content is 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?

Schema description coverage is 100% and the single 'section' parameter is fully documented with examples. The description's 'Omit section for the main guide' merely restates what the schema already says, so this is a baseline 3.

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 purpose: it is the 'axcel-film-studio skill,' a step-by-step guide for making a multi-scene AI film, and enumerates the workflow stages it covers. An agent can tell this is a documentation/guide tool rather than a media-generation sibling, though it never names an alternative to differentiate itself explicitly.

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

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

'Call it before starting a film when your client has no skills support' gives a concrete trigger condition and timing (before starting). It does not state a when-not-to-use case or name any competing tool, but the conditional context is clear enough to route the agent.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is known. The description adds nothing beyond that: it does not say whether names must be unique, what happens on a duplicate name, what permissions are required, or what is returned.

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 short sentence with no filler or redundancy, and the action is front-loaded. It is efficient, though its brevity reflects under-specification rather than disciplined editing.

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

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

For a one-parameter creation tool with a covered annotation profile and no output schema, the description still omits the few things an agent needs: naming constraints, duplicate handling, and confirmation of what a successful call yields. It is minimal but not sufficient on its own.

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

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

There is a single 'name' parameter with 0% schema description coverage, so the description must carry the semantics. It adds nothing about naming rules, uniqueness, length limits, or whether the value is a leaf name versus a path, leaving the parameter 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 gives a clear verb+resource ('Create ... folder') and scopes it to the Library, which separates it from file-level operations. However, it does nothing to distinguish this tool from its closest siblings (axcel_folder_rename, axcel_folder_delete, axcel_folder_list), so an agent only knows the generic action, not the specific role.

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 when-to-use guidance, no prerequisites, and no mention of the alternative folder tools (rename/delete/list) or when this creation step is needed. The agent must infer all usage context from the name alone.

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 destructiveHint=true and idempotentHint=false, so safety is covered structurally. The description adds the explicit irreversibility note ('cannot be undone'), which reinforces rather than contradicts the annotations, but it says nothing about side effects on contained items or auth requirements.

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

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

A single front-loaded sentence with zero filler; the destructive warning is placed immediately after the action. It is arguably too terse for a mutation tool, but nothing in it 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 two-parameter destructive tool with no output schema, the annotations plus the irreversibility note cover the essentials. However, the gap on folderId semantics and the lack of any sibling differentiation leave an agent with gaps it must resolve 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 50%: confirm is well documented in the schema, but folderId has no description. The word 'Library' weakly implies folderId identifies a library folder, but the description does not clarify the identifier format or whether nested contents are removed.

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

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

States a specific verb and resource ('Delete a Library folder'), which is enough to distinguish it from folder_create, folder_rename, and library_delete. It does not explicitly contrast with library_delete, the nearest sibling, but the resource scope 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?

There is no guidance on when to use this tool versus alternatives such as axcel_library_delete or axcel_folder_rename, and no stated preconditions beyond the implicit warning. The agent is left to infer usage entirely from the name.

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 declare readOnlyHint=false, idempotentHint=true, openWorldHint=true and destructiveHint=false, which already communicate safety and repeatability. The description adds only that the scope is the entire folder, but says nothing about where the ZIP is written locally, whether it requires authentication, size limits, or whether it overwrites existing files – notable gaps for a tool whose annotations mark it as a non-read-only, network-touching 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?

A single front-loaded sentence with no filler or repetition. It is efficient, though arguably under-specified rather than merely concise given the tool's complexity.

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 parameter documentation, and only partial annotation coverage, the description leaves too much unstated: where the archive lands, whether login is required, and how folderId maps to a library. For a download/write-to-disk tool, this is a significant shortfall.

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

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

Schema description coverage is 0% and the description provides no parameter information at all. 'folderId' is inferable from the name, but 'outputDirectory' is ambiguous (optional destination path? server-side path? default behavior?) and is left entirely unexplained in both schema and description.

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

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

The description gives a specific verb ('Download'), a clear resource ('a whole Library folder'), and the output form ('as one ZIP file'), so the agent knows exactly what the tool produces. However, it does not differentiate itself from nearby siblings such as axcel_download_job or the other axcel_folder_* operations, so the agent must infer which one to pick.

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 statement of when to use this versus alternatives like axcel_download_job, nor any prerequisite such as being logged in. The only implied guidance is the word 'whole folder', which hints at bulk retrieval but does not name an alternative or a triggering condition.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds nothing beyond that – no mention of whether the listing is scoped to a user/library, whether it can be empty, or how results are ordered.

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?

It is a single short sentence with no padding, which is structurally fine, but the brevity here is under-specification rather than genuine conciseness – there is nothing to front-load because nothing substantive is said.

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

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

With no output schema, the description carries the burden of telling the agent what a folder listing yields (folder identifiers, names, nesting?). It says nothing about the return shape or about the related move/download/delete operations that consume these folders, leaving the agent to guess.

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 takes zero parameters, so there is no parameter semantics burden on the description. Baseline 4 applies; nothing is missing or misrepresented.

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 verb ('List') and a resource ('Library folders'), so the basic operation is identifiable. However, 'Library folders' largely restates the title, and the description gives no signal to distinguish this from siblings such as axcel_library_list, axcel_folder_create, axcel_folder_rename, or axcel_folder_delete.

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 when-to-use guidance, no mention of alternatives, and no indication of prerequisites (e.g. whether login is required first, given the axcel_login_* siblings). The agent must infer that this is the discovery step before folder_create/rename/delete.

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 non-destructive, idempotent, openWorld behavior, so safety is partly covered. But the description adds nothing beyond the bare operation: it does not say what happens on a name collision, whether the folder must pre-exist, or whether the rename is immediately visible to other clients.

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 short sentence, front-loaded and free of waste, so it is structurally clean. However, it is under-specified rather than genuinely concise for a two-parameter mutation 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?

With no output schema and 0% parameter coverage, the description carries the burden and falls short: it omits collision/error behavior, required permissions, and the meaning of folderId. An agent would have to guess at edge cases before invoking.

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% for two required parameters (folderId, name), and the description supplies no compensating detail. It never clarifies whether name must be unique within its parent, whether folderId is a path or ID, or any format constraints.

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

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

States a specific verb and resource ('Rename a Library folder'), so the agent knows exactly what operation is performed. It does not, however, differentiate itself from related siblings such as axcel_library_move or axcel_folder_create, which would require explicit naming.

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 axcel_library_move (to relocate) or axcel_folder_create (to make a new folder). No prerequisites, no exclusions, no context beyond the operation itself.

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

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

Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false, so the safety profile is covered. The description adds real behavioral context beyond that: the call blocks and waits, then downloads the artifact, and reference images are an optional input path. It omits the cost/plan-consumption implication that the schema's `confirm` parameter hints at.

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

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

A single front-loaded sentence with no filler; the verb+resource leads and the optional and post-processing behaviors follow. Every clause carries information.

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

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

For an 11-parameter, open-world generation tool with no output schema, the description covers the core flow (generate, optional refs, wait, download) and the schema fills in polling, file naming, and directory details. It leaves the async jobId handoff and plan-cost consequence implicit, but nothing essential to a correct call is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely restates what the schema already documents (reference images capped at 4, model examples, download-on-completion) without adding syntax, defaults, or edge-case guidance for the 11 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 states a specific verb and resource ('Generate an image on Axcel') and adds useful scope detail: named example models, optional reference-image guidance (up to 4), and the wait/download flow. It is clear what the tool does, though it never explicitly names the neighboring axcel_generate_video as the alternative, so the sibling distinction is left implicit in the word 'image'.

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

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

Usage is only implied: an agent can infer 'use this when you want an image' and that reference images enable image-to-image. There is no explicit when-to-use, when-not-to-use, or routing statement against axcel_generate_video, axcel_upload, or the library 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 flag non-read-only, non-idempotent, open-world behavior, so the bar is lower. The description adds real workflow context beyond them: the call is long-running and waits, it downloads by default, it returns a jobId, and there is a documented fallback path if processing is unfinished. It does not restate the plan/credit-consumption behavior, which lives only in the schema.

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

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

Two compact sentences, front-loaded with the action and mode scope, followed by the return value and the polling fallback. No filler or redundant restatement of the title.

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

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

For a 20-parameter, mutating, cost-incurring tool with no output schema, the description covers the essentials an agent must know: it is asynchronous, it waits, it downloads, it returns a jobId, and how to continue. Gaps remain around cost/confirmation semantics and differentiation from image-generation or sequence workflows, but the rich schema absorbs most of that burden.

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 every one of the 20 parameters is already documented in the schema, and the description adds no format, default, or constraint detail beyond it. Baseline 3 is appropriate when the schema carries the full parameter burden; the only addition (jobId return) is about output, not parameters.

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

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

States a specific verb plus resource ('Generate a video on Axcel') and immediately enumerates the two supported modes (text-to-video, image-to-video). It also distinguishes itself from sibling job tools by clarifying that it waits and downloads, and that polling is the fallback. An agent can identify this tool without opening the schema.

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

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

It names one alternative with a clear triggering condition ('if it is still processing, poll axcel_job_status with that jobId'), which is genuine routing guidance. However, with siblings like axcel_generate_image, axcel_sequence_start, and axcel_download_job present, it offers no guidance on when to prefer this tool over those, and no 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value by disclosing the response content (capabilities, workflow, examples), but says nothing about output format, size, or the odd idempotentHint=false, and there is no output schema to fall back on.

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 compact clause with no filler and the key content front-loaded. It is a fragment rather than a full sentence, but every word earns its place.

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

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

For a parameterless, non-destructive read tool the description is close to sufficient, but with no output schema it should say more about what an agent gets back (form, expected length) and when in a session it is worth invoking. It is adequate but not complete for an entry-point tool in a 31-tool surface.

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 takes zero parameters, so schema descriptions carry no burden and the baseline is 4. There is nothing for the description to clarify about argument semantics.

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?

Names a specific resource (the Axcel MCP) and states exactly what the tool returns: capabilities, recommended workflow, and example requests. An agent can immediately tell this is a documentation/onboarding tool rather than an action tool, though it does not explicitly contrast itself with guidance-flavored siblings like axcel_film_guide or axcel_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 says what the tool contains but never states when to call it — e.g., first on an unfamiliar session, or when unsure which sibling to use. There are no exclusions and no named alternatives, so routing to or away from this tool is left entirely to inference.

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 destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description's '(cannot be undone)' reinforces the destructiveness but adds no information beyond the annotations, and says nothing about auth, scope of deletion, 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?

A single front-loaded sentence with the destructive caveat parenthetically attached; nothing is wasted. It is arguably too terse rather than bloated, but structure and economy are good.

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, non-idempotent mutation tool with no output schema and a required confirm flag, the description omits the confirmation requirement, the identity of the target, and any recovery caveat. An agent has enough to know it is destructive but not enough to call it correctly.

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

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

Schema description coverage is only 50%: the required 'id' parameter has no description anywhere, and the description text never mentions either parameter. It does not compensate for the gap by explaining what a valid id looks like or why 'confirm' is mandatory.

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 (Delete) and resource (history item) on a named product, which cleanly separates it from axcel_history_list and axcel_history_get. It does not explicitly name those siblings or scope what a 'history item' is, so it falls just 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 when-to-use guidance, no prerequisites, and no mention of alternatives such as axcel_history_get or axcel_library_delete. The intended use must be inferred entirely from the name and the word 'Delete'.

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, destructiveHint=false, openWorldHint=true, and idempotentHint=false, covering the safety profile. The description adds that the result includes a 'result URL', which is useful output context beyond annotations, but it does not describe the full return shape, auth needs, or error behavior. With annotations carrying most of the behavioral burden, 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 extremely short and front-loaded with no filler, so it respects conciseness. It is a sentence fragment without a verb, which slightly weakens its structure, but every word still carries information.

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

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

For a simple read-only retrieval, the annotations cover safety and the description notes the key return element (result URL). The missing id semantics and lack of distinction from axcel_history_list leave gaps, but given the low complexity and rich annotations, the description is 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?

The schema description coverage is 0% and the sole parameter 'id' is undocumented in both the schema and the tool description. The phrase 'One history item' hints that an identifier is needed, but the description does not explain what the id represents, its format, or where to obtain it, so it 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 identifies the resource and count ('One history item') and a return element ('result URL'), so the purpose is inferable. However, it is a noun phrase without an explicit verb and does not clearly distinguish itself from siblings like axcel_history_list or axcel_history_delete, making it vague rather than specific.

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 axcel_history_list, nor any note on prerequisites like where to obtain the required id. Usage is only implied by the tool name.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, idempotentHint=false). The description adds genuinely useful behavior: the 7-day retention window, newest-first sort order, and cursor-based pagination. It doesn't describe the shape of each history entry, but with annotations already carrying safety this is solid added 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?

Two short sentences, no filler, and the most decision-relevant facts (retention, ordering) come first, with pagination last. 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 read-only paginated list with no output schema, the description covers ordering, retention, and continuation mechanics. It omits what fields a history record contains and the default page size, but nothing critical for correct invocation is missing.

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

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

Schema coverage is 67%; search and hideFailed are documented inline, while cursor has no schema description. The description partially compensates by explaining that cursor comes from the previous response and drives the next page, which is exactly the undocumented parameter. Adequate but minimal.

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 resource (generation history) with scope details (kept 7 days, newest first), which distinguishes it from siblings like axcel_history_get and axcel_history_delete. It never explicitly says 'list', but the name and the newest-first framing make the list semantics unambiguous.

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

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

Usage is implied by the name and the pagination note, but the description never states when to prefer this over axcel_history_get (single item) or axcel_library_list. No exclusions or prerequisites are given; the agent must infer from sibling names.

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 cover the safety profile (idempotentHint=true, destructiveHint=false, readOnlyHint=false, openWorld=true), and the description adds the key behavior that the call blocks up to waitSeconds and then downloads a file to local storage, explaining why readOnlyHint is false. It omits what happens on timeout (job still running?) and where output lands by default.

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

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

Three short sentences, front-loaded with the purpose before the behavioral and usage notes. The final clause is slightly redundant with the name but earns its place as an anti-pattern warning.

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 5-param, no-output-schema tool with low schema coverage, the description covers the core waiting/downloading contract but leaves the download-destination parameters (fileName, outputDirectory) and the timeout/not-finished outcome unexplained.

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

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

Schema coverage is only 40%, so jobId, fileName and outputDirectory are undocumented in structured fields. The description explains jobId and the waitSeconds behavior ('waits up to waitSeconds'), but adds nothing about fileName/outputDirectory destination semantics, leaving half the gap unfilled.

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+resource: retrieving the status of a named Axcel job by jobId, plus the side behavior of downloading the result. It distinguishes itself from axcel_active_jobs and axcel_download_job implicitly, but never names those siblings, so an agent must infer the boundary.

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

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

Gives one real usage rule ('Use the SAME jobId; never resubmit a slow job'), which is a genuine polling/waiting constraint. It does not say when to prefer axcel_download_job or axcel_active_jobs instead, or when to poll with waitSeconds=0 versus waiting.

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 destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered by structured data. 'Cannot be undone' restates irreversibility in plain language but adds nothing about scope (does it remove jobs, history, or folder membership?), auth requirements, or cascade behavior. The confirm-gate is documented only in the schema, not the description.

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 seven-word sentence, front-loaded with verb and resource and free of filler. It is appropriately tight, though for a destructive, confirm-gated tool the terseness slides toward under-specification rather than genuine economy.

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 non-idempotent destructive operation with no output schema and one fully undocumented parameter, the description omits the preconditions that matter: the assetId source, the required confirm=true gate, and what (if anything) is returned. An agent could not call this correctly from the description alone.

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%: only 'confirm' is documented in the schema, while 'assetId' has no description anywhere. The description says 'a Library item' but never identifies assetId as that identifier, nor gives its format or where to obtain it (e.g., from axcel_library_list), so it 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?

States a specific verb and resource ('Delete a Library item'), which is unambiguous on its own. However, it never distinguishes itself from the close siblings axcel_history_delete, axcel_folder_delete, or axcel_library_move, so an agent must infer which deletion target applies from the name alone.

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 criteria, no prerequisites, and no mention of alternatives or when deletion is inappropriate. The parenthetical '(cannot be undone)' is a warning rather than routing guidance, leaving the agent to guess how this differs from deleting a history entry or a folder.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations: the 14-day retention window and the pagination cursor chaining contract, both of which materially affect how results should be consumed.

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

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

Two short, front-loaded sentences with no filler: item semantics and retention first, pagination contract second. Both sentences carry information, though the pagination sentence largely restates the 'before' schema description.

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

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

With no output schema, the description must carry the return-value burden, and it only partially does so — it names the 'berikut' cursor but not the shape of returned items. Two of four parameters lack documentation anywhere, leaving an agent to guess at filtering 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?

Schema coverage is only 50%, and the description only reinforces the 'before' parameter (already documented in the schema as the previous page's begin value). It adds no meaning for the undocumented search and folderId parameters, so it does not compensate for the coverage gap. Baseline 3 given the partial schema documentation.

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

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

The description names the resource clearly (library items) and specifies what it contains — uploaded images and saved results — which separates it from history or folder listings. It does not, however, explicitly contrast itself with siblings like axcel_history_list or axcel_folder_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?

The only guidance is pagination mechanics ('use the returned begin value as before'), which is invocation detail rather than selection guidance. There is no statement of when to call this versus axcel_history_list or axcel_folder_list, and no exclusions or prerequisites.

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 mutation (readOnlyHint=false), idempotency, non-destructiveness and an open world, so the safety profile is covered. The description adds the meaningful semantic that null folderId removes items from any folder, but says nothing about partial failure across an assetIds array or what the call returns. Adds some value but not rich 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 compact sentence with the action front-loaded and the non-obvious null case appended. Every clause earns its place and nothing is padded.

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 two-parameter mutation tool with no output schema, the description covers the destructive-direction semantics of folderId but omits bulk-move behavior for assetIds, error handling when a folder is missing, and what the caller gets back. Annotations carry the safety profile, so this is adequate but 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?

Schema description coverage is 0%, so the description carries the burden. It usefully clarifies folderId semantics (null = out of any folder), which the schema does not express, but assetIds and its array/bulk behavior are left entirely to 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?

States a specific verb and resource ('Move Library assets') with the destination scope ('into a folder'). It is clearly distinguishable from axcel_library_delete and axcel_library_save_job in the sibling list, but it never names or contrasts against those siblings explicitly.

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

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

There is no when-to-use guidance, no prerequisites (e.g. folder must exist), and no mention of alternatives such as axcel_library_save_job or axcel_folder_list for locating a target folder. The only usage hint is the parenthetical about passing null.

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=false, idempotentHint=false and destructiveHint=false, so the write/non-idempotent profile is covered by structured data. The description adds one genuinely new fact — the job must be finished — but says nothing about duplicate saves, overwrite behavior, auth requirements, or whether saving consumes/relocates the job result.

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

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

A single front-loaded sentence with no filler; the destination and the optional folder qualification are both stated up front. Nothing here is redundant with the title.

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

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

For a two-parameter write tool with no output schema and clean annotations, the description covers the happy path adequately. It is still missing the failure/edge semantics an agent would want — behavior when the job is unfinished, when the folder does not exist, or when the result was already saved.

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 carries the burden and does clarify that the folder target is optional ('optionally into a folder'), matching folderId being non-required. It adds nothing about what jobId accepts (job id format, finished-vs-running) and does not explain the consequence of omitting folderId.

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

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

States a specific verb and resource ('Save a finished job result') plus the destination ('into the Library'), which cleanly separates it from siblings like axcel_library_move, axcel_download_job and axcel_library_list. It does not explicitly name a sibling it must not be confused with, but the verb+resource+target combination 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?

The phrase 'finished job result' implies the precondition that the job must already be complete, which is useful implied guidance. However, it never states when to prefer this over axcel_download_job or axcel_library_move, nor what to do if the job is still running.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuine value beyond that: it discloses the shape of the returned payload (option categories per model) despite there being no output schema, plus a freshness signal ('Live'). It doesn't mention caching, auth, or pagination, keeping it short of a 5.

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

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

A single dense sentence with the resource front-loaded ('Live model catalog') followed by the enumeration of its contents. No redundant restatement of the name or title, and no filler.

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

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

For a read-only catalog tool with one optional enum parameter this is close to sufficient, and the description usefully compensates for the missing output schema by naming what the catalog contains. However it ignores the only input parameter and says nothing about result size, filtering behaviour, or when the catalog might change, leaving gaps an agent must resolve by trial.

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

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

Schema description coverage is 0% and the single parameter ('type', enum video/image) is never mentioned in the description, which instead describes returned payload fields rather than the filter input. The enum values are self-explanatory in the schema, which limits the damage, but the description does not 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 names a concrete resource (a live model catalog) and enumerates what it contains (inputs, resolutions, durations, ratios, audio), so an agent knows this is a discovery/read tool rather than a generation tool. It does not explicitly contrast itself with siblings like axcel_generate_video or axcel_film_guide, but the resource is specific enough to distinguish it.

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 when-to-use or when-not-to-use guidance, no mention of the alternatives (axcel_film_guide, axcel_help) and no stated prerequisites. The implied use — call this before generating to learn valid options — must be inferred entirely by the agent. 'Live' hints at freshness but that is not equivalent to routing guidance.

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

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

Beyond the annotations (which only declare it is not read-only, is open-world and non-idempotent), the description discloses key behavior: it launches a UI window on the user's machine, returns immediately rather than blocking, and requires a human round-trip before completion. That is real added context for an interactive auth flow. It still omits failure/edge behavior (e.g., an existing window, timeouts).

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

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

Three short sentences, front-loaded with the action and side effect, then the required follow-up sequence. No filler and nothing redundant with 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?

No output schema exists, and the description compensates by stating the return behavior (returns immediately) and the mandatory next call, which is what an agent needs for this two-step flow. It is slightly thin on what the user sees or how to detect a failed/abandoned window.

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

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

Only one optional parameter (restart) and schema description coverage is 100%, so the schema already explains it. The description adds nothing about restart semantics, which matches the baseline-3 rule when structured fields do the work.

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?

Specific verb (open a browser window), specific resource (axcel.cloud sign-in), and it explicitly names the follow-up sibling axcel_login_complete. An agent can distinguish this from axcel_logout, axcel_login_import_cookie_file and axcel_login_diagnose from the text alone.

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

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

It states the condition for use (user signs in with their own Google account) and prescribes the exact follow-up workflow: tell the user to sign in, wait, then call axcel_login_complete. It does not say when to prefer the cookie-file import or diagnose siblings, so it stops short of full alternative routing.

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

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

The annotations already declare the safety profile (readOnly=false, idempotent=false, destructive=false, openWorld=true), so the bar is lower. The description adds genuine behavioral context beyond that: the call blocks/waits briefly while the auth window is open, which tells the agent this is a synchronous completion step rather than a fire-and-forget one. It omits failure modes (e.g., behavior if no sign-in was started or the wait expires).

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 zero filler; the action and its prerequisite are front-loaded, and the parenthetical caveat about waiting is placed where it is most useful.

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

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

For a single-parameter terminal step in a login flow with no output schema, the description covers what the tool does, where it sits in the sequence, and that it blocks. Remaining gaps (outcome on failure, whether the session state is inspectable afterward) are minor given the annotations and the sibling axcel_login_diagnose that likely covers troubleshooting.

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

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

Schema coverage is 100% and the single optional waitSeconds parameter is fully documented in the schema (default 15, max 120). The description alludes to waiting qualitatively ('waits briefly') but adds no bound, default, or format detail beyond what the schema already states, so the baseline of 3 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?

States a specific verb pair (confirm the sign-in, save the session) on a specific resource, and names the sibling it must follow (axcel_login_begin). An agent can distinguish it from axcel_login_begin, axcel_login_diagnose, and axcel_login_import_cookie_file without opening any schema.

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

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

Explicitly states the prerequisite and ordering: this is the step that follows axcel_login_begin. It gives clear context for when to call it, but offers no exclusions or guidance versus the other login-family alternatives such as axcel_login_diagnose or axcel_login_import_cookie_file.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing the return content (screenshots AND text of every page, including the Google popup), which matters since there is no output schema.

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 that states the capture scope first and the motivating scenario second, with no redundant or filler text.

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

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

With no parameters and no output schema, the description adequately covers what the tool returns and why. The only gap is the lack of explicit routing relative to the other login tools, but the core is 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 tool takes no parameters, so the baseline of 4 applies. There is nothing parameter-wise for the description to clarify or omit.

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

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

States a specific action and resource: capturing screenshot and text of every page of the open sign-in window, explicitly noting the Google popup. This clearly separates it from the action-oriented login siblings, though it doesn't name an alternative directly.

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 trailing clause 'when sign-in is stuck' implies the diagnostic scenario, giving some usage context, but it never states explicit when-to-use/when-not conditions or names the sibling to prefer for starting or completing login. Usage is implied rather than spelled out.

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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds meaningful context beyond them: the fallback role, the credential-handling restriction, and the origin of the file. It does not describe what happens to the existing session or how failures surface.

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

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

Three sentences, front-loaded with the when-to-use condition, then the operational instructions, then the safety constraint. No sentence is filler and nothing is repeated from the schema or annotations.

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

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

For a credential-import tool with no output schema and full schema coverage, the description covers trigger, input provenance, and a security guardrail. It omits post-success behavior (session replacement, validation failures), which would matter for an auth-mutating 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 coverage is 100%, so the baseline is 3, but the description adds real value by enumerating the acceptable file contents/formats (DevTools cookie header paste, cookie-extension JSON export, cookies.txt), which tells the agent what filePath may legitimately point to. It also enforces a security rule about never requesting raw cookie values in chat.

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

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

States a specific action (sign-in) and mechanism (cookie file import) and frames itself as the fallback path, which is precisely what separates it from the browser-based login siblings. An agent can tell when this tool applies without inspecting any schema.

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

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

The condition for use is explicit: 'Fallback sign-in when the browser window cannot be used.' It also tells the agent how to instruct the user to produce the file. It stops short of naming axcel_login_begin/axcel_login_complete as the primary alternatives, so the routing is implied rather than spelled out.

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 flag destructiveHint=true and readOnlyHint=false, but the description adds the crucial detail of what is actually destroyed: the locally saved session and, by default, the sign-in browser profile. It also implies the server-side session persists unless serverSide=true, which is real behavioral value beyond the annotations.

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

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

A single front-loaded sentence with no filler, with the default behavior parenthetically scoped rather than buried in a second paragraph.

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 two-param destructive tool with annotations covering the safety profile and no output schema, the description gives an agent enough to call it correctly, though it omits any note about re-authentication being required afterward.

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 both parameters (serverSide, keepBrowserProfile) are already documented. The description only restates the default for the browser profile, adding little beyond the schema; baseline 3 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?

States a specific action and target: forget the saved Axcel session on this computer, plus the sign-in browser profile by default. It is clearly separable from the axcel_login_* siblings, which establish rather than remove a session.

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 on when to call this versus alternatives such as axcel_login_diagnose, nor on whether it should precede a re-login or a switch of accounts. Usage is only inferable from the name and the word 'Forget'.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds two genuinely useful facts not in the annotations: the listing is scoped to sequences started from this machine, and results are ordered newest first. It says nothing about pagination, result size, or whether empty results are possible.

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

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

A single, front-loaded sentence with no filler or redundancy. It is efficient, though it is arguably so terse that the scoping phrase 'started from this computer' is left ambiguous rather than explained.

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 parameterless read-only list with no output schema, the description covers what is listed, the scope, and the order. It still leaves the agent guessing about what fields a returned sequence contains and whether results are truncated, which matters since there is no output schema to fall back on.

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 takes zero parameters, so the schema imposes no documentation burden and the baseline of 4 applies. The description's only parameter-like information is the implicit ordering/scoping, which the schema cannot express.

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 concrete resource (multi-scene films/sequences), the scope ('started from this computer'), and the sort order ('newest first'), so an agent can tell what the tool returns. It does not, however, name or contrast itself with near-neighbours such as axcel_history_list, axcel_library_list, or axcel_sequence_status, which is the main thing keeping it out of 5 territory.

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 when-to-use statement and no mention of alternatives. An agent must infer from the tool name alone that this is the listing counterpart to axcel_sequence_start/axcel_sequence_status, and nothing tells it when to prefer this over axcel_history_list or axcel_library_list.

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 non-read-only, non-idempotent, open-world behavior, so the bar is lower, and the description still adds real context: background/asynchronous execution, the returned pipelineId and the polling step, and an external dependency (ffmpeg). It omits the safety-relevant confirm requirement, keeping it from a 5.

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

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

Three tight sentences, front-loaded with the core action, then chaining/join behavior, then return value and dependency. Every sentence adds distinct information with no filler.

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

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

For a complex pipeline tool with 8 params, nested scene objects, and no output schema, the description covers async flow and return value well, but omits the mandatory confirm=true safety gate, the shared-vs-scene override precedence, and the 30-scene cap. Adequate 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?

Schema coverage is 63%, in the middle band. The description's chain/concat explanation largely restates what the schema already documents for those two params, and it is silent on name, scenes, shared, crossfade, and outputDirectory. Baseline 3 is appropriate.

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

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

States a specific verb and resource: generating a multi-scene film scene-by-scene in the background, chaining frames and joining into one MP4. It routes the agent to the correct sibling for follow-up (poll axcel_sequence_status), making it distinguishable from axcel_generate_video and axcel_sequence_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?

It implies the async usage pattern clearly by saying the tool runs in the background and to poll axcel_sequence_status, which is genuine workflow guidance. However, it never contrasts this with single-scene tools like axcel_generate_video, nor states prerequisites such as the required confirm=true flag, so the when/when-not routing is only partial.

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 (readOnlyHint=false, idempotentHint=false, openWorldHint=true) already signal this is not a pure read, and the description adds real behavioral context: resume picks up where it left off, finished scenes are never resubmitted, and re-running a FAILED scene requires confirm=true. This is valuable beyond the structured fields, though it omits auth/permission requirements and cost or rate implications of resuming.

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 tight sentences with the core purpose front-loaded and the conditional parameter behavior following. No filler; every clause carries 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?

With no output schema, the description should indicate what 'progress' actually returns, and it should explain how to obtain the required pipelineId. Neither is covered, and the non-read-only nature of the resume path is only partially contextualized.

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

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

Schema coverage is only 33% (only confirm is documented in the schema). The description compensates for resume and confirm by explaining their semantics, but pipelineId — the sole required parameter — is left completely unexplained in both schema and description, so the compensation is incomplete.

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 clear purpose: reporting progress of a multi-scene film, which is distinguishable from job-level status tools by the 'multi-scene film' scope. However, it never names or contrasts with siblings like axcel_status, axcel_job_status, or axcel_sequence_list, so differentiation is implied rather than 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 conditions for resume=true and confirm=true, which is useful conditional guidance. But it gives no guidance on when to choose this tool over the many sibling status tools (axcel_status, axcel_job_status, axcel_active_jobs) or sequence tools, leaving tool selection to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered without the description's help. The description adds the sequencing cue ("call this first") and that local settings are included, but does not explain the surprising idempotentHint=false or openWorldHint=true, nor what happens if the user is not signed in.

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

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

Two short sentences with the content summary front-loaded and the actionable directive second. Every clause earns its place, though the first sentence is a sentence fragment that reads slightly awkwardly.

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, so the description carries the burden of describing returns — and it does enumerate the main categories (sign-in state, plan, credits/limits, settings). The categories are somewhat coarse ("credits and limits" and "local settings" are vague in shape), but adequate for a zero-parameter status call.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing parameter-related the description could usefully add, and it does not need to.

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

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

The description names the specific resource contents — sign-in state, account plan, credits/limits, and local settings — so an agent knows exactly what this returns. It is distinguishable from billing or login siblings by enumerating those fields, though it does not name the alternatives explicitly.

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

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

"Call this first" is a clear directive about ordering and implies the tool should precede other calls, which is useful. However, it gives no explicit when-not conditions and never contrasts with adjacent tools like axcel_login_diagnose or axcel_billing_plans that also surface account state.

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 annotations (which already declare it non-read-only and non-destructive), the description discloses non-obvious behavior: files are converted when not in the listed formats, the returned assetId is the payload to reuse, and assets are retained only 14 days. That retention/conversion detail is genuinely additive.

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 redundancy; the action, accepted inputs, and returned value are all packed in without filler.

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

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

For a one-parameter upload tool with no output schema, the description states the return value (assetId) and retention window, which is what an agent needs. It stops short of noting upload size limits or auth prerequisites, but is largely 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 coverage is 100% and the single filePath parameter is fully documented with accepted formats in the schema itself. The description echoes the format categories but adds no syntax, path-format, or size-limit detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

States a specific verb (upload), the accepted resource types (local image, reference video/audio), and the outcome (assetId for later generations). It is clearly distinguishable from siblings like library_save_job and library_list, though it doesn't explicitly name them.

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

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

The phrase 'for reuse in later generations' implies the use case, but there is no explicit when-to-use vs when-not guidance or reference to the alternative tools (e.g. axcel_library_save_job). Usage is inferable but 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 declare the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description only needs to add context. It adds one genuinely useful operational fact — ffmpeg is required for video previews — but says nothing about latency, why idempotentHint is false for what appears to be a read, or whether job previews trigger a download as a side effect.

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

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

Two short sentences, zero waste: the capability and scope come first, and the ffmpeg prerequisite follows. Nothing is repeated or padded.

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 low-complexity read tool with full schema coverage and no output schema, the description explains what comes back (a small preview image) and the environment prerequisite. It is nearly complete, though it leaves the nullable file/jobId pairing and the distinction from extract_frame unexplained.

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

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

Schema description coverage is 100%, so every parameter (file, jobId, maxSize, position) is already documented in the schema. The description echoes the concepts ('one frame', 'small preview') but adds no format, default, or constraint detail beyond the schema, which is the expected baseline of 3.

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

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

States a specific verb and resource ('Return a small preview image') plus the accepted inputs (local image/video, single frame, or finished job) and the intent ('check the result visually'). This is clearly distinguishable from job/generation tools, though it does not differentiate itself from the sibling axcel_extract_frame, which sounds like an overlapping capability.

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 clause 'so you can check the result visually' implies the use case (visual verification of output), and 'Needs ffmpeg for videos' is a useful precondition. However, there is no statement of when to prefer this over axcel_extract_frame or axcel_download_job, and no exclusions.

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