Prolifik

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely non-derivable behavior: it is asynchronous and must be polled via get_clone_job, it consumes AI credits, and idempotencyKey should be passed on retries. It stops short of describing failure/partial-success behavior, so not 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?

Front-loaded with the core action and the cost/comparison rationale, then the async and credit/idempotency caveats. The opening 'Paste a TikTok or Instagram link' sentence is slightly puzzling since no URL parameter exists (jobId is passed), but overall every sentence 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 async, credit-spending mutation with no output schema, the description covers the important agent-facing facts: polling target, cost, idempotency, and lifecycle ('stay on the cloning job until saved to the Library or scheduled'). Minor gap: it doesn't reconcile the 'paste a link' framing with the jobId parameter the agent actually supplies.

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

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

Schema description coverage is only 33%, with jobId and variations undocumented structurally. The description implies the job context (an already-analysed cloning job) and explains idempotencyKey usage, partially compensating, but it never clarifies jobId semantics or the variations count beyond the schema's 1–8 range. Baseline 3 given partial schema coverage plus marginal added meaning.

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 (add/build) and resource (variations on a cloning job), and immediately distinguishes scope from a fresh clone ('cheaper than a new clone, because the post is downloaded and read only once'). An agent can tell this apart from clone_post and localize_clone_variations 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?

Gives clear when-to-use context: it operates on a job that is already analysed, and contrasts that with creating a new clone. It also states the async workflow (poll get_clone_job) and the retry condition for idempotencyKey. It does not explicitly name sibling alternatives like localize_clone_variations, so it falls 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 and readOnlyHint=false, so the mutation profile is covered. The description adds the state constraint that only queued or in-progress jobs are eligible, which is real context beyond the annotations, but it says nothing about reversibility, whether the job record is deleted, or whether completed clips are retained.

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

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

One short sentence with the key scope qualifier front-loaded; nothing wasted. It is efficient, though extremely terse given the number of open behavioural questions.

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 destructive tool with no output schema, the description covers the action and the eligible states but omits what cancellation returns or how the job's state changes afterwards. Annotations carry the safety signal, so the definition is workable but leaves 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?

There is one parameter (jobId) with 0% schema description coverage, so neither schema nor description explains what the id refers to or where to obtain it. The description mentions the parameter not at all, leaving the agent to infer it is a Clipper job id from create_clip_job/get_clip_job.

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

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

States a specific verb (cancel) and a specific resource (Clipper job), and names the only valid states (queued or in-progress). It is distinguishable from the neighbouring cancel_content_job and cancel_content_publish because the resource is named, though it never explicitly contrasts itself with 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 'queued or in-progress' implicitly tells the agent when cancellation is applicable (not for completed jobs), which is useful. However there is no explicit guidance on alternatives such as cancel_content_job, nor any prerequisite or post-condition statement.

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 readOnlyHint=false, so the agent knows this is a mutating, destructive operation. The description adds the useful constraint that only queued/generating jobs are cancellable, but says nothing about side effects on the produced content or partial cleanup.

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

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

One sentence, front-loaded with the verb and the state qualifier, with no filler. Nothing to trim.

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 tool with no output schema, the definition is serviceable but thin: it omits the jobId parameter, the behavior on non-cancellable states, and whether cancellation is reversible or frees quota. Adequate, not complete.

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

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

Schema description coverage is 0% and the description never mentions jobId at all. The parameter name is largely self-explanatory and the schema supplies uuid format/pattern, but the definition does not compensate for the documentation gap as a low-coverage schema requires.

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 ('Cancel') and resource ('content-production job') and narrows scope to jobs in 'queued or generating' states. It distinguishes itself from cancel_clip_job and cancel_content_publish by resource name, though it never names 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?

The 'queued or generating' qualifier tells the agent when cancellation is applicable, implicitly excluding completed/failed jobs. There is no explicit statement of what to do instead for other states or which sibling cancels other job types.

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 openWorldHint=true, so the mutation and external side effects are partially covered. The description adds genuine value beyond them by disclosing the quota refund side effect and the 'when applicable' condition, though it says nothing about failure modes or reversibility of the cancellation.

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

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

A single sentence that front-loads the verb and resource, then attaches the precondition and side effect in a compact clause. No filler, nothing to trim.

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, one-parameter tool with no output schema and no annotations covering the refund, the description covers the essentials (what is cancelled, the precondition, the refund). It omits what happens on failure (e.g., already-published publishId) and any confirmation or irreversibility note, leaving gaps for an agent handling edge cases.

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 the single required publishId parameter, so the description should compensate but instead only vaguely refers to 'a content post' without explaining where publishId comes from or what it identifies. The parameter's name and UUID format in the schema make it largely self-evident, keeping this at a minimum-viable 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?

The description pairs a specific verb (cancel) with a specific resource (a not-yet-published content post) and adds scope ('not-yet-published'), which separates it from mutation siblings like update_content_publish or publish_content. It stops short of naming the sibling alternatives it should be chosen over, so it is clear but not fully differentiated.

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 precondition for use: only posts that have not yet been published at the provider are cancellable, which implicitly excludes published posts. It offers no explicit alternatives (e.g., update_content_publish, delete_content_piece) for cases where the post is already live, so guidance is clear but not exhaustive.

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?

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true). It discloses that the call is asynchronous and returns before completion, that variations remain attached to the job until saved/scheduled, and that it consumes AI credits — all operational facts an agent must know to call it safely.

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 core action and packs the async flow, next steps, and credit warning into compact sentences with no filler. Every clause carries procedural or routing 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 mutating, credit-spending, async tool with no output schema, the description covers the critical gaps: async return behavior, polling target, downstream save/publish tools, and cost pre-quote. An agent has everything needed to invoke and follow through 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 coverage is only 40%, so the description must compensate. It usefully explains the 'url' parameter (TikTok/Instagram, carousel or wall-of-text video), but says nothing about the 'variations' count, 'idempotencyKey', or why a retry-safe key is required — leaving a meaningful part of the low-coverage schema undocumented.

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

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

States a specific verb and resource: paste a TikTok/Instagram link and Prolifik rebuilds it as brand-voiced variations. It clearly distinguishes itself from sibling generators (blog/content jobs) by naming the source platforms and the carousel/wall-of-text input types.

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 describes the async lifecycle: returns on queue, poll get_clone_job until 'ready'/'failed', then keep with save_clone_variation_to_library or schedule/post with publish_content. It also names estimate_clone as the required cost-quoting prerequisite, giving full when-to-use and 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?

Annotations cover the safety profile (write, non-destructive, open-world), and the description adds genuinely useful behavior beyond them: the brand returns immediately while voice/audience enrichment completes asynchronously. It omits the duplicate-call/idempotency behavior, which matters for a create 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?

Two tight sentences with no filler; the synchronous-creation/asynchronous-enrichment distinction is front-loaded and immediately actionable.

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

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

For a create tool with no output schema and undocumented parameters, the description explains the return timing but not the idempotency contract, error/duplicate behavior, or what the enrichment fields contain. 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 description coverage is 0% and the description only obliquely gestures at the url parameter ('from its website'). The required idempotencyKey is never mentioned, so the agent gets no explanation of its purpose or the duplicate-suppression 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 and resource (create a brand from its website) and adds the enrichment behavior, which clearly separates it from get_brand, list_brands, and update_brand among the 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?

Usage is only implied: the agent can infer this is the first step before enrichment and subsequent get_brand/update_brand calls, but the description never states when to use this over alternatives or any 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?

The annotations establish the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds real behavioral value by disclosing that the call 'consumes the account's clip-minute allowance,' a billing side effect not captured by annotations, but it omits job/async semantics and failure behavior for a 15-parameter queuing 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?

Two tight sentences with zero filler, and the core action plus its batch limit is front-loaded. Nothing is wasted, though there is little beyond the essentials.

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

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

For a tool with 15 parameters, nested option objects, and no output schema, the description is far too thin. It should at least hint at the async job lifecycle (polling via get_clip_job_status) and the primary option groups, none of which appear.

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 7%, so the description must compensate and largely does not. It conveys the single-vs-batch behavior and the 10-item cap (matching url/urls), but says nothing about the remaining 13 parameters, including the nested options object with layout, mode, format, quality, brand_kit, and clip-count/duration controls.

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 ('Queue one video URL, or a batch of up to 10 video URLs, for AI clipping') with clear scope and the batch limit. However, it does not differentiate itself from siblings like get_clip_job_status, estimate_clone, or list_clip_jobs, which an agent would need to disambiguate an async job tool.

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 or when-not-to-use guidance and no named alternative (e.g., checking allowance via get_clip_minutes first, or polling with get_clip_job_status). Usage is only implied by the verb 'Queue ... for AI clipping'.

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=false, openWorldHint=true, destructiveHint=false), so the bar is lower. The description adds real value beyond that: the 15-minute expiry, the presigned PUT mechanism, and the downstream use of the returned path. It still omits auth requirements and size/type constraints.

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, front-loaded with the core action and expiry, followed by the follow-up usage. 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?

No output schema, but the description states the return value ('returned path'). However, with two params at 0% coverage and no mention of jobId, the definition is not fully complete 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 0% and the description never mentions either parameter. 'video source' loosely gestures at fileName, but jobId — which ties the URL to a specific Clipper job — is completely undocumented in both schema and description.

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

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

States a specific verb and resource: 'Create a 15-minute presigned PUT URL for a video source.' The 'video source'/'Clipper job' framing distinguishes it from sibling upload-URL tools like create_content_upload_url and create_studio_upload_url.

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?

Describes the workflow clearly: create the URL, upload, then use the returned path as sourceStoragePath when queueing a Clipper job. It gives context but never explicitly names or contrasts against the sibling upload-URL tools, so the agent must infer which one to pick.

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 establish non-read-only and open-world behaviour, but the description adds substantial context beyond them: asynchronous lifecycle with concrete terminal states (ready_for_review, completed, partially_failed), per-piece consumption of the monthly render budget, and a refusal condition when the budget is exhausted. It omits auth/permission requirements, which prevents 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?

The core action, batch limit and quota constraint are front-loaded and efficient. The talking-head mechanics arrive as one long compound sentence, which is dense but arguably necessary for the format's required parameters; there is little pure 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 12-parameter, nested-object mutation with no output schema and low schema coverage, the description covers the risky/ambiguous parts (quota, async states, talking-head inputs, audio substitution). It still leaves several parameters and the idempotency contract undocumented, so an agent could call it valid but under-informed.

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% across 12 parameters, so the description must compensate. It does add meaning for demoVideoKey, hookVideoKey and audioMood (own audio replaced by library track), but leaves deliveryMode, idempotencyKey, contentSourceId, includeLogo and mentionBrand entirely unexplained in both prose and 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 first sentence names a specific verb and resource ('Queue an asynchronous, rendered content batch') and scopes it (up to 50 pieces). An agent can distinguish this from siblings like create_clip_job or create_studio_generation 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?

Usage context is implied through prerequisites: talking-head requires demoVideoKey from a media library or upload URL, and a job exceeding remaining monthly renders is refused. However, it never states when to choose this over the closely-named siblings (create_clip_job, create_studio_generation), and gives no 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 cover the mutation/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds genuinely new behavioral context: the call is asynchronous, returns immediately, and the returned source carries a status that later becomes 'ready' after analysis finishes. That polling/eventual-consistency detail is exactly what an agent needs and is not in the annotations. It omits idempotency behavior and failure modes, but the async lifecycle disclosure is valuable.

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 most decision-relevant fact (queued/asynchronous) is front-loaded. 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?

With no output schema, the description does helpfully explain the return shape (the source with a status). However, for a 4-parameter tool with 0% schema coverage and no usage routing against five sibling create/list tools, the definition is not complete enough to guarantee a 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 description coverage is 0% and the description only vaguely accounts for 'url'. The required brandId and idempotencyKey, plus the optional title, are completely unexplained in either the schema or the description, leaving three of four parameters semantically opaque.

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 and resource: it queues a URL for scraping and AI analysis, producing a 'source' object. This distinguishes it from create_content_job and create_content_upload_url by implying a URL-scraping ingestion path, though it never names 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 guidance on when to use this over create_content_job, create_content_upload_url, or create_clip_upload_url, all of which sit in the same creation family. No prerequisites or exclusions are stated, so the agent must infer the routing 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 only flag readOnly=false, openWorld=true, destructive=false. The description adds substantial behavior beyond that: a 30-minute URL expiry, the signed Content-Type requirement, size (100 MB) and duration caps (60 s demo / 15 s hook), and the semantics of the returned key — exactly the mutation details annotations cannot convey.

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

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

Three dense sentences, front-loaded with the core action and constraints, then the call mechanics, then the return-value usage. No filler; every clause carries a constraint or instruction.

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 only one parameter, no output schema, and a single creation action, the description covers everything an agent needs: format/size/duration limits, the exact PUT procedure, the signed header requirement, and what the returned key is used for.

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 0%, so the description must carry the parameter's meaning, and it does: it spells out the accepted formats (mp4/mov/webm) matching the contentType enum and requires the same Content-Type header on the PUT. It does not restate the enum values verbatim, but the mapping is unambiguous.

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 (Create) and a precisely scoped resource (a 30-minute presigned PUT URL for a Video Hook & Demo recording), including the exact downstream use (a Video Hook & Demo content job). This is clearly differentiated from sibling upload-URL tools like create_clip_upload_url and create_studio_upload_url.

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

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

The description gives clear operational context: PUT the bytes to uploadUrl with the signed Content-Type, and the returned key feeds demoVideoKey/hookVideoKey. It does not explicitly compare against the clip/studio upload-URL siblings or state when each is preferred, so it stops short of full 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, destructiveHint=false, and openWorldHint=true, so the write/safety profile is covered. The description adds useful behavior beyond that by disclosing the operation is asynchronous ('queue its base portrait'). However, it says nothing about the required idempotencyKey's deduplication behavior, credit cost, or failure modes, which matter for a create call.

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

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

Two short sentences, zero filler, and the core action is front-loaded ahead of the follow-up polling instruction.

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 no annotations about returns, the description does at least route the agent to get_influencer for polling. But for a 7-parameter create tool it omits parameter meaning, cost, and what the initial call returns (job id vs. influencer id), leaving real 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 description coverage is 0% across 7 parameters, so the description carries the full burden of explaining them and instead mentions none. The required idempotencyKey, brandId, and optional fields like details/ethnicity are left entirely to bare JSON Schema types with no semantic guidance.

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

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

The description gives a specific verb+resource ('Create a reusable AI influencer') and adds the scope of what creation triggers ('queue its base portrait'), which distinguishes it from regenerate_influencer and get_influencer. It does not explicitly contrast with other create_* siblings, but the resource 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?

'Poll with get_influencer' tells the agent exactly what to do after this call, which is the key follow-up action for an async create. There is no explicit when-not guidance (e.g., vs regenerate_influencer or list_influencers), but the context is clear.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds one genuinely new behavioral trait: this is an asynchronous queue operation that requires polling. It does not mention credit consumption, auth, or how kind-dependent params behave.

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 tightly written sentences, front-loaded with the action and followed by the follow-up step. No filler, no redundancy.

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

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

This is a complex, nested-param, 4-required-param mutation tool with no output schema and zero parameter coverage, so the description carries the full burden and falls well short. It omits how params depend on kind, what idempotencyKey guarantees, and where modelKey values come from (list_studio_models).

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 six parameters are undocumented at the top level (modelKey, params, idempotencyKey, influencerId, prompt). The description's mention of image/video/talking-head merely restates the 'kind' enum and adds no syntax, format, or dependency meaning for the other 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 ('Queue') and resource ('AI generation'), and enumerates the three output kinds (image, video, talking-head) that match the sibling namespace. It is clear on its own, though it doesn't differentiate itself from other create_* job tools like create_clip_job or create_content_job.

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

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

It gives a concrete next step ('Poll with get_studio_generation'), which is useful workflow routing. However, it offers no when-to-use-vs-alternative guidance or prerequisites, so usage is only implied rather than stated.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value by explaining the presigned-URL handshake and that a key is returned for reuse, but it says nothing about URL expiry, upload constraints, or size/type limits that matter for a presigned flow.

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, front-loaded with the core action and followed by the workflow. Every clause carries information; nothing is padded or repeated from 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 single-parameter tool with no output schema, the description covers the essential arc: what URL is produced, that bytes must be uploaded, and that the returned key feeds the next tool. The only gap is the undocumented contentType parameter, which the schema's enum partially mitigates.

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 contentType parameter is not mentioned in the description at all. The phrase 'source/reference image' loosely aligns with the image/* enum, but the description adds no syntax or meaning beyond the schema's enum values, so this is baseline rather than compensation.

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 ('Create a presigned PUT URL for a source/reference image'), which an agent can act on directly. It implicitly distinguishes itself from create_clip_upload_url and create_content_upload_url via the 'source/reference image' + studio context, but never names 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?

Gives a clear usage sequence: create the URL, upload the bytes, then pass the returned key to create_studio_generation. That names the downstream tool and the condition for using this one. It lacks any explicit 'do not use when...' exclusion, 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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description goes beyond that by specifying the scope of destruction: unsaved variations live on the job and are removed, while variations already saved to the Library survive. That is exactly the kind of consequence detail an agent needs before a destructive 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?

Roughly 75% of the text is preamble about the cloning product rather than this tool. For a single-parameter delete, the relevant content ('This deletes the job. Variations already saved to the Library survive it.') is two sentences buried at the end instead of front-loaded. The marketing copy does not earn its place in a delete tool's definition.

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-param destructive tool with no output schema, the description covers the key data-loss consequence, which annotations alone would not. It omits permission/auth requirements, whether the job record itself is recoverable, and how to obtain a valid jobId, leaving modest 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 description coverage is 0% and there is one parameter (jobId), so the description carries some burden. It refers to 'the job' and 'the cloning job,' which implicitly identifies what jobId targets, but adds no format, sourcing, or lookup guidance (e.g., obtain via list_clone_jobs or get_clone_job). Marginal compensation 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 actual purpose is stated plainly in sentence four: 'This deletes the job.' However, three of the four sentences describe the cloning feature generally (pasting TikTok/Instagram links, generating variations), not the delete operation, so the purpose is buried under product marketing rather than front-loaded. There is also no differentiation from the delete-adjacent siblings (retry_clone_job, distribute_clone_job).

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

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

The description never says when to delete a job versus when to retry or distribute it, nor any prerequisite or caution condition. The statement that saved variations survive is useful consequence information, but it is not usage guidance for selecting this tool.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds real behavioral context beyond them: the stored render is deleted as part of the cascade and queued provider posts are cancelled first. It still doesn't say whether the deletion is permanent or what permissions are required, so it is not 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 with zero filler, and the primary effect (delete) is front-loaded ahead of the secondary side effect (cancellation).

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 destructive delete with no output schema, the description covers the important surprises: cascading render deletion and pre-emptive post cancellation. It leaves out irreversibility and permission prerequisites, which are the remaining gaps an agent would want.

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 contributes nothing about pieceId beyond implying which resource it identifies. The UUID format and pattern live in the schema, but the description neither explains the identifier's source nor its uniqueness 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 (Delete) and resource (content piece) plus a cascade target (its stored render), which separates it from delete_content_source, delete_clone_job and delete_influencer. It does not explicitly name a sibling or contrast with update_content_piece, so it stops short of a 5.

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

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

There is no when-to-use guidance and no mention of alternatives such as cancel_content_publish or update_content_piece. The agent must infer the scenario entirely from 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 already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavioral context — that downstream content derived from the source survives the deletion — which is exactly the kind of consequence an agent cannot get from structured fields. It still omits reversibility and permission 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?

Two short sentences, zero filler, with the core action front-loaded and the scope caveat immediately after. Nothing is wasted.

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

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

For a single-parameter destructive tool with no output schema, the description covers the action and the most important side effect. It lacks any note on irreversibility or on what happens to in-flight jobs tied to the source, but annotations carry the destructiveness signal.

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 the single sourceId parameter, and the description says nothing about how to obtain or format it. The parameter is nonetheless self-explanatory (a required UUID identifying the target source), so the gap is modest rather than crippling.

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 content source'), which inherently separates it from delete_content_piece and delete_influencer. However, it never explicitly contrasts itself with those sibling deletion tools or states scope limits, so it stops short of full sibling differentiation.

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. whether the source must be idle or unlinked), and no mention of alternatives such as update_content_source or reanalyze_content_source. The agent must infer usage purely from 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 already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so the agent knows this is a destructive write. The description's one genuinely additive fact is the cascade: portrait/library images are deleted too. It stops short of stating irreversibility, required permissions, or behavior when the influencer does not exist.

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

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

One sentence, front-loaded with the action and resource, with the cascade scope appended rather than buried. There is no filler or 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 single-parameter destructive delete with no output schema, annotations already carry the safety profile and the description adds the important cascade-deletion detail. It is nearly complete; only irreversibility and not-found/error behavior are unaddressed, which is a minor gap for this complexity.

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

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

Schema description coverage is 0%, so the description carries some burden, but the single parameter 'influencerId' is self-explanatory and the schema supplies type/format/pattern (UUID) plus the required constraint. The description adds nothing about the identifier, which is acceptable but not additive.

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 ('Delete') plus specific resource ('an AI influencer'), with an added scope clause naming the collateral data ('its stored portrait/library images'). This cleanly separates it from the other delete_* siblings (delete_content_piece, delete_content_source, delete_clone_job), which target different resources.

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 never says when to use this tool versus alternatives such as regenerate_influencer, nor does it state prerequisites or exclusions. The only implicit guidance is that this is the removal path for an influencer, which the agent must infer from the verb.

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 destructive=true and openWorld=true, but the description goes well beyond them: it discloses that posts are externally visible, that one monthly video is consumed per variation, that the same variation never hits two accounts or posts twice, that surplus variations spill to next days, that carousels never go to YouTube, and that originals precede translations. This is rich behavioral context an agent cannot get from 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?

The purpose is front-loaded and every sentence carries operational detail, but the single dense paragraph packs scheduling rules, language ordering, and platform constraints into a run-on that is hard to scan. It is information-dense rather than padded, so it largely earns its length.

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 9-parameter mutation with no output schema, the description is nearly complete: it covers the scheduling algorithm, dedup/idempotency behavior, language ordering, platform constraints, cost, and even notes per-entry results. The only minor gap is the absence of expected error/idempotency-conflict behavior, which an agent would want for a destructive 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 78%, putting the baseline at 3, but the description adds genuine meaning: the plan vs server-planned mutual exclusion, that languages selects which variations to hand out (with 'original' semantics), and the per-account-per-day counting rule tied to timeZone. It stops short of explaining jitterMinutes or idempotencyKey semantics beyond what the schema already notes.

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 with clear scope: it spreads DIFFERENT variations of one cloning job across the brand's social accounts at staggered times. This is distinguishable from siblings like add_clone_variations, save_clone_variation_to_library, and publish_content 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 lays out the two invocation modes (server-planned via socialAccountIds+startAt+spacingMinutes vs explicit plan entries), names the sibling tools that supply inputs (get_clone_job for pieceIds, list_publish_destinations for account ids), and states prerequisites (variations must be rendered and not already scheduled). It also notes that re-calling only fills gaps, which prevents accidental duplicate scheduling.

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 (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description still adds real behavioral context: no credits are spent, variations persist on the cloning job until saved or scheduled, and slide count is unknown pre-download so photo links are assumed at six slides. It stops short of stating auth/brand 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?

The lead sentence correctly front-loads the action, and the pricing behavior is stated plainly. However, the elaboration on Prolifik's brand-voice reproduction ('paraphrased copy, subtly changed visuals, the brand's logos') is product marketing that does not help an agent decide or invoke the tool, so not 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?

With no output schema and no annotations describing the response, the description should clarify what the quote actually returns (credit amount, structure), which it only gestures at. It is reasonably complete on the input side for `url` but omits the `variations` parameter and the return shape.

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 full burden. It does characterize the `url` parameter well (TikTok or Instagram, photo carousel or wall-of-text video), but the `variations` parameter (1-8) is never mentioned, so its effect on the quote is left completely unexplained.

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

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

States a specific verb (quote/estimate) and resource (a clone) and makes the key distinction from the actual cloning flow explicit: 'This quotes what one clone would cost in AI credits, spending nothing.' It does not name the sibling tool (clone_post) that performs the real operation, but the read-only framing makes the difference inferable.

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 rather than stated: the estimate is meant to precede the actual clone. There is no explicit 'use this before X / use clone_post to actually create' routing, and no mention of prerequisites such as whether a brand must exist. Adequate but clearly leaves the when-to-use 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. With no output schema, the description's field list does add useful return-shape context, but it says nothing about auth, error behavior for an unknown ID, or caching.

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 resource and returned fields are stated immediately with zero waste.

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-param read tool whose annotations carry the safety profile, the definition is adequate, and the field enumeration partially substitutes for the missing output schema. Gaps remain around the ID parameter and failure modes.

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

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

Schema description coverage is 0% and the description never mentions brandId, so it does not compensate for the undocumented parameter. Only the singular 'a brand's' implicitly signals that one brand identifier is the target.

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 (Get) and resource (brand) and enumerates the concrete fields returned (voice, audience, colors, logo, posting schedule), which lets an agent distinguish it from list_brands and update_brand. It stops short of explicitly naming those siblings, so it isn't 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 mention of prerequisites (e.g. needing an existing brandId), and no routing to alternatives like list_brands for discovery. The verb 'Get' implies a single-record retrieval, but nothing is 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 readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds that clips are returned alongside the job, but says nothing about pagination or result size of the clips list.

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 no filler, though it is brief enough that more useful context could have been added at minimal cost.

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?

Adequate minimum for a one-parameter read tool, but it omits how this differs from get_clip_job_status and does not hint at the structure of the returned clips, which are central to the tool's purpose.

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

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

Only one parameter (jobId) with 0% schema description coverage, so the schema does not document it. The description mentions the job but gives no detail on the identifier's format or provenance; baseline 3 applies for a single-param tool.

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

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

Clear verb+resource: retrieves a Clipper job along with its generated clips. This distinguishes it from get_clip_job_status, which likely returns only status. However, it does not explicitly name or contrast with that sibling, so it falls 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?

No when-to-use guidance is provided. The existence of both get_clip_job and get_clip_job_status creates ambiguity that the description never resolves, so an agent gets no routing help.

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 the useful fact that the response includes progress and clip count, but says nothing about polling cadence, job state transitions, or failure states that a poller needs.

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

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

One sentence, front-loaded with the verb and resource, and it names the three returned fields without padding. Nothing in it 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?

With no output schema, the description does carry partial return-value disclosure (status, progress, clip count), which is the right instinct. However, for a polling tool it omits the transitional-state behavior and any parameter documentation, leaving the agent guessing about call frequency and termination.

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 the single jobId parameter, so the schema supplies only type and length constraints. The description implies jobId identifies the Clipper job but adds no format, source, or provenance detail beyond that inference.

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 ('Poll') and resource ('Clipper job'), and narrows scope to status, progress, and generated clip count, which separates it from list_clip_jobs. It does not explicitly distinguish itself from the sibling get_clip_job, leaving some ambiguity about which read tool returns what.

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?

'Poll' implies a repeated-call pattern after job creation, so usage is implied rather than stated. There is no explicit statement of when to prefer this over get_clip_job or list_clip_jobs, and no guidance on terminal states or when to stop polling.

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. Above that bar, the description discloses exactly what is reported (balance, plan allowance, queue eligibility), which frames it as a decision-support read rather than a raw counter.

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

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

A single sentence that front-loads the primary resource and appends the two secondary outputs. No filler, no redundancy 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 parameterless read-only tool with no output schema, the description enumerates the returned facts clearly enough to call it correctly. It stops short of stating the unit or format of the balance, but nothing essential is missing.

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

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

The tool takes zero parameters, so there is nothing for the schema to document and nothing the description needs to compensate for. Baseline 4 applies.

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

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

States a specific verb and resource ('Read the account's clip-minute balance'), plus the scope (billing period) and the auxiliary facts returned (plan allowance, queue eligibility). An agent can distinguish it from get_studio_credits or get_usage by subject matter, though the description never names 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?

The phrase 'whether a new job can be queued' implies the pre-flight use case, so usage is reasonably inferable. However, it never states when to prefer this over other balance/credit tools, nor any exclusion or prerequisite.

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: what the response contains and the lifecycle rule that 'Variations stay on the cloning job until saved to the Library or scheduled.' It does not discuss rate limits or pagination, but for a read poller that is minor.

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 core information ('This returns one job...') is buried in the third sentence, behind two sentences that describe the cloning feature generally and read as belonging to clone_post. The content earns its place in context but is not front-loaded around this tool's purpose.

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 correctly takes on the burden of describing the return value (status, analysed source post, variations), and read-only annotations cover the safety profile. An agent has enough to call it and interpret the result, with the only gap being the jobId's origin/format.

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

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

Schema description coverage is 0%, so the description must carry the burden for the single jobId parameter. It implies the id originates from clone_post ('Poll it after clone_post'), which helps, but it never states what jobId represents or its format. This is a partial compensation, not a full one.

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+resource ('returns one job: its status, the analysed source post, and every variation built so far'), which is more than the tautological title 'Get cloning job'. It implicitly separates itself from list_clone_jobs by emphasizing it returns a single job, though it does not name the sibling explicitly. The opening two sentences explain the cloning feature broadly rather than this specific tool.

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 explicit workflow guidance: 'Poll it after clone_post until status is "ready".' This tells the agent when and how to invoke it relative to clone_post. It lacks any explicit exclusion or mention of list_clone_jobs as the alternative for multiple jobs, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context in revealing that media URLs are 'signed' (i.e., time-limited), but says nothing about job-state semantics, polling cadence, or behavior when the job has not finished.

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 the action front-loaded and zero filler. Every clause contributes (polling intent, script output, media URL output).

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 return-value semantics, and it does name the two payload classes. However, for a polling tool it omits the critical completeness signal — how to tell a job is finished, and what a pending/failed job returns — leaving a real gap.

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% — jobId carries only type/format constraints with no prose. The description indirectly ties jobId to a 'content job', which is a weak but real anchor, and the parameter is largely self-evident given the tool name. No format, sourcing, or error semantics are added.

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 (poll/retrieve) and resource (content job) and names what it returns (scripts plus signed rendered-media URLs). It does not, however, explicitly distinguish itself from the very similar sibling get_clip_job, so an agent must infer the content-vs-clip split.

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?

'Poll a content job' implies the usage pattern (repeatedly call after create_content_job until complete), which is more than nothing. But there is no explicit when-to-use, no mention of the get_clip_job alternative, and no statement of what to do when the job is still pending.

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=false, so the safety profile is covered. The description usefully discloses that the payload includes a script and signed media URLs, but says nothing about URL expiry, missing-piece behavior, or whether regeneration state is reflected.

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 returned artifacts are named immediately after the primary action.

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 correctly takes on the job of naming the return payload (piece, script, signed media URLs), which is the key information an agent needs. It stops short of error/edge-case behavior, but for a one-parameter read this is close to sufficient.

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

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

One parameter (pieceId) with 0% schema description coverage and no format explanation in the description. The name is largely self-explanatory given 'Get one content piece', but the description adds no syntax or scoping detail beyond what the schema's uuid pattern already enforces.

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 (Get) and resource (one content piece), and adds that the response bundles the script and signed rendered-media URLs. That return-scope detail distinguishes it from list_content and get_content_source, though no sibling is named explicitly.

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

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

No when-to-use guidance, no prerequisites, and no routing to alternatives such as list_content (for enumeration) or get_content_source (for the source asset). The agent must infer from the name alone that this is the single-item fetch.

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 that the response includes live 'provider status', which is useful context, but says nothing about latency, freshness, or what happens when the publication is still pending.

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 efficiently front-loaded sentence with no filler. It is brief enough that nothing needs trimming, though it could afford one more clause given how little it says.

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

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

For a single-parameter read tool with no output schema, the description conveys the gist of the return value but omits any explanation of the id, error behavior for unknown/expired publications, or the relationship to the sibling lookup tools.

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

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

Schema description coverage is 0% for the single required publishId parameter; only the type/format/pattern convey meaning. The description does not mention the id at all, so it adds no 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 and resource ('Get one content publication record') and adds what it returns ('current provider status'). It is distinguishable from the plural sibling list_content_publishes, though it never explicitly names that sibling or the related update_content_publish.

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

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

No guidance on when to use this versus list_content_publishes or get_content_job, and no prerequisites stated. The agent must infer that this is a single-record lookup keyed by an id.

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 safety is covered. The description adds the polling semantics (status may not be final on first call), which the annotations cannot express. It does not describe terminal statuses, error states, or what 'structured content analysis' contains.

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

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

A single sentence that front-loads the polling purpose and appends the retrieval payload. No wasted words 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?

No output schema exists, so the description carries the return-value burden, and 'structured content analysis' is left unelaborated — an agent cannot tell what fields to expect or whether a pending status is a normal first response. For a status-polling tool, a note on retry/terminal states would close the gap.

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?

One parameter with 0% schema description coverage, so the schema supplies only type/format/pattern and no human meaning. The description's 'one source's' ties the id to a content source, which is marginal added value; it says nothing about where the sourceId comes from (create_content_source or list_content_sources).

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 (poll / retrieve) and the exact resource: one source's analysis status plus its structured content analysis. An agent can distinguish it from list_content_sources (plural) and from the create/delete/reanalyze siblings. It does not explicitly differentiate itself from get_content_job or get_content_piece, which is the only gap.

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 'poll' implies an iterative use pattern (call repeatedly until analysis completes), which is real, if implicit, guidance. There is no explicit when-to-use/when-not statement and no named alternative such as reanalyze_content_source or list_content_sources for discovery.

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 useful behavioral context by disclosing that it returns signed image-library URLs, but it omits whether those URLs expire, auth requirements, or error behavior on a missing/invalid id.

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 verb front-loaded and no filler. It is appropriately sized, though 'signed image-library URLs' is slightly cryptic without further elaboration.

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

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

There is no output schema, so the description must convey return values; it names the influencer plus signed image-library URLs, which is a reasonable partial account. However, it leaves key details (URL expiry, full returned shape, error cases) unstated for a single-param fetch 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 description coverage is 0% for the single required influencerId parameter, and the description adds no meaning about it — it never explains the id, its format (UUID), or how to obtain it. With the description carrying the full burden and failing to do so, it falls below the schema-documented baseline.

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 (get) and resource (one reusable AI influencer) and notes it returns signed image-library URLs. The word 'one' implicitly distinguishes it from list_influencers, and the resource differs from create_/delete_/regenerate_influencer. It stops short of naming any sibling explicitly, so it's clear but not maximally differentiated.

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 guidance or mention of alternatives. The singular 'one' weakly implies fetching a single record by id versus listing, but the agent must infer the selection condition 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 already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered without the description's help. The description adds only the notion that 'current' balance and plan are read, which is mildly useful scope context but no auth requirements, rate limits, or freshness caveats.

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. It names the operation and the two returned values immediately, with nothing trailing that could be cut.

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 tool with no output schema, the description carries the burden of describing the return payload and does name both components (credit balance and plan). It is nearly sufficient; a brief note on what units or plan fields look like would close the last gap.

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 nothing for the description to explain. Per the rubric this is the baseline-4 case: there is no parameter semantics gap to fill.

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 (Read) and resource (the account's AI Studio credit balance and plan), so an agent knows the exact data returned. It does not, however, distinguish itself from adjacent read tools such as get_usage or get_clip_minutes, which plausibly return overlapping account-level quota information.

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 offers no when-to-use guidance, no prerequisites, and never names an alternative. With siblings like get_usage and get_clip_minutes in the same family, a routing cue (e.g., credits vs. consumption) would be the most valuable thing this description could add, and it is absent.

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

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

Annotations already establish a safe, read-only, non-open-world operation, so the description only needs to add operational context. It does so meaningfully by disclosing the polling model and the fact that outputs are returned as signed URLs on completion, implying the result may be incomplete on early calls and that URLs are likely time-limited. It stops short of describing the in-progress response shape.

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, front-loading the action (poll) and the payoff (signed output URLs). 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?

There is no output schema, so the description must characterize returns; it does so by naming signed output URLs on completion. It is nearly complete for a simple one-parameter poll tool, with the only gap being the response shape when the generation is not yet finished.

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 the single required generationId parameter, so the description must carry the load. It implies the parameter identifies the generation to poll, but adds no format, sourcing (e.g., from create_studio_generation), or error semantics beyond the self-evident UUID name.

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

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

The description states a specific verb and resource: polling one AI Studio generation and retrieving signed output URLs. It is clearly distinct from list_studio_generations and create_studio_generation, though it does not explicitly name those siblings to route the 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?

"Poll" implies the intended workflow (call repeatedly until completion), and "when it completes" hints at the terminal condition. However, no alternatives are named and there is no explicit guidance on polling cadence or what to do if the generation is still in progress.

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 (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower, and the description still adds real substance: counting rules for both meters (each piece counts once; retries, regenerations and edits all consume renders), the presence of limits and reset dates, and the trial-mode shape. It does not mention auth requirements or caching/refresh behavior, keeping it out of 5 territory.

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 two meters and their counting rules, then adds constraints and trial behavior; nearly every clause carries information an agent cannot get from the empty schema. It is dense to the point of being slightly run-on ('Each content piece is one render' partly restates the parenthetical), which keeps it from a 5.

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 does: it names the two counters, their counting rules, limits, reset dates, and the trial-specific fields (end date, content-job videos left). It leaves the exact response shape and units only loosely specified, but it is adequate for a zero-parameter read 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?

The tool takes zero parameters, so the schema has nothing to explain and the baseline of 4 applies. The description correctly avoids inventing parameter semantics for a parameterless call.

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

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

States a specific verb+resource: returns this month's plan usage, broken into 'videos kept' and 'renders used', with limits and reset dates. An agent can tell it reports account-level consumption rather than job status. It does not explicitly differentiate itself from close siblings like get_studio_credits or get_clip_minutes, which also report usage/credits, so it falls 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?

Usage is implied rather than stated: the mention of limits, reset dates, and the rule that a content job exceeding renders.remaining is refused hints this is the pre-flight check before create_content_job. However, it never names an alternative (get_studio_credits, get_clip_minutes) or states when not to use it, so the agent must infer 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds one genuine behavioral detail beyond that – results include the account-plan activation status of each brand – but says nothing about pagination, filters, or result size.

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 waste. 'Prolifik workspace' is lightly redundant with the context but it usefully pins the scope, so the 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 with no output schema, the description is sufficient: it states the resource, the scope, and the extra datum (plan activation) the caller gets back. Only the shape/volume of the returned list is left unspecified, which is a minor gap.

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 nothing for the description to disambiguate; the baseline for a parameterless tool 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?

Specific verb (List) plus resource (brands) with a scope qualifier (Prolifik workspace). An agent can distinguish it from get_brand, create_brand, and update_brand by the list/read semantics, though the description never names 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?

Usage is only implied: 'list' versus the sibling 'get_brand' suggests this is the enumerate-everything call and get_brand the single-record call, but no when-to-use, prerequisites, or alternatives are 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered and the bar is lower. The description adds that results are scoped to the authenticated account and sorted newest-first, but says nothing about pagination behavior, default result count, or result contents.

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 and no repetition of the title's information. It is efficient, though it is efficient partly by saying very little.

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 list endpoint with no output schema, the description never tells the agent the response is paginated or how many items come back by default; pagination is only inferable from the schema's 'before' text mentioning nextCursor. Adequate but with a clear gap for a list 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 description coverage is 50%: 'before' is documented thoroughly in the schema (cursor vs ISO-8601 with the millisecond-skip caveat), while 'limit' carries only type/default/bounds. The description adds nothing about either parameter, but the self-explanatory 'limit' schema and the rich 'before' doc keep the baseline at 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 ('List ... Clipper jobs') plus scope ('the authenticated Prolifik account's') and ordering ('newest'). It is distinguishable from get_clip_job by the plural/collection framing, though the siblings it differs from are never named.

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

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

The description gives no when-to-use guidance, no mention of alternatives such as get_clip_job or get_clip_job_status for single-job status, and no exclusions. The only hint is the word 'newest', which implies a bulk listing.

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 word 'recent' usefully signals an implicit recency window rather than full history, but pagination, result limits, and ordering are left unstated.

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 the verb and resource front-loaded and no filler. It is not under-specified to the point of uselessness, but one clause could have been spent on the filters.

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

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

Three optional, undocumented filters plus no output schema leave the agent guessing how to scope the query and what fields come back. For a list tool with zero schema coverage, the description should at minimum explain the filter dimensions.

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

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

Schema description coverage is 0%, so the description must carry all parameter meaning, and it names none of the three filters (jobId, status, platform). 'Its current status' only loosely hints that status is a filterable field; no value domains or filter interaction is given.

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

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

States a specific verb (List) and resource (clip publish records) plus the returned attribute (current status). The 'clip' qualifier separates it from the sibling list_content_publishes, though the description never names that alternative 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?

No guidance on when to use this versus get_content_publish, list_content_publishes, or the retry/publish siblings. The agent must infer that this is a bulk enumeration tool from the verb 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the 'newest first' ordering and the lifecycle note that variations remain attached to a job until saved to the Library or scheduled, which is genuinely useful. It says nothing about pagination or rate limits.

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

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

Two of the three sentences describe Prolifik's product concept rather than this list tool, which is waste on a read operation, and the actual purpose is buried last. Front-loading the list behavior would make this far more scannable.

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 four parameters, only 25% schema coverage, no output schema, and an enum status filter, the description should explain filtering and pagination behavior. It explains neither, leaving the agent under-informed for a tool whose value lies in its filters.

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

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

Schema description coverage is only 25%, so the description carries the burden of clarifying limit, status, and brandId, and it clarifies none of them. Only the ordering implied by 'newest first' loosely gestures at the `before` cursor param.

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 final sentence states a clear verb and resource ('lists the account's cloning jobs, newest first'), which distinguishes it from get_clone_job. However, the purpose is back-loaded behind two sentences of product-concept framing, and it never contrasts itself with list_clip_jobs or other list_* siblings.

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

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

There is no when-to-use guidance, no mention of when to reach for get_clone_job instead, and no indication of how the status/brandId filters should drive its use. The agent must infer all routing decisions 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds that results include render status, which is genuinely useful context, but says nothing about pagination behavior, result caps, or ordering beyond what the schema implies.

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 the brevity here veers toward under-specification rather than crisp completeness.

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 five loosely documented parameters, no output schema, and no enumeration for the filter fields, the definition leaves an agent guessing how to narrow results or what a page contains. For a listing tool with this much filtering surface, the description does too little.

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 20%: just one of five parameters ('before') is documented in the schema, and the description adds no meaning for limit, format, status, or brandId. An agent gets no hint of what values format/status accept or that brandId scopes the listing, so the description 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 (List) and resource (generated content pieces) plus an extra facet of the response (current render status). It is clear on its own, but it does not distinguish itself from the many adjacent listing siblings such as list_content_jobs, list_content_sources, list_studio_generations, or list_media_library.

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 offers no when-to-use guidance, no prerequisites, and no pointer to alternatives like get_content_piece or list_content_publishes. The agent must infer the scope entirely from the name and the nine other list_* siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds only 'asynchronous', with no mention of ordering, result size, pagination limits, or what a job record contains, so it contributes little beyond the structured fields.

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

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

One short, front-loaded sentence with no filler. It is structurally clean, but borderline under-specified rather than genuinely economical.

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, three parameters, and two of them undocumented, the description should carry more weight than a single clause. Nothing tells the agent what a listed job looks like, how results are ordered, or that brandId scopes the list.

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

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

Schema description coverage is only 33%: 'before' is documented in the schema, but limit and brandId have no description anywhere. The description does not compensate at all — it never mentions pagination, page size, or brand filtering, which are the three actual knobs on the tool.

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

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

States a specific verb (list) and resource (asynchronous Prolifik content-production jobs), which is enough to separate it from get_content_job and the clip-job siblings. It does not, however, draw the line between content jobs and content pieces/sources beyond the noun itself.

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 when to prefer get_content_job vs list_content vs this tool, and no stated prerequisites. The agent must infer context entirely from the name and sibling 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 readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the set of publish states (scheduled, publishing, posted, failed), which is useful operational context, but says nothing about ordering, pagination behavior, or whether the list is scoped to the caller's workspace.

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. It is efficiently written, though its brevity is partly under-specification rather than true tightness.

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 paginated list tool with no output schema, the annotations cover safety and the 'before' parameter documents cursor pagination, so the largest structural gaps are filled elsewhere. Still, the description leaves undefined what the status and pieceId filters do and what ordering the returned records follow.

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

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

Schema description coverage is only 25%: only 'before' is documented, while limit, status, and pieceId have no schema description and no description text. Enumerating the publish statuses indirectly hints at valid status filter values, but the description never explains the status filter, the pieceId scoping, or the limit default.

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 (List) plus resource (content publication records), and it enumerates the record states covered, so the agent knows this is a read of publish records rather than content pieces or jobs. It does not explicitly distinguish itself from the close sibling list_clip_publishes, leaving that differentiation to the token 'content'.

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

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

The description gives no when-to-use guidance, no prerequisites, and never names alternatives such as list_clip_publishes for clip publishes or get_content_publish for a single record. Usage is only implied by the verb '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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one behavioral fact beyond that — only 'analyzed' sources are returned — but says nothing about pagination, ordering, or the cursor semantics that the schema's `before` param warns can skip same-millisecond items.

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, and the scoping qualifier ('analyzed', 'for a brand') comes before anything else. However appropriate, it is arguably too terse for a paginated list tool.

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

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

For a simple read-only list with no output schema, the description covers what is enumerated but not how enumeration works — no mention of paging, default limit, or result ordering. The agent can call it, but cannot reason about paging behavior 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 only 33%: `before` is documented in the schema, but `brandId` and `limit` are not, and the description never mentions them. 'Available to a brand' weakly implies brand scoping, but the limit cap and page-size behavior are 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 ('List') and a specific resource ('analyzed source URLs available to a brand'), which is enough to separate it from list_media_library and list_content. It never names or contrasts a sibling, so the differentiation is left to the agent's 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, no exclusions, and no pointer to alternatives such as get_content_source for a single source or create_content_source for adding one. The agent must guess the retrieval context entirely.

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 structurally. The description adds that results include base-image generation status, which is genuine extra context, but it says nothing about pagination, ordering, or how many records come back. With annotations carrying the main burden, a 3 is appropriate.

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, stating the resource first and the notable return content second. 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 no-argument, read-only list tool whose annotations already cover the safety profile, the description tells the agent what is returned (influencers plus base-image generation status). The absence of pagination or output-shape detail is a minor gap, since no output schema exists to cover 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify about arguments, and it correctly does not invent any.

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 (reusable AI influencers) with an added scope note about base-image generation status, which separates it from get_influencer and the create/delete influencer siblings. It is clear without explicitly naming an alternative sibling, which keeps it 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?

Usage is implied: 'List' signals bulk retrieval of all influencers, contrasted with the sibling get_influencer for a single one, but the description never states when to prefer this over that alternative or any prerequisite conditions. No exclusions or routing guidance are provided.

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

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

With readOnlyHint/destructiveHint already covering safety, the description adds real behavioral context: results are scoped to the caller's own library, AI Studio items require studio:read, ordering is newest-first, and only usableForHookDemo items are valid for job references. It stops short of describing pagination behavior, which matters here.

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 dense sentences with the core content and the key-chaining hint front-loaded; every clause carries real information. Slightly long but 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 list tool with annotations and no output schema, the description usefully explains the `key` field and its downstream use, but leaves the type/limit parameters and pagination semantics an agent needs to call it correctly 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 33% (only `before` is documented), so the description should compensate, but it says nothing about `type` (video/image) or `limit` (max 100, default 50). The usableForHookDemo filter it mentions is not even a parameter, so it adds no meaning to the two undocumented 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 verb (list) and resource (the user's own media library), enumerates the contents (app-uploaded videos, Content Studio demos, and permission-scoped AI Studio outputs). It is clear what the tool returns, though it does not explicitly contrast against the many sibling list_* tools.

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

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

Usage is implied rather than stated: the mention of demoVideoKey/hookVideoKey and the usableForHookDemo qualifier signals this feeds the Video Hook & Demo content jobs, but there is no explicit 'use this when…' or exclusion against alternatives like list_content or list_studio_generations.

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 useful filtering context ('active' accounts, scoped to the active brand), but says nothing about pagination, ordering, or the returned shape.

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. It is efficient, though it is arguably too terse for a tool with an undocumented parameter and no output 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 no output schema, the description should convey what is returned (e.g., account identifiers/names for use in publish_content). It gestures at 'active social accounts' but omits return structure and the brandId default behavior, leaving gaps an agent must guess at.

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 single brandId parameter has 0% schema description coverage, so the description must carry the load. It partially does by framing the result as belonging to the account's 'active brand', hinting that brandId is optional and defaults to that brand, but it never explains the parameter's format or what passing a different UUID does.

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 verb+resource ('List active social accounts') and scopes it to the account's active brand, which distinguishes it from publish-history siblings like list_content_publishes and list_clip_publishes. However, it never names a sibling or clarifies the destination-vs-publish distinction 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, and no mention of alternatives such as list_content_publishes. The only contextual clue is the phrase 'available to the account's active brand', which implies the pre-publish discovery step but leaves the agent to infer it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only "recent," implying recency-ordered results, but says nothing about ordering direction, default limit behavior, or result shape. Adequate but thin given the annotations do most of the work.

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 wasted words. Efficient, though its brevity borders on under-specification rather than crispness.

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 convey return shape/ordering, and it doesn't. Combined with undocumented `limit` and `status` parameters, the definition is too sparse for an agent to invoke confidently beyond the basics.

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%: the `before` cursor is well documented in the schema, but `limit` and the `status` enum carry no descriptions anywhere. The description adds zero parameter meaning (e.g., default page size or what status values filter on), 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 ("List") and a clear resource ("image, video, and talking-head generation jobs"), which lets an agent distinguish it from get_studio_generation (single item) and list_studio_models (models, not jobs). No explicit sibling naming, but the resource scoping 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 description gives no when-to-use context: it doesn't say to use this instead of get_studio_generation for a single job, doesn't mention pagination workflow, and doesn't explain the status filter's purpose. The agent must infer all routing from the tool 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the output includes supported inputs and credit prices, which is genuine extra context, but says nothing about freshness, pagination, or filtering behavior. With annotations carrying the read-only profile, a 3 is appropriate.

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 naming verb, resource, and the three categories of returned data. 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 zero-parameter read-only catalog listing with no output schema, the description tells the agent what the tool returns (models, inputs, prices), which is the key missing piece. It lacks only return-structure detail, but that is minor for such a simple 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?

There are zero parameters, so the baseline is 4. The description correctly frames this as a no-input catalog listing, consistent with the empty 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 (List) and resource (image and video models) and goes further by naming the three things returned: supported inputs and credit prices. An agent can distinguish this catalog-lookup from siblings like get_studio_credits or list_studio_generations without opening a 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 description implies a discovery/catalog use case but never states when to use it versus get_studio_credits or list_studio_generations, nor any prerequisites. Usage is only implied by the verb.

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?

Adds substantial behavior beyond the annotations: 3 AI credits per translation reserved up front with refunds on failure, asynchronous execution requiring polling of get_clone_job, verbatim app/brand names with localized caption/hashtags, and the language/localizedFrom markers on results. This is rich operational context that the openWorldHint/destructiveHint flags do not convey.

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

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

The core translate behavior, cost, and async notes are valuable, but the leading sentences about pasting links and rebuilding variations describe the parent cloning feature rather than this tool, so the payload is not front-loaded and several sentences do not earn their place for a translation call.

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 usefully explains the return semantics (translated variations carry language and localizedFrom) and tells the agent to poll get_clone_job. Combined with cost, refund, and language restrictions, an agent has enough to invoke correctly; only jobId/idempotencyKey semantics are 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?

With schema coverage at 25%, the description compensates well for pieceIds (omit = all finished originals, existing pairs skipped) and languages (each language a new audience, pl/tr restricted to carousels). jobId and idempotencyKey are left undocumented, but both are conventional, so the marginal gap is small.

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

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

The description names a specific verb+resource ('TRANSLATES finished variations into other languages') and makes the distinction from the parent cloning flow explicit by emphasizing each (variation, language) pair becomes a new variation. However, the first three sentences describe the cloning feature in general ('Paste a TikTok or Instagram link... Prolifik rebuilds it...') rather than this tool's job, which dilutes focus before the actual purpose appears.

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?

Offers concrete operating guidance: omit pieceIds to translate every finished original variation, existing pairs are skipped, and Polish/Turkish only work on carousel variations. It also says to poll get_clone_job for completion. It stops short of contrasting with the closest sibling (add_clone_variations), but the when/how conditions are unusually 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 readOnlyHint=false and destructiveHint=true, so the description's added sentence, that this 'creates an externally visible post', supplies the concrete real-world consequence the annotation cannot convey. It stops short of covering permission requirements, irreversibility of an already-published post, or how idempotencyKey affects retries.

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, purpose first and consequence second, with no filler. Nothing could be removed without losing 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 externally visible, irreversible-feeling mutation with four undocumented parameters and no output schema, the description is serviceable but thin. It never explains the idempotency contract or what a successful publish returns, which an agent needs before firing this 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?

Schema description coverage is 0%, so the description must carry parameter meaning, and it largely does not. 'Schedule' weakly implies scheduledFor and 'generated clip' weakly implies clipId, but idempotencyKey and connectionId are entirely unaddressed despite being required/meaningful 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 concrete verb pair (publish/schedule), the resource (a generated clip), and the target (a connected social account), which is enough to separate it from publish_content. It does not name a sibling explicitly, but the 'clip' vs 'content' distinction is inherent in the wording.

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 choose this over publish_content or retry_clip_publish, no mention that a connectionId must first be obtained (e.g. from list_publish_destinations), and no statement about immediate vs scheduled publishing rules.

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 write/destructive/open-world profile, but the description adds the crucial consequence that this 'creates an externally visible social post' — meaning the effect leaves the system and is publicly visible. It still omits retry/idempotency behavior and any rate-limit 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, front-loaded with the primary action and then the scheduling condition; no filler. It is efficiently sized, though it stops short of using that compactness to convey more essential detail.

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

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

For an 8-parameter destructive external-publish tool with 13% schema coverage and no output schema, the description is too thin: it never mentions required identifiers, the idempotency key, connection targeting, or what a successful publish returns.

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

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

Schema description coverage is only 13% (just aiGenerated), so the description must compensate, yet it only explains scheduledAt's effect. brandId, pieceId, connectionIds, caption, hashtags, and idempotencyKey receive no added meaning anywhere.

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 (publish a rendered content piece) and adds the scheduling variant, so the action is unambiguous. It does not explicitly contrast itself with the sibling publish_clip, so the agent must infer the piece-vs-clip distinction from the tool 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?

Gives one clear conditional: schedule by supplying scheduledAt. There is no guidance on when to prefer this over publish_clip, nor on prerequisites (piece must be rendered) or when not to use it.

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

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

Annotations already flag this as destructive (destructiveHint=true) and non-read-only with openWorldHint, so the safety profile is covered structurally. The description adds the meaningful detail that the URL can be overridden, but does not disclose that existing extraction results are discarded or overwritten, which is the key behavioral risk for a destructive re-run.

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 core verb and the optional override are both conveyed without waste.

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 destructive, likely asynchronous operation in a toolset full of job/poll siblings (get_content_job, list_content_jobs), yet the description does not say whether re-analysis returns a job handle or completes inline, nor what happens to prior results. With no output schema to compensate, the definition leaves the agent guessing.

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

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

Schema description coverage is 0%, so the description must carry the load; it clarifies that url is optional and represents a corrected URL ('optionally against a corrected URL'). It says nothing about sourceId beyond what the name implies, leaving half the parameters without added meaning.

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 ('Re-run extraction') and resource ('a content source'), and adds the corrected-URL nuance. It is distinguishable from update_content_source and regenerate_content_piece, though it does not explicitly name those siblings.

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

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

There is no guidance on when to re-analyze versus create/update a source, no prerequisites, and no mention of alternatives such as update_content_source or get_content_source. The agent must infer the scenario entirely.

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 openWorldHint=true, so the bar is lower; the description still adds the meaningful detail of what is discarded and replaced (script plus library assets). It does not cover authorization needs, rate limits, or how idempotency affects repeated calls.

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, with the action and its effect front-loaded and the disambiguation placed second. 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?

There is no output schema, so the description should ideally say what the call returns or what state the piece ends up in, and it should clarify the required idempotency key. It covers the core behavior and the sibling distinction, but leaves the agent under-informed for a destructive operation with two undocumented required parameters.

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, so the description carries the full burden and adds nothing about pieceId or idempotencyKey. For a destructive, non-idempotent-looking write, the absence of any explanation of idempotencyKey semantics is a real 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 ('Replace a failed job piece with a freshly written script and new library assets') and contrasts it with a re-render. It distinguishes the concept from the sibling retry_content_render but never names that tool, so routing requires a small 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?

The second sentence effectively gives a when-not-to-use condition: if you only want to re-render the existing script, this is the wrong action. The alternative is described by behavior rather than by tool name, and no prerequisites (e.g. the piece must be in a failed state) are 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 destructiveHint=true and openWorldHint=true, so the agent knows this is a destructive write. The word 'replace' adds useful confirmation that the existing base portrait is overwritten, but nothing is said about the idempotencyKey requirement, cost/credit implications, or whether the old portrait is recoverable.

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 tightly-written sentence with the destructive action front-loaded and no filler. It may be slightly terse given the tool's mutation semantics, 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 destructive mutation with 0% parameter coverage, no output schema, and only minimal annotations, the description leaves important gaps: parameter roles, the meaning of the required idempotencyKey, and what the response or resulting portrait state looks like.

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 0% and the description explains none of the three parameters. It doesn't clarify that influencerId selects the target, that instructions guide the generation, or that idempotencyKey is required for safe retries.

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 (replace) and resource (the influencer's base portrait), which distinguishes it from create_influencer and delete_influencer. It doesn't name a sibling explicitly, but the operation is unambiguous.

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

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

No guidance on when to prefer this over create_influencer or update_* tools, no prerequisites, and no excluded cases. The agent is left to infer that this regenerates an existing portrait rather than creating a new entity.

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=true and openWorldHint=true, so the safety profile is covered. The description adds a meaningful trait beyond that: the retry 'creates an externally visible post', clarifying the consequence is public and externally observable. It still omits idempotency and prerequisite/repeat-retry behavior.

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 followed immediately by the key consequence. No filler, nothing that could be cut.

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?

Covered: purpose and the externally-visible consequence. Missing for a destructive, open-world mutation: prerequisites for a valid retry, what happens if retried repeatedly, and any description of the publishId parameter. With no output schema, no return-value explanation is required.

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

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

Schema description coverage is 0% and the description never mentions publishId or what value it expects. With only one parameter the name is largely self-describing in context, but the description adds no semantics beyond what the bare schema name already conveys.

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 (retry) and resource (clip publish record), and the 'failed' qualifier implies this targets existing failed publish records rather than creating new ones. It does not name the sibling it contrasts with (publish_clip), so it falls short of full sibling differentiation.

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 'failed' implies the trigger condition (a prior publish that did not succeed), giving implied usage. However, there is no explicit when-not guidance, no prerequisites (e.g. whether the record must still be in a retryable state), and no named alternative such as publish_clip.

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?

Adds real context beyond the annotations: it spends AI credits, it can be refused for unrebuildable posts, and it advises passing idempotencyKey when the prior answer was never seen. It is consistent with destructiveHint=true and openWorldHint=true. It stops short of saying what happens to the original failed job's state or whether a retry is billed on refusal.

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 two sentences describe the general Prolifik cloning feature rather than this tool specifically and even open with 'Paste a TikTok or Instagram link', which is not this tool's input (it takes a jobId). Tool-specific content is valuable but arrives after the domain preamble, so the most actionable sentences are not 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 2-parameter mutating tool with no output schema and no nested objects, the description covers the qualifying state, refusal cases, cost, and idempotency, which is enough to call it correctly. Minor gaps remain around the result of a successful retry and how the retried job is identified back to the caller.

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% because jobId carries no description; the prose compensates by implying jobId must reference a FAILED job with no variations. The idempotencyKey guidance in the description mirrors and slightly extends the schema text (retrying a call whose answer you never saw).

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 (re-runs a FAILED cloning job from the paste) and explicitly distinguishes itself from the sibling that handles the other case (add_clone_variations). An agent can tell retry_clone_job apart from clone_post, get_clone_job, and add_clone_variations without opening a 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?

Gives an explicit precondition (job must be FAILED and have no variations), two explicit exclusions (job already has variations -> use add_clone_variations; post the transform cannot rebuild -> refused), and a retry-safety rule for the idempotencyKey. This is textbook 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 declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation/safety profile is covered. The description adds the precondition that the piece must have failed, which is useful context, but says nothing about what the retry actually does (re-queue the render?), whether it is safe to call repeatedly, or any auth/rate constraints.

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 action, target, and precondition all land in the first clause.

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

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

For a mutation tool with no output schema and 0% parameter documentation, the description is too thin: it omits the semantics of the required idempotencyKey, the expected outcome of a retry, and how to choose this over regenerate_content_piece. Annotations cover safety but not the operational behavior an agent needs.

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 full burden, and it only indirectly hints that pieceId identifies the failed content piece. The required idempotencyKey – the most semantically important parameter for a retry operation – is never explained, leaving the agent to guess its dedupe/retry-safety role.

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+resource ('Retry the render worker') and narrows scope to a 'failed content piece', so the agent knows this is a recovery action rather than a fresh render. It does not, however, distinguish itself from the sibling regenerate_content_piece, which an agent could easily confuse with this tool.

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 phrase 'for a failed content piece' – retry only makes sense after a failure. But no explicit when-to-use/when-not guidance and no alternative is named (e.g., regenerate_content_piece vs create_content_job), leaving the agent to infer the boundary.

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 openWorldHint=false, so the safety profile is known. The description adds useful lifecycle context (variations remain on the cloning job until saved or scheduled) but does not reveal whether the operation copies or moves the piece, whether others are affected, or whether it is reversible.

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 three sentences are expository background about the cloning pipeline and belong to a different tool; the actual action is buried in the last sentence. Content is not front-loaded around what this tool does, making the definition inefficient for selection.

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 does not explain the effect on the piece itself (move vs copy vs duplicate), what happens to un-saved variations, or where the saved item appears beyond naming list_content. For a 1-required-param mutation tool, key operational details are missing.

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

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

With only one parameter at 0% schema description coverage, the description carries the full burden, yet it never mentions pieceId, its UUID format, or how to obtain a variation's id. The phrase 'one finished variation' weakly implies selecting a specific piece but gives no actionable parameter guidance.

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

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

The name and final sentence ('This keeps one finished variation: it is admitted to the Library') do state the specific verb+resource, but the opening three sentences describe the upstream cloning/rebuild process rather than this tool's action, so the purpose is muddled and the agent must read to the end to recover it. It also does not distinguish itself from the sibling add_clone_variations.

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?

'Variations stay on the cloning job until saved to the Library or scheduled' implies when to persist a variation, and the mention of list_content/publish_content indicates the downstream context. However, there is no explicit when-to-use condition, no exclusion, and no comparison to add_clone_variations or regenerate_content_piece.

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 and destructiveHint=true, so the safety profile is partly covered. The description adds the scope of what is mutated (the enumerated fields), but it does not warn what the destructive flag means here — e.g. whether omitted nullable fields are cleared — nor discuss permissions. It clears the lower annotated bar but adds only modest context.

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

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

A single front-loaded sentence with no filler, listing the mutation surface efficiently. It is well-sized, though for an 8-parameter mutation the terseness edges toward under-specification rather than true conciseness.

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

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

For an 8-parameter destructive mutation with nested objects, nullable fields and no output schema, one sentence leaves important gaps: partial-update semantics, brandId requirement, and how null values affect existing data. The description is not complete enough for an agent to call this safely without guesswork.

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

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

Schema description coverage is 0% across 8 parameters, so the description must carry the burden. It conceptually groups several fields (visual identity covers logoUrl/primaryColors, audience covers targetAudience, schedule covers postingSchedule), which adds mild meaning, but it never addresses the required brandId or the standalone description field and gives no format or clearing 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 (Update) and resource (brand) and enumerates the mutable facets (name, voice, visual identity, audience, posting schedule), which clearly distinguishes it from create_brand, get_brand and list_brands in the sibling set. It stops short of naming those siblings explicitly, so an agent infers the routing rather than being told 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 prerequisites such as needing an existing brandId, and no statement about whether this is a partial or full replacement update. The agent must 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 already declare this as a destructive, non-read-only, open-world mutation, so the safety profile is covered. The description usefully adds that the render is asynchronous ('the piece shows the new render once it finishes'), but it omits that existing copy/logo is overwritten and says nothing about idempotencyKey semantics, which matter for a destructive retryable write.

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

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

Two short sentences, front-loaded with the action and scope, followed immediately by the async render consequence. No padding or restated title 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?

For a 7-parameter destructive mutation with 0% schema coverage and no output schema, the description is under-specified: it does not explain idempotency behavior, what happens to the prior render, or failure/retry handling, though the async completion note covers the return-value gap.

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

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

Schema description coverage is 0%, so the description must compensate; it loosely covers the editable fields (copy: cta/body/hook/slides, logo: includeLogo) but says nothing about pieceId or idempotencyKey, leaving two required parameters and their uniqueness/retry semantics undocumented.

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

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

States a specific verb (Edit) and resource (a generated piece's copy or logo setting) plus the side effect of queuing a replacement render. It is distinguishable from regenerate_content_piece or retry_content_render, though it never explicitly contrasts itself with those siblings.

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

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

The description implies the use case (modify existing copy/logo, not regenerate or retry), but it does not state when to prefer this over regenerate_content_piece, retry_content_render, or delete_content_piece, nor any preconditions such as piece state or required permissions.

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 readOnlyHint=false, so the mutation/risk profile is covered. The description adds one genuinely useful precondition — the content must not have posted yet — but says nothing about permissions, partial-vs-full replacement of caption/hashtags, or error behavior when the publish already went 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?

A single tight sentence with the scope condition front-loaded; nothing is wasted. It is arguably too terse rather than padded, but sizing itself is appropriate.

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

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

For a mutation tool with no output schema and zero parameter descriptions, the description covers the core intent and the unposted precondition but omits prerequisites, what a successful response contains, and the identity of the required publishId. 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 description coverage is 0% for 3 parameters, so the description has to compensate. It identifies two of the three mutable inputs (caption, hashtags) but leaves publishId unexplained and gives no constraints (2200-char caption, 30-hashtag cap) that the schema supplies only structurally.

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?