ReelsFarm MCP

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

Annotations already declare readOnly=false, destructive=false, idempotent=false, so the safety profile is covered. The description adds genuinely useful context: 'Its batches and their slideshows stay' clarifies that archiving is scoped to the format only and leaves children intact, which explains the non-destructive hint. It does not mention the Creator/Autopilot idempotency requirement or the confirm flow, so it remains thin.

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 wasted words; the core action comes first and the side-effect clarification follows. The phrase 'like Archive in the app' is somewhat informal but efficiently conveys UX parity.

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?

Output schema and full schema descriptions are present, so return values and parameters need no explanation. What is missing is the workflow context: this tool's relationship to the confirm sibling and to the required idempotencyKey in Creator/Autopilot modes, which an agent would need to invoke it correctly in that flow.

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% — all three parameters (dryRun, formatId, idempotencyKey) are documented in the schema with UUID format, validation-only semantics, and retry guidance. The description adds nothing about these parameters, 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 and resource ('Archive a saved slideshow format'), so the agent knows exactly what operation this performs. However, it does not distinguish itself from the directly paired sibling reelsfarm_confirm_archive_slideshow_format, leaving the two-step relationship unexplained.

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 when-to-use, when-not-to-use, or prerequisite guidance. Given that a confirm_archive_slideshow_format sibling exists, the agent would benefit from knowing whether this is the initiation step or the final execution, but the description is silent on this.

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 cover the safety profile (write, open-world, not destructive, not idempotent). The description adds one genuinely useful trait — partial success reporting — but omits other critical behavior: whether the call charges credits, whether it is synchronous or returns a job, and why idempotencyKey matters when idempotentHint is 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?

One front-loaded sentence with no filler; the constraint and the partial-success trait both land immediately. It is efficient, though its brevity is part of why guidance and behavior gaps exist.

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

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

An output schema exists so return shape needn't be explained. However, for a credit-consuming, job-style batch import in a prepare/start/confirm ecosystem, the description should at least indicate whether this enqueues a job and how partial failures 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?

Schema coverage is 100%, so the schema already documents the HTTPS-only URL constraint, the 1–10 item range, the category enum, dryRun, and idempotencyKey. The description adds no meaning beyond those fields, making the baseline 3 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 (import media URLs into a user asset category) plus a concrete scope (up to 10). The word 'bulk' distinguishes it from the single-URL reelsfarm_import_media_from_url, but it never names that alternative or explains the prepare/start/confirm family it belongs to.

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, when-not-to-use, or alternative routing guidance. An agent cannot tell from the description how this differs from reelsfarm_import_media_from_url, reelsfarm_start_bulk_import_media, or the confirm siblings.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the warning sentence largely restates structured data. Worse, the stock phrasing 'overwriting saved data' is not obviously what cancelling a job does, and it omits genuinely useful behavior the agent needs: that Creator/Autopilot require idempotencyKey and whether a cancelled import can be resumed.

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 action and ownership scope front-loaded. The second sentence is generic templated safety boilerplate that could be trimmed or replaced with tool-specific detail.

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

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

With a full input schema, an output schema, and annotations carrying the safety profile, the remaining gaps are minor. The two-way relationship with confirm_cancel_hook_clip_import is the only meaningful omission, and that is arguably discoverable from the sibling name.

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 jobId, dryRun and idempotencyKey are already fully documented in the schema, including the Creator/Autopilot requirement. The description adds no parameter-level meaning beyond that, so 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 verb+resource ('Cancel ... hook clip import job') plus a scope qualifier ('owned by the authenticated user'), which is more than a restatement of the title. It does not, however, distinguish itself from the very similar sibling reelsfarm_confirm_cancel_hook_clip_import, which an agent would naturally encounter next to 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?

The phrase 'pending or running' implies the eligible job states, but there is no explicit when-to-use/when-not guidance, no mention of the confirm_* counterpart in the two-step flow, and no pointer to reelsfarm_get_hook_clip_import_status as the way to check state first.

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 destructiveHint=true and idempotentHint=false, so the sentence 'can have destructive or irreversible effects' mostly restates structured data. It does add the useful fact that the queued job is also removed, but 'including overwriting saved data' is generic boilerplate that doesn't fit a cancel operation and gives no real behavioral insight such as whether the post can be restored.

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 first sentence is front-loaded and earns its place. The second sentence is generic warning boilerplate that partially misdescribes the operation, wasting the only remaining space that could have carried sibling routing or precondition 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?

An output schema exists, so return values needn't be explained, and the safety profile is in annotations. What is missing is the operational context an agent needs: the relationship to reelsfarm_confirm_cancel_scheduled_post and any state requirements for the target post.

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 id, dryRun, and idempotencyKey are fully documented in the schema. The description adds nothing beyond that (e.g., it doesn't reinforce that dryRun is the safe way to validate before a destructive cancel), 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?

The first sentence names a specific verb and resource ('Cancel a SCHEDULED post') and clarifies scope by including 'its queued job', which tells the agent the cancellation cascades. It does not, however, differentiate from the sibling reelsfarm_confirm_cancel_scheduled_post, leaving the two-step relationship unstated.

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 versus reelsfarm_confirm_cancel_scheduled_post or reelsfarm_update_scheduled_post, and no statement of preconditions (e.g., the post must be in SCHEDULED state, not already published). The presence of a confirm_ sibling strongly implies a two-phase flow that the description never mentions.

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

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

Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds that this is a live 'canary' mirroring the web retest, useful context, but says nothing about auth requirements, failure behavior, rate limits, or side effects of the probe.

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 a clear verb and no filler. The trailing clause about the web library is slightly indirect but carries real context rather than repetition.

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

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

With an output schema covering return values, full schema coverage, and rich annotations, the description only needs to explain purpose and context, which it does reasonably well. It could go further by tying the tool to its sibling get_hook_import_capabilities, but nothing critical is missing for correct invocation.

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

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

Schema coverage is 100% and both parameters are documented, including the enum for platform and the profileId reference to get_hook_import_capabilities. The description only loosely reinforces platform selection and 'import account' (profileId) without adding format or constraint detail beyond the schema, so the 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 verb ('Run') and resource ('YouTube or TikTok hook-import access canary'), and clarifies it mirrors the web hook library's retest flow. The purpose of checking live import access is understandable, though it does not explicitly distinguish itself from the closely related sibling reelsfarm_get_hook_import_capabilities.

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 anchors usage to 'when a user retests an import account,' implying a diagnostic/verification context. However, it gives no explicit when-to-use vs alternatives (e.g., when to prefer this over get_hook_import_capabilities or get_hook_clip_import_status), and no when-not conditions.

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

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

Annotations already declare idempotentHint=true, so restating idempotency earns no credit. The description does add two real traits beyond the annotations: the requirement that the sessions originate from the same MCP connection, and the exemption from a second Review confirmation. It says nothing about what happens when validation fails or whether promotion is atomic/partial, which is the key behavioral gap for a mutation tool.

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

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

Two sentences, no filler, with the action front-loaded and the confirmation-policy caveat placed immediately after where it matters.

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

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

An output schema exists, so return values needn't be described, and the single parameter is fully documented in schema. The description positions the tool correctly in the upload lifecycle; the only missing piece is failure/partial-success behavior for the promotion step.

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 sessionIds property already documents the 1–20 UUID range and points back to reelsfarm_create_product_upload_sessions. The description adds nothing about the parameter, so the 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 specific verbs and resource: 'Validate and promote presigned product uploads'. The scoping phrase 'approved by this same MCP connection' distinguishes it from the create/confirm session siblings, though it never names reelsfarm_create_product_upload_sessions or reelsfarm_confirm_create_product_upload_sessions 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?

Makes the trigger condition clear: use after uploads have been approved through this MCP connection, and notes that no additional Review confirmation step is needed — meaningful in a toolset dense with prepare/confirm pairs. No explicit exclusions or failure-path guidance, so not a 5.

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

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

Annotations already declare idempotent=true, destructive=false and openWorld=true; the description usefully adds the two-phase contract and the immutability of prepared arguments, which is behavior an agent cannot infer from the schema. It does not mention credit consumption or whether a job handle is returned, but the output schema covers the latter.

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: the action and its precondition come first, the immutability constraint second. No restatement of the title or 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?

With annotations, a 100%-covered single-param schema and an output schema, the definition covers what an agent needs to invoke it correctly. Minor gaps remain around side effects such as credit spend or what kind of job gets queued.

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 parameter is documented there as the confirmationId from the prepare call. The description reinforces that the ID alone carries all prepared arguments, which is mild added meaning but nothing about format or lifetime.

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 (execute the action prepared by reelsfarm_prepare_ai_clone_job) with an explicit precondition (user approval) and scope (takes only the confirmationId). The prepare/confirm split and the named sibling make it unambiguous against the many other confirm_* tools.

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

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

Clearly says to call this only after the matching prepare tool has run and the user has approved. The alternative (re-invoking prepare) is implied by 'the prepared arguments cannot change' rather than stated, so it stops just short of an explicit when-not clause.

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-destructive, idempotent behavior, so the bar is lower. The description adds two valuable traits beyond annotations: the action is gated on user approval, and the prepared arguments are immutable at confirmation time. It omits any statement about expiry or failure modes, keeping it at 4.

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, both load-bearing: the first gives the action and approval gate, the second the input contract. Nothing is redundant and the precondition is front-loaded.

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 confirmation tool with full annotations and an output schema, the description covers the essentials: what it does, when to call it, and the immutability guarantee. Minor gaps around confirmation expiry or error behavior keep it just under 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 confirmationId parameter is fully documented in the schema, so the baseline is 3. The description reinforces that confirmationId is the only input and that the underlying arguments are frozen, but adds no new format or sourcing detail beyond what the schema states.

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 (run the prepared archive-slideshow-format action) and names its direct counterpart reelsfarm_archive_slideshow_format, which is the key sibling for disambiguation within the large confirm/prepare family. It is slightly indirect ("the action that X prepared" rather than naming the operation outright), so it falls short of a perfect 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?

It gives a clear trigger condition: use this only after the prepare step and once the user approves. It does not spell out what to do if approval is withheld or how to recover an expired confirmationId, so it is clear context without explicit 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 non-readOnly, idempotent, non-destructive, open-world. The description adds real value beyond them: execution is gated on user approval and the prepared arguments are immutable, so the confirmation is not a re-parameterization hook. It omits that this is a credit-consuming bulk generation and says nothing about what happens on an expired confirmation.

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, with the prerequisite linkage front-loaded and the immutability constraint second. Every clause carries information an agent needs before calling.

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 one required parameter, full schema coverage, and an output schema, the description only needs to establish the prepare→confirm contract, which it does clearly. The remaining gap is operational: no mention that this kicks off a billable batch job whose progress must be polled subsequently.

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 confirmationId is fully documented in the schema itself, so the description adds little beyond 'takes only its confirmationId'. That restatement usefully forecloses attempts to override batch arguments, but it is not new parameter semantics; 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?

The description states a specific action (executing the prepared batch avatar generation) and anchors it to the prepare sibling by name, so the agent knows which half of the prepare/confirm pair this is. It never restates 'avatars' or 'batch' itself, leaning on the tool name, but the pairing makes the purpose 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?

'Once the user approves it' gives an explicit gating condition and 'the action that reelsfarm_prepare_batch_generate_avatars prepared' names the prerequisite call directly. It does not cover the failure path (e.g. expired or reused confirmationId, or whether to re-prepare), so usage is clear but not fully specified.

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 covering readOnly, idempotency, and destructiveness, the description adds useful confirmation-specific behavior: the prepared arguments are fixed and only the confirmationId is accepted. It does not describe expiration or failure handling for an invalid confirmationId, but the core behavioral constraint is disclosed.

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

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

Two short sentences, front-loaded with the action and its precondition, with no redundant or filler content.

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

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

Given the presence of an output schema and safety-relevant annotations, the description supplies what an agent needs: when to call, required approval, and immutable prepared arguments. Minor edge cases such as expired or previously consumed confirmationIds are left implicit.

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

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

Schema coverage is 100%, so the confirmationId parameter is already documented. The description adds meaningful context by making clear that no other arguments are accepted and that the prepared arguments cannot be altered.

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 that this tool executes the action previously prepared by reelsfarm_prepare_batch_publish and is distinct from that preparation step. The verb 'Run the action' is a bit generic, but the sibling reference makes the purpose clear.

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 clearly says to call this only once the user approves the prepared action, which establishes the necessary precondition. It does not explicitly warn against calling it before reelsfarm_prepare_batch_publish, but that requirement is strongly implied by the wording.

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=false, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds real context beyond them: this is the execution half of a prepare/confirm pair and the prepared arguments are immutable. It stops short of describing behavior on an expired or already-consumed confirmationId.

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

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

Two short sentences, front-loaded with the action and immediately followed by the parameter constraint. Nothing is redundant 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?

With an output schema, full annotation coverage and a single fully-described parameter, the description carries what an agent needs to select and invoke it. The only gap is failure-mode behavior (expired confirmation, partial import results), which is modest for a one-parameter confirm tool.

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 parameter is already documented in the schema, so the baseline would be 3. The description adds a useful constraint by stating it takes 'only' its confirmationId and that no arguments can be varied, reinforcing the additionalProperties:false contract for the agent.

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

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

States a specific verb and resource ('Run the action that reelsfarm_bulk_import_media prepared') and names the sibling that produces the input, so the pair is unmistakable. It does not, however, disambiguate from the similarly named reelsfarm_confirm_start_bulk_import_media, which sits in the same family and could tempt an agent.

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 an explicit precondition: use it only after reelsfarm_bulk_import_media has prepared the action and 'once the user approves it'. That is clear when-to-use guidance, but there is no explicit when-not (e.g. what to do if the user has not approved, or if the confirmation is stale).

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=true, so the safety profile is known; the description adds real value by stating the prepared arguments are immutable and that effects can include overwriting saved data. It does not mention confirmationId expiry or whether a repeated call is treated as a no-op, which would complete the picture.

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: the action and precondition come first, then the parameter constraint, then the risk warning. Nothing is redundant with the title or 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?

With one parameter, an output schema, and full annotation coverage, the description supplies everything needed to invoke it correctly: the prepare/confirm pairing, the approval gate, and the destructive consequence. Only edge-case behavior for invalid or expired confirmationIds is left unaddressed.

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 single parameter is already documented, but the description adds the meaningful constraint that confirmationId is the only accepted input and encodes unchangeable prepared arguments. That is genuine semantic value beyond the schema's type and minLength.

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 (execute the operation prepared by reelsfarm_cancel_hook_clip_import) and ties it directly to its prepare-stage counterpart, which separates it from the many other confirm_* siblings. The verb 'Run the action' is slightly abstract but the referenced prepare tool pins down the resource precisely.

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 conditions use on a prior prepare call and user approval ('once the user approves it'), which is the key gating rule for this confirmation family. It names the counterpart prepare tool implicitly as the alternative, but does not address what to do if the user has not yet approved or if the confirmationId is stale.

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 idempotentHint=true, so the description's warning is partly redundant, but it adds specificity ('including overwriting saved data') and a genuine behavioral constraint not in annotations: the prepared arguments are immutable. It does not mention replay/expiry semantics of the confirmationId, leaving a small 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?

Three short sentences, front-loaded with the action and its provenance, then the parameter constraint, then the risk warning. No sentence is 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?

An output schema exists so return values need no prose, annotations carry the safety profile, and the two-step flow is spelled out. What remains unsaid is what happens on an invalid/stale confirmationId and whether retries are safe despite idempotency being declared only in annotations.

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

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

Schema coverage is 100% and the schema already documents confirmationId's origin, so the baseline is 3. The description adds real meaning beyond the schema by stating that this is the ONLY parameter and that the underlying prepared arguments cannot be altered, which tells the agent it cannot 'fix' a wrong prepare at this stage.

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 and, crucially, ties the tool to its prepare-step sibling by name (reelsfarm_cancel_scheduled_post). An agent can distinguish this confirmation step from the many other confirm_* siblings because the flow pairing 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?

It gives the gating condition clearly: run only 'once the user approves it', and only after the prepare call produced a confirmationId. It does not enumerate when-not-to-use cases (e.g., expired or reused confirmationIds) or point to recovery tools, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing the immutability guarantee ('the prepared arguments cannot change'), which tells the agent it cannot re-parameterize at confirm time. Return behavior is left to the 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?

Two sentences, no filler; the action and its dependency come first, the constraint second. Every clause carries information an agent needs.

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 confirmation step with an output schema and full annotations, the description covers the essentials: what it executes, whose approval gates it, and that inputs are frozen. Edge cases such as an expired or already-consumed confirmationId are not addressed but are partly mitigated by the idempotentHint annotation.

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 confirmationId parameter is fully documented as coming from the prepare call. The description's 'takes only its confirmationId' reinforces that no other input is accepted, but that is already conveyed by additionalProperties=false, so it adds little beyond 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 ('run the action that ... prepared') and immediately names the sibling it depends on, reelsfarm_prepare_create_automation. Against a sibling list containing dozens of confirm_* tools, this pins the target action unambiguously.

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

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

Explicitly encodes the two-step flow and the gating condition ('once the user approves it'), which tells the agent when this tool becomes callable. It stops short of stating what to do if no approval was obtained or how long the prepared action stays valid, but the trigger context is clear.

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

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

Annotations already declare this is a non-read-only, non-destructive, idempotent, closed-world operation. The description adds useful behavioral context beyond them: user approval is required and the prepared arguments are immutable. It does not spell out what happens if the confirmationId is expired or invalid, but the core safety and execution model is clear.

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 waste. The primary action and approval condition are front-loaded, followed by the key immutability constraint.

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

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

For a single-parameter confirmation tool with annotations and an output schema, the description covers the essential invocation context and constraints. Minor gaps such as confirmation-code expiry behavior are not addressed, but they are not necessary for correct tool selection.

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 schema itself explains that confirmationId comes from reelsfarm_create_media_collection. The description adds meaning by emphasizing that this is the only input and that the prepared arguments cannot be altered, which helps the agent understand the parameter's role as an opaque confirmation handle.

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

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

The description states a specific action: executing the media-collection creation that reelsfarm_create_media_collection prepared. It clearly distinguishes this confirmation step from the sibling that prepares the action, and the title/name align with the stated purpose.

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

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

It says to run this only once the user approves the prepared action, which gives a clear usage condition and implicitly routes the agent through the prepare/create sibling first. It also notes that prepared arguments cannot change, signaling that changes require going back to the preparing tool rather than editing here. It stops short of explicitly naming the exact fallback tool for revisions.

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, idempotent=true, destructive=false, and the description adds real context beyond them: the call is approval-gated and the prepared arguments are frozen, which explains why idempotency holds and why re-invocation is safe. It doesn't cover failure modes such as an invalid or stale confirmationId.

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; the approval precondition and the immutability constraint are both front-loaded and each carries distinct 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?

With a single required param, full schema coverage, an output schema, and rich annotations, the description supplies what the structured fields can't: the approval gate and the frozen-argument guarantee. Only missing edge-case behavior (expired confirmation) keeps it from a 5.

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 schema already documents confirmationId as coming from reelsfarm_create_product_context, so the description mostly restates it. The added note that this is the *only* input and that nothing else can be altered gives mild extra value over 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 action (execute the action prepared by reelsfarm_create_product_context) and names the sibling that produced the pending operation, which lets an agent separate this from the prepare-side tool. It does not explicitly contrast with reelsfarm_confirm_update_product_context, but the referenced sibling pins the resource down.

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

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

Gives a clear precondition: run only 'once the user approves it', with the paired prepare tool implied as the source of the confirmationId. No explicit when-not guidance or handling of expired/rejected confirmations, so it stops short of a 5.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely new context: the action is frozen to the prepared arguments and only a confirmationId is accepted, which prevents the agent from attempting to re-specify parameters at confirm time.

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 filler. The dependency on the prepare tool comes first, followed by the input constraint, so both key facts are front-loaded.

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

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

An output schema exists, so return values need not be explained, and annotations cover safety. What's missing is only marginal: confirmationId lifetime/expiry and the error behavior when confirmation is rejected.

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 parameter is self-documenting, so the baseline is 3. The description earns above baseline by clarifying that confirmationId is the *only* input and that the underlying arguments are immutable, which is semantic information not present in the schema.

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

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

States a specific action ('run the action ... prepared') tied to the exact resource-producing sibling (reelsfarm_create_product_upload_sessions), so the agent knows this executes a staged product upload session creation rather than preparing one. The prepare/confirm relationship is explicit and distinguishes it from the many sibling confirm_* tools only by resource, which is named precisely.

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 the triggering condition ('once the user approves it'), which tells the agent not to call it unprompted. It does not spell out the failure mode (e.g., what if the confirmationId expired or was never prepared), so it falls just short of explicit when-not guidance.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds real value by stating that the prepared arguments are frozen, which tells the agent re-confirmation with modified parameters is impossible. It does not disclose confirmation expiry, credit consumption, or what a failed confirmation looks like, so it remains adequate rather than 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?

Two sentences, no filler, and the core action is front-loaded before the parameter constraint. Every clause earns its place by either identifying the preparer or bounding the input.

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 an output schema present and a single fully-documented parameter, the description need not explain return values. It covers the two-step prepare/confirm model and the immutability of the payload, which is what an agent needs to invoke it correctly. Minor gap: nothing about confirmation lifetime or the consequence of confirming a stale ID.

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

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

Schema coverage is 100% for the single confirmationId parameter, and the schema already documents that it comes from reelsfarm_create_slideshow. The description's 'takes only its confirmationId' reinforces that no other arguments are accepted (consistent with additionalProperties: false) but adds no format or lifecycle detail beyond the schema. Baseline 3 applies when the schema carries the 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?

States a specific verb (run/execute a prepared action) tied to a specific resource and names the sibling that produced the prepared payload (reelsfarm_create_slideshow). This makes it unambiguous against the many other reelsfarm_confirm_* siblings, since the preparer is identified.

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

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

The phrase 'once the user approves it' establishes the precondition for calling, and naming reelsfarm_create_slideshow as the source of the prepared action routes the agent to the correct preceding step. It stops short of stating what to do if the confirmation has expired or been superseded, so it is clear context rather than exhaustive when/when-not guidance.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false. The description adds real value beyond them by disclosing that the prepared arguments are frozen and cannot be modified at confirmation time, which is exactly the behavioral guarantee an agent needs to know before committing.

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

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

Two short sentences, front-loaded with the core action and followed by the immutability constraint. Nothing is redundant 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?

An output schema exists, so return values need no explanation, and the safety profile comes from annotations. The description covers the essentials for a one-parameter confirmation step, with only minor gaps around failure behavior for stale confirmationIds.

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% with a single required confirmationId, so the schema carries the baseline. The description still adds meaning by stating the tool takes only that identifier and that the underlying arguments are locked, reinforcing the parameter's role as a handle rather than a bundle of inputs.

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 (executing a prepared operation) and ties it directly to the sibling reelsfarm_prepare_create_slideshow_batch, so an agent can tell confirm vs prepare apart. It never spells out that the resulting action creates a slideshow batch, leaving the actual effect to be inferred from the name.

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 conditions usage on user approval ('once the user approves it'), which is the key gate for this two-step flow, and implicitly tells the agent to call the prepare tool first. It does not cover edge cases such as what to do if approval is denied or the confirmationId has expired.

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=true, so the description earns credit for adding that the prepared arguments are immutable and cannot be changed at confirmation time. The destructive warning ('overwriting saved data') is somewhat generic boilerplate rather than specifying that the avatar record itself is what is removed.

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 the trigger condition, then the argument constraint, then the risk. 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?

An output schema exists and annotations cover the safety profile, so return values and side-effect class need no explanation. The only gap is failure behavior — what happens with an expired or already-consumed confirmationId — which the description does not address.

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% for the single parameter, so the schema already carries the definition. The description adds real meaning by explaining that confirmationId is the *only* input and that all other arguments were frozen at prepare time, which tells the agent not to attempt to pass avatar identifiers here.

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 ('Run the action') tied to a named sibling ('that reelsfarm_delete_avatar prepared'), making the confirm step of the prepare/confirm pair unmistakable. An agent can distinguish it from the ~60 other confirm_* tools by the explicit reference to the avatar-delete prepare call.

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?

'once the user approves it' gives an explicit triggering condition and implicitly identifies reelsfarm_delete_avatar as the prerequisite step. It stops short of stating what to do if approval is withheld or the confirmationId is stale, but the when-to-use case is unambiguous.

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=true, so the safety profile is known; the description adds genuinely new information — that the prepared arguments are frozen and cannot change at confirmation time. It also restates the destructive/irreversible nature, which is redundant with annotations but appropriately cautions the agent.

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-loading the action and precondition before the immutability constraint. The final warning sentence is somewhat boilerplate but still earns its place for a destructive 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 rich annotations and an output schema, the description only needs to explain the confirm-step contract, which it does: precondition, argument immutability, and destructive effect. Nothing essential is missing, though a note on what happens if preparation expired would complete it.

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 confirmationId is already documented, but the description reinforces 'takes only its confirmationId' and clarifies that the value must come from reelsfarm_delete_gallery_image, which slightly exceeds the schema's wording.

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 ('Run the action... prepared') and ties it directly to its producer, reelsfarm_delete_gallery_image, so an agent can distinguish the confirm step from the prepare step among the many confirm_* siblings. Scope and input are explicit in one sentence.

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?

'once the user approves it' gives a clear precondition for invocation, and naming reelsfarm_delete_gallery_image establishes the required prior step. It doesn't explicitly say what to do if no preparation exists (e.g. an error), but the when-to-use condition is unambiguous.

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=true, so the safety profile is covered. The description goes beyond them by naming the concrete consequence ('including overwriting saved data') and the immutability constraint ('the prepared arguments cannot change'), which shapes how an agent should reason about the call.

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

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

Three short sentences with the action and the approval gate front-loaded, followed by the parameter constraint and the risk note. Nothing is redundant or padding.

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 an output schema present and rich annotations, the description covers purpose, precondition, input constraint, and risk. Only edge behavior (expired or already-consumed confirmationId) is left unaddressed, a minor gap for a two-step confirmation tool.

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 already documents confirmationId and its origin, so the baseline would be 3. The description adds the non-obvious invariant that the confirmationId carries locked-in arguments and no other input is accepted, which is genuine semantic value beyond 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 ('Run the action') plus the exact resource and names the sibling that produced the pending action (reelsfarm_delete_media_collection). In a family with dozens of confirm_* siblings, this makes the tool's identity 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?

Explicitly frames the precondition: run only 'once the user approves it', and points to where the confirmationId comes from. It does not state what to do if approval is withheld or the confirmation has expired, but the when-to-call rule is clear.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is partly structured data. The description still adds real context: the prepared arguments are frozen and cannot be altered at confirm time, and the effect can be irreversible or overwrite saved data. It does not explain confirmation expiry or idempotency-of-replay behavior, which keeps it at 4.

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 its prerequisite, followed by the parameter constraint and the destructive warning. No redundancy or filler; each sentence carries distinct 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?

With one required parameter, full schema coverage, complete annotations, and an output schema handled separately, the description covers everything an agent needs: the prepare-pair prerequisite, the single input, frozen arguments, and destructive impact. Nothing material 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 100% and the confirmationId is already documented as coming from reelsfarm_delete_slideshow. The description adds semantic value by stating that only this ID is taken and that it encapsulates the immutable prepared arguments, clarifying the two-phase contract beyond the schema's field description.

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

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

States a specific verb+resource ('Run the action that reelsfarm_delete_slideshow prepared') and names the exact sibling it pairs with, so the agent can tell it apart from the many other confirm_* tools and from reelsfarm_delete_slideshow itself. The scope (delete slideshow via a prior prepare call) 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?

'once the user approves it' gives a clear triggering condition for calling this tool, which implicitly excludes calling it before prepare has run. It stops short of explicitly stating when not to use it (e.g. expired or already-consumed confirmation) or pointing to alternatives, so it falls just short of a 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is carried by structured data. The description adds genuinely new information: that prepared arguments are frozen and cannot be altered at confirmation time. The destructive/irreversible sentence largely restates the annotation.

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 its precondition. The final destructive-effects sentence is somewhat boilerplate against the destructiveHint annotation but is not harmful.

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?

Output schema exists, so return values need no explanation, and the one-parameter schema is fully covered. The description supplies the prerequisite chain (prepare then confirm) and the immutability guarantee, leaving nothing an agent needs 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 100% and the single confirmationId property is fully documented in the schema. The description only restates that it is the sole input, adding no format or lookup guidance beyond 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 action ('run the action that reelsfarm_delete_video prepared') with a named sibling as the source, so the agent can tell it apart from the prepare tool and from the many other confirm_* siblings. The resource (video deletion) is unambiguous given the prefix.

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 conditions invocation on user approval of a previously prepared deletion, which is the correct usage gate. It does not name a negative case (e.g., 'do not call without a matching confirmationId from delete_video'), but the prerequisite is clear.

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

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

Annotations already cover the safety profile (idempotentHint=true, destructiveHint=false, non-read-only), and the description usefully adds that the prepared arguments are frozen and only the ID is accepted. It says nothing about confirmation expiry, failure modes, or whether the effect is a new avatar asset, which are the remaining behavioral unknowns for a mutation.

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: the action and its approval gate first, then the parameter constraint. Nothing is redundant or buried.

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 an output schema present and annotations carrying idempotency and safety, the description covers what to pass and when to call it. Only the expiry/failure behavior of the confirmation token is left implicit, a minor gap for a single-parameter confirm tool.

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 schema itself already documents confirmationId as coming from reelsfarm_duplicate_avatar; the description restates that same fact rather than adding format, lifetime, or error semantics. 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 action (run the prepared avatar-duplication) and ties it directly to the sibling that produced it, reelsfarm_duplicate_avatar, so an agent can separate prepare from confirm. It never says 'duplicate avatar' in its own words, relying on the reference to the prepare tool to carry the resource identity.

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

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

Gives a clear precondition for use: only after the user approves the prepared action. It does not spell out the when-not case (e.g. what to do if the user declines or the confirmationId has expired), so it stops short of explicit alternatives.

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

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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world. The description adds the critical behavioral fact that the prepared arguments are immutable and only the confirmationId is accepted, preventing an agent from attempting to amend the operation at confirm time. Missing only failure modes such as expiry or mismatched IDs.

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, the trigger condition first and the immutability constraint second; nothing redundant 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?

An output schema exists so return values need no explanation, and the description covers the two-phase semantics and parameter restriction. Only error/expiry handling is left implicit, which is a minor gap for a confirmation step.

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 parameter is documented in-schema as coming from reelsfarm_duplicate_slideshow; the description reinforces that no other arguments can be supplied, which meaningfully constrains use beyond the schema text.

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

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

A specific verb plus resource ("run the action that reelsfarm_duplicate_slideshow prepared") that names the sibling it depends on, cleanly separating the prepare/confirm pair among ~150 siblings.

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

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

"once the user approves it" gives the triggering condition clearly, and referring back to the prepare tool implies the precondition. It does not state what to do if approval is withheld or the confirmation is stale/expired, so it falls short of full when/when-not coverage.

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, destructiveHint=false and idempotentHint=true; the description adds the meaningful non-obvious fact that the mutation executes arguments that cannot be altered at confirm time. It does not address expiry or failure behavior of a confirmationId, which would round this out.

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

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

Two sentences, no waste; the action and its precondition come first and the immutability constraint follows as supporting detail.

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

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

With an output schema and full annotations carrying safety and return-shape information, the description needs only the workflow contract, which it supplies. The remaining gap is error/expiry handling for the confirmationId.

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, and the description earns above baseline by explaining why there is exactly one parameter: the confirmationId is an opaque handle and the prepared arguments cannot change. That removes any temptation for an agent to pass extra fields.

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 ('Run the action') tied to the exact resource prepared by reelsfarm_duplicate_video, making the prepare/confirm pairing unmistakable even among many similarly named confirm_* siblings.

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

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

Explicitly gates invocation on user approval and implies the prerequisite prepare call by naming reelsfarm_duplicate_video as the source of the action. It does not state what to do if approval is absent or the confirmation is stale, so it falls short of 5.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful behavioral context beyond that: execution is gated on user approval and the prepared arguments cannot change. It does not describe side effects in detail, but for a confirmation wrapper the key constraints are covered.

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, purpose first and parameter/immutability constraint second. Every sentence earns its place with no repetition or 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?

This is a narrow confirmation executor; annotations, schema, and output schema carry much of the structured detail. The description supplies the approval gate, prerequisite sibling, and immutability constraint, leaving nothing essential missing for correct invocation.

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

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

Schema coverage is 100% and documents confirmationId. The description reinforces that only confirmationId is taken and that the prepared arguments are immutable, which adds meaning to the single parameter's role beyond the schema.

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

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

The description names the exact prepared action (exclude slideshow batch item), frames it as the execution/confirmation step for reelsfarm_exclude_slideshow_batch_item, and distinguishes it from that sibling by user approval and confirmationId. An agent can tell exactly what this tool does 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 states the key condition: use this once the user approves the action prepared by reelsfarm_exclude_slideshow_batch_item. The prerequisite and workflow context are clear, though it does not explicitly say what to do if approval is withheld.

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, idempotent, non-destructive, open-world behavior. The description adds useful context beyond them: this tool executes a previously prepared action, requires user approval, and the prepared arguments are immutable. Missing details such as confirmation expiry or failure behavior keep 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?

Two tight sentences. The purpose and prerequisite are front-loaded, followed immediately by the key constraint that no other arguments can be supplied.

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 confirmation tool with an output schema and full annotation coverage, the description covers the essential workflow: prepare first, user approval, then confirm with only the confirmationId. Minor omissions like confirmation expiry or error behavior are not critical given the structured data available.

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 schema already documents confirmationId fully. The description reinforces that only the confirmationId is accepted and that the prepared arguments cannot be changed, which adds meaningful invocation guidance beyond the schema's type 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 states a specific action (running the export prepared by reelsfarm_prepare_export_slideshow_video) and explicitly names the sibling preparation tool that must precede it. An agent can distinguish this confirm step from both the prepare tool and the separate status-checking sibling 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.