Unsora

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and repeatability are covered. The word 'single-shot' adds real value by implying a non-blocking poll in contrast to the wait_for_* siblings, but the description stops short of saying whether the call returns immediately or what status values can come back. No contradiction with annotations.

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

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

A single short sentence, front-loaded with the core purpose. The trailing parenthetical is low-value and could be dropped, but there is no padding or repetition.

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

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

With no output schema and 0% parameter description coverage, the description carries the full burden and falls short. It omits what the status response contains, how pending/complete/failed states are surfaced, and how this poll relates to the wait_for_* tools, leaving an agent unable to use it confidently.

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

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

Schema description coverage is 0% and the description says nothing about either parameter. It does not explain that 'id' is a generation identifier nor why the 'tool' discriminator is needed on an audio-named endpoint. The 12-value enum is visible in the schema, but the meaning of the fields is left entirely 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?

It states a verb+resource ('generation status check') and adds a scoping qualifier ('single-shot'), so an agent gets the general idea. But it never resolves how it differs from the sibling image_status, video_status, and clipping_status tools, nor why an 'audio_status' tool accepts an enum spanning image, video, music, and voiceover. The parenthetical '(used by the preview UI)' is implementation noise rather than clarification.

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 and no mention of the obvious alternatives such as wait_for_video, wait_for_image, or video_status. The only contextual hint, '(used by the preview UI)', arguably steers the agent away from the tool rather than telling it when to call 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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses cost (~10 credits/minute), a hard 5-minute source limit, accepted input types, the async/polling nature of the operation, and the output behavior ('renders a live audio player'). These are exactly the traits an agent needs before invoking and typically missing from 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?

A single dense paragraph, front-loaded with the core action and transformation, then constraints, cost, id sourcing, polling, and output. Every sentence adds a distinct, non-redundant fact with no filler.

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

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

For a 3-param async mutation tool with no annotations and no output schema, the description covers purpose, input constraints, cost, id source, polling path, and output rendering. An agent has everything needed to call it correctly and know what to expect.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including the cloned-voice constraint on voiceId and video acceptance for sourceUrl. The description largely reinforces the schema (cloned voice id, audio-or-video source) rather than adding new syntax or format detail, so the baseline 3 applies.

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

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

States a specific verb+resource ('Re-voice existing speech into one of the user's cloned voices', with 'Voice Changer, speech-to-speech' as a gloss) and clarifies the transformation ('keeps the timing and delivery of the source, swaps the voice'). This clearly separates it from sibling create_voiceover (text-to-speech) and create_voice_clone (voice creation), which an agent can distinguish 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 clear usage context: source must be audio or video up to 5 minutes, voiceId must come from list_voices, and results should be polled with wait_for_voiceover. It routes the agent to the right supporting tools, though it never states an explicit 'do not use this for X' exclusion (e.g., versus create_voiceover for text input).

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

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

Annotations already declare readOnly, idempotent and closed-world behavior, so the safety profile is covered. The description still adds useful traits beyond that: it is single-shot (no waiting/polling) and returns clips in addition to status, which matters since there is no output schema.

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

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

A single front-loaded sentence with no filler. It is efficient, though borderline terse given how much remains unexplained about the return content.

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

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

With no output schema, the description should carry return-shape burden; it only notes '+ clips'. It omits the possible status values, error/failure states, and how to interpret an in-progress job, leaving the agent to infer polling semantics.

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?

Both parameters (id, tool) have 0% schema description coverage and the description adds no meaning for either. The 'tool' enum is self-evident from the schema, but 'id' (job id) is never clarified, 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 resource and action: AI clipping job status plus clips for a given job id. 'Single-shot' implicitly distinguishes it from the polling-style sibling wait_for_clipping, 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?

The parenthetical '(used by the preview UI)' describes an internal consumer rather than telling an agent when to call this instead of wait_for_clipping or create_clipping. No when-to-use or when-not-to-use guidance is provided.

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

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

Annotations establish the safety profile (not read-only, not destructive), and the description adds real context beyond them: the tool returns the upload plus its URL, and in app-capable hosts renders as an interactive panel that must not be re-serialized in the reply. The panel-rendering contract is substantive and not derivable from 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?

Front-loads the core action, then the return, then the rendering caveat; each sentence carries information. The panel instruction is slightly digressive but genuinely necessary to prevent redundant output, so it 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?

No output schema exists, and the description compensates by stating the return (the upload with its URL). Combined with annotations covering the mutation safety profile, an agent has what it needs to invoke and report this tool 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 100%, so the schema already documents both blobName (from create_upload_url) and fileName (display name). The description only alludes to these indirectly and adds no syntax or format detail, so baseline 3 applies.

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

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

States a specific action (add a file to the user's library) tied to the preceding create_upload_url flow, and names the resource precisely. An agent can distinguish this finalization step from upload_file and list_uploads without reading schemas.

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

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

Clearly roots the tool in the create_upload_url workflow and lists where the returned URL applies (create_post media, reference images, clipping input). It stops short of contrasting with the sibling upload_file, which an agent might reasonably confuse for the same job.

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

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

With no annotations, the description carries the full burden and does well: it discloses that this is an interactive UI invocation, that the composer performs the actual creation, and that the host must support apps or the workflow falls back to create_post. It does not cover auth requirements, what the call returns (e.g., whether the created post is returned), or how long the composer session lives.

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

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

The first sentence is a long enumeration but it is front-loaded with the core action and the 'composer creates the post itself' clarification. The subsequent usage sentences all earn their place; only the long per-platform list is arguably more detail than an agent needs.

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

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

For a zero-required-param UI-opening tool with no output schema and no annotations, the description covers the important behaviors: host requirement, prefill expectation, and the do-not-double-create rule. It leaves the return value of the call unspecified, which is the main remaining 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 coverage is already 86% and the schema documents title, mediaType, mediaUrls, accountIds, and scheduled_at clearly. The description restates some of this and adds per-platform option names (YouTube visibility, TikTok privacy/duet/stitch, Pinterest board, etc.) that are not actual parameters, which risks confusing the agent about what can be passed. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource (open the interactive post composer) and immediately clarifies the crucial distinction that the composer, not this tool directly, creates the post. It is unmistakably separable from the sibling create_post, list_posts, and update_post.

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 when-to-use ('whenever the user wants to create or schedule a post and the host can show apps'), a prefill instruction, an explicit when-not ('do NOT call create_post yourself after it opens'), and names the alternative path (call create_post in hosts without app support). This is a complete routing rule.

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

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

With no annotations, the description carries the disclosure burden and does well: it names the 10-credit cost, discloses the asynchronous job nature requiring wait_for_video polling, and mentions live preview behavior in app-capable hosts. It stops short of saying what happens on failure or whether credits are refunded.

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?

Four tight sentences, front-loaded with the core action and mode selection before cost, routing and polling hints. 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?

Covers the essentials for a 7-parameter async generation tool with no output schema: cost, polling, voice sourcing, and dual input modes. Missing only edge-case behavior such as failure/refund handling and validation limits already visible in the schema.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds value beyond it by explaining where voiceId comes from (MiniMax presets, Eleven v3, cloned voices via list_voices) and by framing voiceId/transcript versus audioUrl as alternative input paths.

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 ('Turn a portrait into a talking-head video') and names the underlying engines (AI Avatar Maker, SkyReels V3). The two operating modes (transcript+voiceId vs audioUrl lip-sync) make it clearly distinct from siblings like create_video, create_influencer or create_motion_control.

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 routes the agent to list_voices for voice selection and to wait_for_video for polling, and explains the condition selecting each of the two audio modes. It does not state when-not-to-use it (e.g. versus create_video for non-avatar footage), so no exclusions are covered.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses that the call spends the user's credits, requires a public videoUrl, renders a live preview in capable hosts, and that polling must be skipped there. It does not cover failure behavior, credit cost magnitude, or processing time, so it stops just short of a 5.

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

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

Front-loaded with purpose, then prerequisites, then host-conditional polling guidance — a sensible order. It is long for a description and repeats itself ('never assume defaults, never infer unstated preferences' restates the preceding sentence), but almost every clause carries routing or constraint value.

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 credit-spending, 9-parameter tool with no annotations and no output schema, the description covers the critical unknowns: consent gating, input URL constraints, preview rendering, and the polling alternative. The gaps are secondary parameter definitions (sourceLang/targetLang/limit) and any statement of what the call 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 coverage is 56%, so the description must compensate, and it partly does: it frames the user-facing choices (aspect ratio, captions/style, number of clips, clip length) and explains that clip length is irrelevant when query is set. However sourceLang, targetLang, and limit remain unexplained in both places, and the ratio/captionStyle enum semantics come from the schema rather than the description.

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

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

Opens with a concrete verb+resource ('Turn a long video into short clips') and enumerates the request types it covers (clip, cut, chop, trim, repurpose, find moments). It also names the siblings it coordinates with (wait_for_clipping, clipping_status), so an agent can separate it from the status/polling tools without opening schemas.

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?

Explicit when-to-use (any clipping/repurposing/highlight request), explicit gating (do not call until the user chose aspect ratio, captions, clip count, clip length), and explicit host-conditional behavior for polling. This is close to a complete decision procedure, including what to do instead in preview-capable vs preview-less hosts.

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

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

With no annotations, the description carries the full burden and does well: it discloses the async lifecycle (returns generation.id, poll with wait_for_image), live pricing and credit refusal via maxCredits, automatic import of externally hosted media, and live preview in app-capable hosts. It omits auth requirements, rate limits, and idempotency behavior, keeping it below 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?

Purpose is front-loaded in the first sentence, followed by tight, information-dense clauses covering models, inputs, pricing, and polling with no filler. The model enumeration is slightly long, but every sentence carries actionable content.

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

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

For a 6-parameter, nested-input tool with no output schema and no annotations, the description covers the full call lifecycle: model selection, input construction, cost guardrails, return value, and follow-up polling. Only permission/prerequisite context is missing.

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

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

Schema coverage is 83%, so the baseline is 3, and the description adds genuine meaning beyond it: attaching `images` inside `inputs` means edit/reference, `mode`/`model` keys come from list_models, and omitted fields fall back to model defaults. This enriches the nested `inputs` object that the schema only partly documents.

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 ('Generate an image') and names concrete use cases (social post, thumbnail, ad creative). It is clear what the tool does, but it does not explicitly differentiate itself from core siblings like create_thumbnail or create_image_and_schedule, which overlap with the stated use cases.

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

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

Gives explicit routing for the workflow: see list_models for per-model inputs, get_price for live pricing, and wait_for_image to poll. It also explains that attaching `images` in inputs switches to an edit/reference flow. It stops short of stating when NOT to use it versus the scheduling/thumbnail variants.

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

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

With no annotations, the description carries the full burden and does disclose real behavioral traits: the internal generate→wait→schedule sequence, automatic padding when ratios don't match, and the host-dependent interactive-panel rendering with an explicit instruction not to duplicate its contents. It still omits auth/permission needs, what happens on partial failure, and scheduling 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?

Front-loaded with the tool's purpose, then the pipeline, then the conditional guidance, then the host-behavior note — a sensible ordering with little filler. The final sentence is dense but each clause carries distinct instructions.

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 combined tool with 7 params, no output schema, and no annotations, the description covers the operation flow and rendering behavior well but leaves key invocations underspecified. An agent still lacks semantics for most inputs and any failure-mode or dependency information.

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 14% (just 'model'), so the description must compensate for six largely undocumented parameters. It only adds meaning for aspectRatio (4:5/1:1 preference and padding behavior); prompt, caption, accountIds, resolution, and scheduled_at are left with no format, constraint, or intent explanation.

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

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

The description uses a specific verb pair and resource: 'Generate an image for a social post and schedule it in one step,' and even spells out the internal pipeline (create image → wait → schedule slideshow post to accounts). This clearly distinguishes it from atomic siblings like create_image and create_post without naming them, though it never explicitly contrasts itself against those alternatives.

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 'in one step,' suggesting it is the combined-operation choice when a user wants both generation and scheduling, but there is no explicit when-to-use vs. when-to-decompose guidance. The only concrete conditional rule ('If any target account is Instagram, prefer aspectRatio 4:5') is parameter-shaped rather than routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the async/preview-grid behavior and the need to poll ids, but omits credit cost, whether the prompt is free-form or safety-filtered, and what happens on multi-count requests.

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, zero filler, with the core action front-loaded and the async handling second. Appropriately sized.

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 6-parameter generation tool with no annotations and no output schema, the description covers only the async retrieval pattern. Enum parameters like styleMode, aspectRatio, and cameraAngle and the meaning of count are left entirely to a sparse schema.

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

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

Schema description coverage is only 33% (only age and styleMode have descriptions). The description mentions no parameters at all — nothing about count, aspectRatio, cameraAngle, or the prompt's expected content — so it does not compensate for the coverage gap on a 6-parameter tool.

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

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

States a specific verb and resource ('Generate an AI influencer portrait') and scopes it to social accounts or UGC-style posts. It is distinguishable from create_image by the influencer/UGC framing, though it never explicitly contrasts with that close sibling.

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

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

Gives conditional guidance on retrieval ('Renders a live preview grid in app-capable hosts; poll each id with wait_for_image otherwise'), which is genuinely useful. However it says nothing about when to pick this over create_image, create_avatar_video, or other generation 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?

With no annotations, the description carries the full burden and delivers key traits beyond the schema: async execution requiring wait_for_video polling, live credit pricing tied to motion-video length, and live preview rendering in app-capable hosts. It omits auth requirements and failure/refund behavior, keeping it short of a 5.

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

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

One tight paragraph, front-loaded with the core action, then models, pricing, polling, and preview in descending priority. Every sentence carries information an agent needs to invoke this correctly.

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 6-param async creation tool with no output schema, the description covers the essentials: what it produces, how to choose models, how it is priced, and how to await results. Only minor gaps remain (no output/return shape detail, no failure handling), but polling guidance compensates for the missing output schema.

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

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

Schema coverage is 83% (baseline 3), and the description adds genuine meaning by explaining the role split of the media inputs (image = performing character, video = motion reference) and pointing to list_models for mode/model keys and the WaveSpeed input fields. That extra role context lifts it above the schema 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 and resource ('Make a character copy the motion of a reference video') and pins the exact input slots (inputs.image = character, inputs.video = motion source). This clearly distinguishes it from siblings like create_video and create_avatar_video without opening either 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 a clear operational sequence: check models via list_models, price via get_price first, then poll with wait_for_video. It stops short of an explicit when-not-to-use this over create_video/create_avatar_video, but the routing points to companion tools are strong and specific.

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

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

With no annotations, the description carries the full burden and does well: it discloses exact credit costs (3/4/6 at 1k/2k/4k), reveals the operation is asynchronous by instructing 'Poll with wait_for_image', and notes a live preview in app-capable hosts. It omits the return format (image URL vs. ID) and any failure/rate-limit behavior, so it stops short of full transparency.

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

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

Purpose and output list are front-loaded in the first sentence, then short declarative sentences cover credit costs, polling, and rendering. Every sentence carries information, though the opening enumerates seven output types and is somewhat dense. No filler or restated boilerplate.

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 6-parameter tool with a nested object, 3 enums, no output schema, and no annotations, the description covers cost, async polling, downstream usage, and output types. The main gap is that with no output schema it should more explicitly state what the call returns (e.g., an image reference/URL to poll for), but it is otherwise complete enough to invoke correctly.

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

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

Schema description coverage is 100%, including a detailed enum key for mode and a rich nested params object, so the schema already does the heavy lifting and the baseline is 3. The description's listing of output types loosely maps to the mode values but adds no syntax or constraints (e.g., resolution/ratio interplay, referenceImageUrls count) beyond what the schema states.

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

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

States a specific verb (Generate) and resource (pre-production reference images for AI films/ads) and enumerates exactly what it produces: faces, full-body refs, turnarounds, locations, first frames, mood boards, and storyboards. It distinguishes itself from siblings like create_image and create_video by scoping to pre-production reference material. An agent can tell what this does without opening the schema.

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

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

Explicitly names the downstream consumer ('Feed the results to create_video as reference images') and the polling tool ('Poll with wait_for_image'), giving clear workflow context. However, it never states when to use this over create_image or create_thumbnail, nor any exclusion conditions, so the routing guidance against the closest sibling is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses the async pattern (returns generation.id, poll with wait_for_music) and host-dependent rendering behavior. It omits cost/credit implications and failure/retry behavior, keeping it short of a 5.

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

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

Four dense sentences, all front-loaded with the core action and model rules before the return-value note. No filler, though the model enumeration is verbose enough to make scanning slightly heavy.

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

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

For a 5-param async generation tool with no output schema, the description covers the action, model constraints, prompt semantics, and polling path. Only the two minor params (output_format, idempotencyKey) and cost behavior 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?

Schema coverage is only 40%, but the description compensates substantially: it explains what the prompt controls (genre, mood, tempo, vocal style with an example), and the lyrics/model coupling rule. output_format and idempotencyKey remain undocumented in both places.

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

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

Opens with a specific verb+resource: 'Generate a music bed or song for a social video, Reel or ad', and names the provider (Mureka AI). An agent can distinguish this from create_voiceover or create_video immediately.

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?

Explains model-dependent usage (song models need lyrics; mureka-7.5 treats lyrics as optional) and points to wait_for_music for polling, which is clear operational context. It does not explicitly state when to prefer this over sibling audio tools, 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?

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses draft behavior, publishNow semantics, paid-plan requirement, automatic image fitting, rejection with per-platform issues list, and app-panel rendering instructions. These are exactly the traits an agent needs before invoking a write operation.

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

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

The description is long but front-loads purpose, usage, and the compose_post alternative before diving into platform rules. Most sentences carry operational detail, though the platform list and some image-ratio guidance could be tightened; still, it is structured for scanning.

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 17-parameter, multi-platform tool with no output schema and no annotations, the description covers core invocation behavior, platform constraints, error handling, and UI rendering. It still omits how to source accountIds (get_accounts), alternatives like update_post/publish_post for existing drafts, and constraints for several supported platforms.

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 65%, so the description must add value, and it does: it gives platform-specific constraints for YouTube title, Pinterest media, X character/media limits, and Google Business Profile limits. It does not explain every parameter (e.g., external_id, accountOverrides, mediaUrl vs mediaUrls, timezone), leaving some gaps.

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

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

The description opens with a specific set of verbs (create, schedule, queue, publish, cross-post) and the resource (content to connected social accounts), lists supported platforms, and explicitly names compose_post as the alternative for self-serve editing. An agent can distinguish this from siblings like compose_post, update_post, and publish_post.

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

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

It states exactly when to use it ('any request to post now, schedule for later, publish to multiple platforms at once, or add something to the posting queue') and when to prefer compose_post ('when the user wants to set the post up themselves or per-platform options are still open'). It also clarifies draft vs immediate behavior with scheduled_at/publishNow.

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

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

With no annotations, the description carries the full burden and does disclose the critical behavioral trait: this is asynchronous and returns one job per requested variation, with polling required via wait_for_image. It omits cost/credit implications, whether generated thumbnails persist or can be deleted, and what happens when all six optional parameters are omitted.

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

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

Two sentences, no waste, and the most decision-relevant facts (what it makes, and how you get the output) are front-loaded. Nothing repeats the tool name or 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 six-parameter generation tool with zero required parameters, no annotations and no output schema, the description covers the async return contract but leaves parameter meaning and the zero-required-parameter behavior unexplained. It is minimally viable: enough to invoke the tool and handle its jobs, not enough to invoke it well.

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 (prompt, context, expression, variations, templateImageUrls, referenceImageUrls) have no schema-level documentation. The description only incidentally hints at 'variations' via 'one job per variation' and says nothing about the prompt, context, expression, or the template vs reference image distinction, so it fails to compensate for the coverage gap.

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

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

States a specific verb and resource with format detail: 'Generate a YouTube thumbnail (16:9) for a video you are publishing.' That is enough to distinguish it from generic image tools, but it never explicitly contrasts itself with siblings like create_image or create_movie_material, nor does it explain what 'context' and 'expression' contribute to the result.

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 real routing guidance: results render as a live preview grid in app-capable hosts, while other hosts must poll each returned id with wait_for_image. That tells the agent how to consume the output in two environments. It does not say when to prefer this over create_image for non-YouTube artwork, so the alternative-selection guidance is incomplete.

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

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

Annotations declare this is a non-read-only, non-destructive operation, but the description goes much further: it describes the one-time link semantics, the exact PUT workflow with Content-Type, the return values, and the required follow-up call to complete_upload. This is rich behavioral context well beyond the annotation surface.

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

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

Front-loaded with the purpose, then the workflow, then the exclusion case. Every sentence earns its place, including the curl example, which gives an agent an actionable template rather than 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, yet the description explains the returns (uploadUrl and blobName) and the complete two-step flow through complete_upload. For a mutation tool whose result is a URL plus a follow-up step, 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?

Schema description coverage is 100% and the single fileName parameter is fully documented in the schema. The description adds only marginal param-level context (the file is large or local, and Content-Type matters for the PUT), so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Get a one-time link for uploading a large or local file straight to the user's Unsora storage') and implicitly contrasts with upload_file by noting it is 'far beyond upload_file's limits.' An agent can immediately tell this apart from the sibling upload tools.

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

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

Explicitly states both the when ('Only useful when you can send HTTP requests yourself, e.g. a coding agent with a shell') and the when-not, naming the alternative ('In chat hosts that show apps, call list_uploads instead'). The full use/avoid decision is 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?

With no annotations, the description carries the full burden and does well: it flags that video is 'expensive' (cost profile), that generation is asynchronous and must be polled with wait_for_video, and that a live preview renders in app-capable hosts. It does not cover failure/refund behavior or auth requirements, so it falls just short of complete.

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?

Four sentences, front-loaded with purpose and use cases, then workflow, with zero filler. The inline model enumeration is long but plausibly useful for model selection; it is the only element that mildly dilutes density.

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-gated generation tool with no output schema and no annotations, the description covers cost gating, polling, model discovery and preview behavior. Minor gaps remain around idempotencyKey usage and what happens if a render fails or is rejected on credits.

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 83%, so the schema already documents mode, model, inputs and maxCredits, giving a baseline of 3. The description adds real meaning by tying maxCredits to the get_price workflow ('pass them as maxCredits') and by directing the agent to list_models for valid mode/model/input keys, which the schema only references abstractly.

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 ('Generate a short video') plus the concrete use cases (social post, Reel, TikTok, ad), and enumerates the supported models. Combined with the sibling list (create_image, create_avatar_video, create_motion_control), an agent can immediately distinguish this from the other creation 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?

Gives an explicit prerequisite chain: see list_models for modes/inputs, call get_price first, tell the user the credits, pass them as maxCredits, then poll with wait_for_video. It names three alternative sibling tools and the exact condition under which each is needed, leaving nothing 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?

With no annotations, the description carries the full burden and does so well: discloses cost (15 credits), a per-account cap (max 10 clones), the return handle (clone.id), and non-obvious host-rendering behavior ('renders as an interactive panel... do NOT repeat its contents'). These are exactly the traits an agent cannot infer from the schema.

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

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

Dense but front-loaded: purpose, legal/prereq constraint, quality guidance, cost/limits, return value, host-rendering rule. Every sentence earns its place with no filler.

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

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

No output schema exists, yet the description explains the salient return value (clone.id) and its downstream use, plus the host-panel behavior. For a 3-param mutation tool, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 67% and the schema already documents name and sampleUrl (including formats and the upload_file hint). The description adds input-quality guidance ('1–2 minutes of clean speech with no music or background noise') that the schema does not provide, though it leaves the optional description field unaddressed.

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 ('Create an instant voice clone from a speech recording') and names the provider. It is clearly distinguishable from siblings like delete_voice_clone, list_voices and change_voice.

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

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

Gives explicit when-to-use constraints (only the user's own voice or one they have permission for), prerequisite routing ('use upload_file first'), and downstream routing (use clone.id as voice_id in create_voiceover, create_avatar_video, change_voice). This is near-complete routing guidance.

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

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

No annotations are provided, so the description carries the full burden and largely succeeds: it discloses per-provider credit costs, the pause-tag syntax, that it is async (generation.id + polling), and host rendering behavior. It omits failure modes, rate limits, and whether credits are refunded on failure, keeping it just below the top band.

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 five dense sentences, each front-loaded with a distinct payload: purpose, voice-selection workflow, cost matrix, pause-tag syntax, and return/polling contract. No filler or repeated schema content.

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

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

With no output schema, the description proactively supplies the return contract ('generation.id — poll with wait_for_voiceover'), and it also covers cost and text-formatting concerns an agent would otherwise miss. Only the idempotencyKey parameter is left unexplained, 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?

Schema description coverage is 86%, so the schema already documents nearly every parameter and a baseline of 3 applies. The description adds genuinely new meaning beyond the schema, notably the pause-tag syntax that governs the 'text' field and the voice-selection provenance (Eleven v3 list vs cloned vs MiniMax presets).

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 ('Generate a voiceover ... from a script') plus the target artifact class (social video, Reel or ad). An agent can distinguish this from create_music or create_voice_clone 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 an explicit prerequisite workflow ('Use list_voiceover_voices first and let the user pick') and a downstream step ('poll with wait_for_voiceover'), which is strong context. It never states when NOT to use it or contrasts directly with a conflicting sibling like change_voice, so it falls short of the full 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, so the safety profile is known. The description adds meaningful context beyond that: the deletion is permanent and cannot be undone, user confirmation is required, and in app-capable hosts the result renders as an interactive panel. It doesn't detail error or partial-failure behavior, but the added disclosure is substantial.

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?

Purpose and ID sources are front-loaded, and the destructive/confirm warning follows immediately. The final sentence about the interactive panel is longer but earns its place by preventing duplicated output in capable hosts.

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

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

For a two-parameter destructive tool with no output schema, the description covers target scope, ID provenance, irreversibility, confirmation, and host-specific rendering behavior. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 0%, so the description must carry the load. It compensates well: id comes from list_generations (or list_uploads for type upload), and the type semantics are clarified for both branches. The full enum list lives in the schema, so the description doesn't need to repeat it.

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

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

The description states a specific verb (permanently delete) and resource (one result from the user's library, or an uploaded file), and it distinguishes the two target categories and their ID sources (list_generations vs list_uploads). An agent can tell exactly what this deletes without opening the schema.

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

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

It gives clear context: use it for library results (type + id from list_generations) or uploads (type upload, id from list_uploads), and it mandates confirming with the user first. It does not name sibling alternatives (e.g., delete_post, delete_voice_clone), but the scope is unambiguous.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that deletion is scoped and does not touch already-published platform content, and it explains the interactive-panel rendering and the instruction not to echo its contents. It omits irreversibility, permission/auth requirements, and the fate of scheduled-but-unpublished posts.

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 and its scope are front-loaded in the first two sentences. The final clause about panel rendering is somewhat tangential to deletion but is short and 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 destructive tool with no annotations and no output schema, the description covers scope and UI rendering but leaves key gaps: whether the operation is irreversible, what permissions it needs, and how scheduled/published posts are affected.

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 parameter postId has 0% schema description coverage and the description adds nothing about it, so the agent must infer it identifies the post to remove. The name is conventional enough that the gap is minor, but no meaning is added 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 ("Delete a post") and clarifies scope with "Does not remove already-published content from the platforms." It does not, however, distinguish itself from the many sibling delete tools (delete_generation, delete_voice_clone) or from update_post/list_posts.

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

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

There is no guidance on when to use this versus update_post, publish_post, or the other delete siblings, and no prerequisites or preconditions (e.g. must the post be unpublished first). The scoping sentence describes behavior, not usage conditions.

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

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

Annotations declare destructiveHint=true. The description adds significant behavioral context beyond that: the deletion is permanent, requires user confirmation, and specifies how output renders in app-capable hosts, instructing the agent not to duplicate the panel. This exceeds what annotations alone provide.

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

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

Three sentences, front-loaded with the core action. The confirmation and output-panel instructions are focused and earn their place, though the third sentence is somewhat long. No obviously wasted 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?

Given a simple, single-parameter destructive tool with annotations and no output schema, the description covers the essentials: permanence, confirmation, and output handling. It omits error behavior and explicit routing to list_voices, but those are minor gaps.

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

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

Schema coverage is 100% for the single cloneId parameter, and the schema itself documents it as 'Clone id from list_voices.' The description adds no parameter-level details beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('delete') and resource ('cloned voices') with scope ('one of the user's'). It distinguishes from other delete tools such as delete_generation and delete_post by resource type. However, it does not explicitly route to or differentiate from siblings like list_voices or create_voice_clone.

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?

Provides a key prerequisite: 'Confirm with the user first.' However, it does not state when to use this tool versus alternatives (e.g., using list_voices to find the cloneId) or when not to delete. Usage is implied by the tool name and purpose.

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, openWorldHint=false), so the description's value is the added behavioral context: supported-platform enumeration, the provider field mapping, and the app-capable-host interactive-panel rendering instruction with an explicit "do NOT repeat" directive. Auth requirements and pagination are unstated, keeping this short of a 5.

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

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

Front-loaded with purpose, then platform coverage, then return-field detail, and finally the output-presentation instruction. The platform enumeration is lengthy but informational rather than redundant, so each sentence largely 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?

No output schema exists, so the description must carry the return-value burden, and it does: it names the platforms, the provider field, and the panel rendering behavior. Minor gaps remain (auth/permission prerequisites, ordering), but for a parameterless list tool this is nearly 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?

With zero input parameters, the baseline is 4. The description adds useful semantic detail about the returned data shape (provider field, e.g. YouTube accounts use provider "google"), though this concerns outputs rather than 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 and resource ("List connected social accounts") plus the scope/purpose ("for scheduling"). This is clearly distinguishable from sibling list tools (list_posts, list_generations, list_voices), which concern posts or media rather than connected accounts.

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 by "for scheduling" — the agent can infer it enumerates the accounts available before composing/publishing. There is no explicit when-to-use/when-not statement and no named alternative among the many sibling tools, so it meets only the minimum viable bar.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false. The description adds genuinely new behavioral context: that in app-capable hosts the result renders as an interactive user-facing panel and that the agent should not duplicate it. That is useful output-presentation behavior not derivable 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?

Front-loaded with the core action in the first sentence, followed by one longer sentence of rendering guidance. Slightly wordy but every clause earns its place by preventing redundant 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?

No output schema exists, but the description explains the return shape that matters (an interactive panel plus the caveat that it may not render in all hosts). For a no-param, read-only tool this is close to 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?

Zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify and it introduces no parameter-related confusion.

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 current credit balance'), which is clear enough to separate it from get_subscription and get_price. It does not explicitly name or contrast those siblings, 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?

The description gives real guidance on how to use the *result* (don't repeat the panel contents), but says nothing about when to call this tool versus get_subscription, get_price, or get_accounts. Usage is only implied by the resource 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 establish that this is a safe, non-open-world read (readOnlyHint=true, openWorldHint=false). The description adds useful behavior beyond that: the payload includes per-account publish status and media, and in app-capable hosts the result is rendered as an interactive panel with an explicit instruction not to duplicate it as text. That is meaningful context not derivable 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?

Two sentences, front-loaded with the core purpose. The second sentence is dense but each clause earns its place by telling the agent how to handle rendered output; no filler or repetition 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?

With no output schema, the description steps in to name the return contents (publish status, media) and the host-dependent rendering, so an agent knows what to expect. It stops short of covering failure cases such as an unknown or deleted post id, a minor gap for a simple read.

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

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

There is a single required parameter (postId) with 0% schema description coverage, so the description must carry the meaning. 'Fetch one post by id' tells the agent the parameter identifies a post, which is adequate but adds no format, source, or retrieval detail beyond the obvious.

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 with scope: 'Fetch one post by id'. The singular 'one post' and 'by id' clearly distinguish it from the plural list_posts sibling, and the mention of per-account publish status and media sharpens what is returned.

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: an agent can infer this is the single-item counterpart to list_posts, but no alternative or condition is named explicitly. The only real guidance concerns how to present the result in app-capable hosts, not when to choose 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?

With no annotations, the description carries the burden and does disclose real behavioral traits: refresh incurs a latency cost because it hits the platforms first, and results render as an interactive panel whose contents should not be duplicated. It omits auth/permission requirements and any staleness/pagination behavior, so it isn't fully exhaustive.

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 purpose, followed by the refresh tradeoff, then the rendering instruction — a logical order. The panel-response directive is wordy ('do NOT repeat its contents as a list or table in your reply') but earns its place by preventing redundant 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 and no annotations, the description compensates by enumerating the return shape (totals plus per-platform breakdowns) and covering the refresh semantics and host-dependent rendering. Adequate for an agent to call and interpret it, though auth/permission context and metric freshness defaults are absent.

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% (the refresh boolean has no schema description), so the description must compensate — and it does, explaining that refresh: true pulls fresh platform metrics and is slower. The days parameter adds little beyond the schema's 7–90 range and default, but the uncovered parameter is well handled.

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?

Combines a specific verb (get/retrieve analytics) with a precise resource (the user's published posts) and names the returned payload: totals for views, likes, comments and shares plus per-platform breakdowns. This clearly distinguishes it from siblings like get_post or list_posts, which return post data rather than aggregated performance metrics.

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?

Explains the refresh: true tradeoff (pulls fresh metrics from platforms first, slower) and gives an explicit when-to-do-what instruction for reply formatting in app-capable hosts. It stops short of naming alternatives or exclusions, but the operative context for invoking it correctly is present.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, but the description adds domain-specific reassurance that matters in a credit system — 'spends no credits and changes nothing in the user's account'. It also discloses that the quote is only valid for the exact settings supplied (resolution, duration, audio, attached media length), which is a real behavioral constraint the annotations do not carry. It omits failure behavior for an invalid model key or mode.

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

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

Three short sentences, the core purpose and the read-only guarantee are front-loaded, and the follow-on maxCredits linkage closes it out. Nothing is padded; even the 'creates nothing' clause earns its place in a credit-consuming product.

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, yet the description states what comes back — the credit price — which is the essential return information. It is slightly thin on the response shape (whether it is a bare number or an object) and on what happens when the supplied settings are invalid, but the nested inputs object and enum are addressed well enough 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 only 40%, with 'model' and 'inputs' documented but mode, prompt and category left bare in the schema. The description compensates partially by naming the price-relevant fields (resolution, duration, audio, attached media length) and implying inputs must mirror the create call, but it never explains the role of mode, prompt or the category enum, so half the parameters remain uninterpreted.

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 gives a specific verb and resource — 'returns the credit price of one video, image or motion-control generation' — and scopes it to 'these exact settings'. It also explicitly separates itself from the create_* siblings by stating 'It creates nothing, spends no credits', so an agent can tell it is a quote/simulation step, not a generation step.

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 supplies a concrete workflow: quote first, then 'the quoted credits can be passed as maxCredits to the create tool', which tells the agent exactly how this tool feeds the creation tools. It does not explicitly route away from the closest read sibling, get_credits, so the agent must infer on its own that get_credits is an account balance rather than a per-generation quote.

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 cover readOnlyHint and openWorldHint; the description adds the admin gating, the 403 failure mode, and the fact that the full record is returned regardless of status, including page content, files, and media. That is substantive behavioral context beyond the structured hints.

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

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

Three tight sentences with the most consequential constraint (ADMIN ONLY) front-loaded, followed by return contents, then the workflow hint. Every sentence carries distinct information and none is padding.

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

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

For a one-parameter read with no output schema, the description covers access requirements, lookup key, and return payload composition, which is everything an agent needs to call it correctly. No meaningful gap remains.

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

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

Schema description coverage is 100% and the single parameter is already documented as "Skill id or slug." The description's phrase "by id or slug" merely restates the schema, adding no format, prefix, or resolution-order detail, so the baseline 3 applies.

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

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

States a specific verb and resource ("fetch a skill from the Unsora skills catalog by id or slug") and immediately qualifies the scope with ADMIN ONLY. It also distinguishes itself from the sibling update-skill by framing itself as the read-side counterpart, so an agent can route without opening either 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 call-site ("Use before update-skill to see the current state") and an explicit exclusion ("Non-admin accounts get a 403"), which tells the agent both when to reach for it and when it will fail. Nothing about selection is left 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), but the description adds genuinely non-obvious behavior: in app-capable hosts the result renders as an interactive panel, and the agent must not duplicate its contents in the reply. That host-dependent rendering rule is not inferable from schema or annotations.

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

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

Two sentences, zero filler, front-loaded with the resource and the field the agent should act on. The second sentence is dense but each clause (panel rendering, don't duplicate, add only missing info) carries distinct guidance.

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 burden of indicating what comes back; it names plan, Stripe subscription state, and the isActive flag, and explains how the result is surfaced. It could say more about edge cases (e.g., no subscription present), but it is sufficient for a zero-parameter read.

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 and schema coverage is 100%, so there is nothing for the description to clarify. Baseline 4 applies for a no-argument 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 and resource ('Get plan and Stripe subscription state') plus the key field of interest ('isActive'). It is distinguishable from related siblings like get_credits and get_accounts, though it does not name them 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 concrete triggering condition ('check isActive before scheduling posts'), which tells the agent when this call matters. It stops short of naming an alternative tool or stating when not to call 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, idempotentHint=true, openWorldHint=false, so the read-only/idempotent safety profile is covered by structured data. The description adds a modest amount: it clarifies this is 'single-shot' (vs. wait_for_* polling tools), which is useful behavioral context. It does not describe what the status values are, whether the id can be reused, or what a missing/failed generation returns.

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 compact sentence with a clear front-loaded purpose statement. Nothing is wasted. It would have earned a 5 with slightly richer content, but as a fragment the sentence is well-formed and easy to parse.

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?

Two required parameters with 0% schema coverage, no output schema, and no annotations explaining status semantics. The description does not tell the agent what a status response contains or how to interpret different states, which for a tool literally named 'status' leaves a significant operational 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% — neither 'id' nor 'tool' has a description in the schema, and the description text provides no semantic detail at all. The enum on 'tool' is self-explanatory (image, influencer, video, etc.), but whether 'id' refers to a generation id, a job id, or a preview id is unspecified, which matters because there are separate generation-list tools.

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 combination: it checks generation status. It even notes the scope ('single-shot generation status check') and its intended caller ('used by the preview UI'). It does not, however, name the sibling it complements (e.g. audio_status, video_status, wait_for_image) which would help an agent distinguish between status variants.

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 parenthetical 'used by the preview UI' is the only usage hint, and it's a weak one — it tells the human-in-the-loop use-case, not when an agent should choose this over wait_for_image, video_status, audio_status, or the polling tools. No when-not or alternative guidance is included.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), but the description adds real non-obvious behavior: results are ordered newest first, each entry carries status and output URLs, and in app-capable hosts the output renders as an interactive panel that must not be duplicated in the reply. Return-content shape and host-dependent rendering are disclosed, which is beyond what the annotations provide.

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 what the tool does and its scoping, then adds routing and host-behavior notes in short sentences. The long embedded enum list is somewhat bulky but matches the schema's values, and every remaining sentence carries actionable information.

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

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

With no output schema, the description compensates by naming the returned fields (status, output URLs) and the ordering, plus the panel-rendering caveat. For a read-only list tool this is a complete picture of what an agent needs to call and report it correctly; only paging semantics remain 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 description coverage is 0%, so the description must carry the parameter burden, and it does not: 'page' and 'limit' (max 100) are never explained, and pagination behavior is unstated. The type enum values are simply re-listed, which duplicates the schema rather than adding meaning; only 'for one feature' hints at scope.

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 ('Browse the user's past results for one feature') and scopes it by enumerating the exact feature types the tool covers. It also distinguishes itself from the sibling list_uploads by explicitly saying uploaded files live there, letting an agent route correctly 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 a clear use case ('find something made earlier, e.g. to post or reuse it') and names one alternative (list_uploads) for a related but distinct resource. It does not, however, say when to prefer this over single-item status tools like image_status or video_status, so the routing guidance is incompletely bounded.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context about the return payload (model names, modes, enums, ranges, defaults) and that it is a prerequisite step for the create_* tools, though it says nothing about size of the catalog or whether results are cached/live.

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, zero filler, with the what (full model catalog) front-loaded and the when (before the create_* calls) immediately after.

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, yet the description explains what an agent receives (models with modes and exact input fields) and why it matters (building `inputs`). For a read-only one-parameter list tool, nothing needed to call it correctly is missing.

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

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

Schema coverage is 100% and the single `category` enum is fully documented in the schema. The description's 'video, image and motion-control' wording loosely mirrors the enum values but adds no filtering syntax or behavior beyond what the schema already gives; baseline 3 applies.

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

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

States a specific resource (video, image and motion-control models) and what each entry carries (modes, exact input fields, enums, ranges, defaults). It is clearly distinguished from the create_* siblings it feeds, which it names 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 an explicit when-to-call rule: 'Call this before create_video / create_image / create_motion_control to pick a model and build `inputs`.' The alternatives and the ordering constraint are both stated, leaving nothing 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 cover the safety profile (readOnlyHint=true, openWorldHint=false). The description adds genuine behavioral context beyond that: in app-capable hosts the result renders as an interactive panel and the agent must not duplicate its contents. Missing are pagination/ordering semantics for large result sets.

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

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

Three sentences, each serving a purpose: capability, filtering, and host-rendering behavior. Front-loaded with the core action. Minor redundancy listing statuses twice (prose and parenthetical).

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 no output schema, the description covers scope, ordering, filtering, and return rendering. The remaining gap is pagination semantics (page/limit), which an agent may need for large post collections.

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. It documents the status filter (though the enum already lists these values in the schema) but says nothing about page or limit, leaving two of three parameters unexplained. Baseline 3 for partial 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 (List) and resource (the user's posts), plus ordering ('newest first') and the covered statuses. An agent can distinguish it from get_post (single-item) and list_generations 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?

Explicitly documents the status-filter use case and enumerates filter values, and adds the important host-conditional rendering instruction. It does not name sibling alternatives (get_post, list_generations) or state when not to use it, 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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely non-obvious behavior: in app-capable hosts the result renders as an interactive panel the user sees and acts on, which drives the 'do not repeat contents' instruction. It omits any mention of rate limits, ordering, or what happens across hosts that lack app support, so it is good but not exhaustive.

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

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

Three sentences, front-loaded with the resource definition before the host-dependent behavior and the output-handling rule. Every sentence earns its place; the middle sentence is dense but not padded.

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

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

With no output schema, the description correctly explains how results surface (an interactive panel) and how the agent should respond, which is the key missing structured information. However, pagination semantics for page/limit are left entirely unexplained, leaving a real gap for a tool whose only parameters are those two.

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 two parameters (page, limit) are undocumented in both schema and description — notably the limit maximum of 100 and any default page size. With two non-trivial pagination params the description is expected to compensate and it says nothing about them.

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

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

States a specific verb and resource — 'List the user's uploaded media assets' — and distinguishes it from sibling list tools (list_generations, list_posts) by naming the exact asset class and its origin (upload_file or the app). It stops short of explicitly naming the sibling it is not, 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?

Gives clear context for when this tool is the right call: in hosts that show apps, invoking it is how the user uploads a file, and the agent should direct them to the panel's Upload button. It also states a usage constraint (do not restate panel contents). It does not contrast against upload_file or create_upload_url, which limits it below 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 only declare a safe read (readOnlyHint=true, openWorldHint=false), but the description adds meaningful behavior beyond that: the fixed count of 20, the exact returned fields, and the host-dependent UI rendering (interactive picker with tap-to-play previews). That rendering behavior is not derivable from any structured field.

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

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

Three sentences, front-loaded with what the tool returns, then the host-dependent response instructions. Every sentence earns its place, though the picker instruction is dense enough that it could be tightened slightly.

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

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

With no parameters and no output schema, the description fully carries the burden: it names the output fields, the count, and the crucial response-handling rule for UI vs non-UI hosts. An agent has everything needed to call it and respond correctly.

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

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

The schema is empty with zero parameters, so there is nothing to document and the baseline of 4 applies. The description correctly implies the tool is a no-argument listing call, though it adds no parameter detail (none exists to add).

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 precise verb+resource with scope ('the 20 ElevenLabs Eleven v3 voices available for create_voiceover') and lists the returned fields, so it is immediately distinguishable from the sibling list_voices and tied to its consumer create_voiceover.

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

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

Gives explicit conditional guidance: in app-capable hosts use the picker and do NOT repeat the voices as a table/list/summary; only in hosts without the UI share preview URLs. This is exactly the when/how-to-present routing an agent needs and leaves nothing 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 only declare readOnlyHint and openWorldHint; the description adds substantially more — that ElevenLabs entries carry preview URLs, that clones must be referenced by clone id, that clone limit and credit cost are returned, and that app-capable hosts render an interactive panel whose contents should not be echoed in the reply. That last point is non-obvious host-dependent behavior an agent would otherwise get wrong.

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 purpose, then layered with return categories, downstream usage, and a rendering caveat. The final panel instruction is comparatively long but carries non-obvious guidance, so it earns its place; the sentence structure is dense but readable.

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 input parameters and no output schema, the description carries the full burden of explaining returns, and it does so thoroughly — categories, identifier conventions, credit-related fields, and host rendering. An agent has everything needed to call it and to interpret and present the result correctly.

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

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

The tool takes zero parameters, so the baseline is 4 per the rubric. The description does name the result field keys (presets, elevenV3Voices, clones, maxClones, cloneCreditCost), which helps with return interpretation, but there are no parameter semantics to clarify.

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 and goes further by enumerating the three voice categories returned (presets, elevenV3Voices, clones) plus the aggregate fields (maxClones, cloneCreditCost). It does not, however, distinguish itself from the sibling list_voiceover_voices, 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?

Gives clear downstream context: voices returned here work as voice_id in create_voiceover and create_avatar_video, and change_voice specifically requires a cloned voice. It stops short of stating when to call this versus list_voiceover_voices, so no explicit alternative or exclusion is named.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so safety and determinism are covered. The description adds one genuinely useful behavioral fact — that boards belong to a connected Pinterest account, implying an account-linking prerequisite — but says nothing about rate limits, pagination, or what happens if the account isn't connected.

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 is stated before the provenance note. It is efficient, though its brevity is partly under-specification rather than pure economy.

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

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

For a one-parameter read-only list tool with no output schema, the definition is minimally viable but leaves the agent guessing about the return shape — notably whether board IDs usable by a pinning/composing flow are included. The connected-account prerequisite is mentioned, which is the most important missing piece, but the rest is thin.

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

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

Schema description coverage is 0% for the single accountId parameter, so the schema provides no meaning. The description partially compensates by framing it as 'a connected Pinterest account,' but does not clarify whether accountId is an internal account identifier or a Pinterest user handle, nor where to obtain it.

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

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

The description names a specific resource (boards) restricted to a connected Pinterest account, which reads as a retrieval/list operation and clearly distinguishes it from the write-oriented siblings like create_post or publish_post. The verb is implied rather than stated, so it falls just short of a 5.

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

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

The parenthetical '(used by the composer UI)' notes where the data is consumed but gives the agent no when-to-use guidance, no prerequisites (must the account be connected first?), and no comparison to alternatives such as tiktok_creator_info or get_accounts. Context is hinted at, not stated.

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

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

With no annotations, the description carries the full burden and delivers: a paid-plan prerequisite, asynchronous background execution, the immediate PUBLISHING return status, the recommended follow-up delay ('a minute or two'), and host-specific panel behavior including a directive not to duplicate panel contents. This is unusually complete behavioral disclosure.

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 scope before the operational details. Each sentence carries distinct information, though the two app-capable-host sentences overlap slightly and could be merged without loss.

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 explain returns — and it does, stating the tool returns PUBLISHING immediately and where to look for per-account results. Prerequisites, async behavior, and error recovery are all covered.

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

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

Only one parameter exists and the schema documents none of it, but postId is self-evident from the name. The description adds real meaning by constraining the target to a DRAFT or SCHEDULED post, implying posts in other states are invalid input.

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 (publish) and resource (a DRAFT or SCHEDULED post) and clarifies the semantics: publish now rather than waiting for the schedule. This distinguishes it cleanly from siblings like create_post, update_post, and retry_post.

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 says when to use it (publish a draft/scheduled post immediately), when not to act (don't poll get_post in app-capable hosts), and names the alternatives (get_post to check results, retry_post for failures). Routing guidance is fully specified.

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

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

With no annotations, the description carries the full burden and delivers: partial-retry semantics (only failed accounts), a no-duplicate guarantee (published accounts are never re-posted), asynchronous background execution, and a polling instruction. These are non-obvious behaviors an agent could not infer from the schema.

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

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

Front-loads eligibility first, then behavior, then outcome retrieval, then rendering constraints. Four tight sentences with no filler; every clause carries operational 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?

No output schema exists, and the description compensates by explaining that results arrive asynchronously and where to read them, plus how the host renders the panel. An agent has enough to invoke it and handle the response correctly.

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

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

Schema description coverage is 0% and the single postId parameter is undocumented, but the description's repeated references to 'post' make the referent obvious. It adds no format, ID-type, or sourcing guidance beyond that implicit context.

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 ('Retry a ... post') and narrows scope with the exact eligible states (FAILED or PARTIALLY_PUBLISHED). This clearly distinguishes it from siblings like publish_post, create_post, and update_post, which do not imply re-attempting a failed 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?

Gives a precise precondition (only failed/partially published posts) and tells the agent how to obtain the outcome via get_post, which is effectively the follow-up step. It stops short of naming an explicit alternative or stating what to do when the post is not in a retryable state.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description usefully discloses the shape of the returned data (privacy levels, disabled-feature flags, max length), but says nothing about auth requirements for the connected account or how to obtain a valid accountId.

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

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

A single front-loaded sentence with the key scope ('TikTok creator info for a connected account') first, followed by the enumerated contents. The trailing parenthetical is mildly informational but not wasteful.

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

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

For a simple read-only, single-parameter lookup with annotations covering safety, the description supplies the important missing piece: what the return payload contains. It is close to complete, with only the accountId provenance 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 1 parameter at 0% schema coverage, the schema documents the accountId field only as an untyped-format string. The description partially compensates by framing it as 'a connected account', but adds no format, source, or lookup guidance beyond that.

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: retrieves 'TikTok creator info for a connected account', and enumerates what that info contains (privacy levels, comment/duet/stitch flags, max video length). This is clearly a read/info tool, distinguishable from the creation and posting siblings, though it doesn't explicitly name an alternative.

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

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

The phrase '(used by the composer UI)' implies this is fetched ahead of composing a TikTok post, which gives context. However, it never states when an agent should call it versus siblings like compose_post or create_post, nor any prerequisites beyond a 'connected account'.

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

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

With no annotations, the description carries the full burden and does well: patch semantics ('only the fields you pass change'), the destructive replacement of accounts, the scheduled_at null-to-draft transition, and the interactive panel output with an explicit instruction not to duplicate it. It omits auth/permission and error behavior, but covers the mutation's risky traits.

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 editability constraint is front-loaded, then field semantics, then output handling, all in compact sentences with no filler. Every clause carries information an agent needs.

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

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

For a mutation tool with no annotations and no output schema, it covers editability, patch behavior, scheduling transitions, and result rendering. Only auth requirements, error handling, and caption/timezone semantics are absent, which are minor given the tool's simplicity.

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% and caption, timezone, and postId are undocumented in both places. The description adds real meaning for scheduled_at (null converts to draft) and accounts (full replacement), partially compensating, but leaves several parameters 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?

The description gives a specific verb (Edit) and resource (DRAFT or SCHEDULED post) and immediately states the scope boundary that published posts cannot be edited. This clearly separates it from siblings like create_post, publish_post, and delete_post.

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

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

It states the precondition for use (only DRAFT or SCHEDULED posts) and the behavior of key fields, which tells the agent when this tool applies versus publish_post. It does not explicitly name an alternative tool for the excluded case, so it falls short of a full routing 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?

With no annotations, the description carries the burden and does disclose the key traits: admin-only auth with a 403 failure mode, the partial-update contract ('only the fields you pass change'), and the mutation surface (rewriting landing content, replacing SKILL.md, publish/unpublish, appending media). It omits reversibility, versioning behavior, and any warning that supplied fields overwrite existing content, which is meaningful for a mutation tool.

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

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

Two tight sentences with the critical 'ADMIN ONLY' constraint front-loaded and no filler. Each clause carries distinct information: eligibility, update semantics, capability surface, and failure mode.

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 15-parameter mutation tool with no annotations and no output schema, the description gives an adequate behavioral picture (auth, partial update, capability scope). It does not touch most of the individual content fields, but the schema covers those at 60%, so the agent has enough to call it correctly.

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

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

Schema coverage is 60%, so the schema already documents many parameters. The description adds meaning for a few (id-or-slug targeting, addMedia attaching media by URL, SKILL.md replacement, status as publish/unpublish) but leaves the many content fields (name, tagline, description, examples, highlights, requirements, installCommand) unexplained, so it does not compensate for the coverage gap.

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

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

States a specific verb+resource ('partially update a skill in the Unsora skills catalog') with an unambiguous scope ('by id or slug'). The 'partially update' framing and the enumerated capabilities clearly separate it from create-only siblings like upload-skill and read-only get-skill.

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?

Establishes a clear precondition ('ADMIN ONLY') and outcome for the wrong caller ('Non-admin accounts get a 403'), which tells an agent exactly who may invoke it. It does not name a sibling alternative (e.g., upload-skill for creation), so it stops short of full 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?

With no annotations, the description carries the full burden and delivers well: auth scope (every authenticated user), size caps for each path, persistence ("stored and recorded as an upload asset"), downstream reuse of the returned url, and host-dependent panel rendering with a do-not-duplicate instruction. It omits failure modes and any credit/quota implications, keeping it short of a 5.

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

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

Front-loaded with the action and the preferred input path, then alternatives, then result/host behavior in a logical order. It is a dense single paragraph rather than scannable lines, but nearly every clause carries operational value.

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

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

There is no output schema, and the description compensates by describing the return value and its reuse sites (create_post media, reference images, clipping input) plus the panel rendering. Error handling and asynchronous progress behavior are not addressed, so it falls just short of fully complete.

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

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

Schema coverage is 100%, so the baseline is 3; the description lifts it by explaining the url-vs-base64 tradeoff and the size ceilings, which is selection guidance the schema doesn't fully convey. It adds little on fileName or contentType beyond what the schema already documents.

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 ("Upload media to the user's Unsora library") and immediately clarifies the two input paths (source URL vs. base64). It also routes between siblings (create_upload_url + complete_upload, list_uploads), so an agent can distinguish this from them 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?

Explicit guidance on when to use which input: URL preferred (up to 200MB), base64 only for small files (≤ ~7MB), and a direct hand-off to create_upload_url + complete_upload for larger local files. The list_uploads panel alternative is also named, so choice conditions are unambiguous.

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

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

With no annotations provided, the description carries the burden and does well: it discloses the admin-only auth requirement, the 403 failure mode, the DRAFT-vs-PUBLISHED default, and the frontmatter-parsing/override precedence. It stops short of describing behavior on duplicate slugs or existing skills (overwrite vs conflict).

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 critical 'ADMIN ONLY' constraint is front-loaded, and each clause carries information. The parenthetical enumeration of landing page fields is dense, but it maps to real parameters rather than 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 13-parameter mutation tool with no output schema and no annotations, the description covers auth, defaults, and frontmatter handling well. It omits the side-effect/conflict behavior for pre-existing slugs, which would round out completeness.

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

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

Schema description coverage is 100%, so the structured fields already document every parameter. The description still adds non-schema value by explaining that SKILL.md frontmatter name/description is parsed automatically and explicit arguments override it, clarifying the precedence among the 13 fields.

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

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

The description names a specific verb and resource (upload a skill to the catalog) and expands the scope to writing full landing page content, listing the concrete copy artifacts. It is clearly distinguishable from the get-skill and update-skill siblings by its 'upload' action.

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

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

It states the strong precondition 'ADMIN ONLY', warns that non-admin accounts get a 403, and clarifies the default DRAFT outcome unless status is PUBLISHED. It does not explicitly route the agent to update-skill for existing skills, so the sibling distinction is left implicit.

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

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

With no annotations present, the description carries the burden well: it discloses the credit cost per resolution (2/3/5), that the operation is asynchronous and must be polled via wait_for_image, and that it renders a live preview in app-capable hosts. It does not cover failure behavior or how long polling typically takes, which is the remaining gap.

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

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

Four short sentences, each carrying unique payload (capability, cost, input sourcing, polling), with the core purpose front-loaded. No filler or repetition of the tool name.

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, the description supplies cost, async/polling behavior, input provenance, and host preview support, which is nearly everything needed to invoke it correctly. Minor omissions (failure modes, expected wait time) keep it from a 5.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: imageUrl is constrained to public URLs sourced from generation outputUrl or upload_file, and resolution choices are tied to specific credit costs. That is value beyond the schema's terse field descriptions.

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 (upscale) and resource (image) with an explicit range of outputs (2K/4K/8K) and names the product surface (Image Upscaler). An agent can immediately separate it from the sibling upscale_video without opening either 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 the workflow context an agent needs: the input must be a public URL, either a generation outputUrl or an upload_file url, and results are polled with wait_for_image. No explicit when-not-to-use or alternative routing (e.g., vs. create_image) is given, 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?

With no annotations, the description carries the full burden and does well: it discloses that the operation is asynchronous (poll with wait_for_video), that input must be a direct file URL rather than a page URL, that cost scales with model and duration, and that some hosts render a live preview. It omits failure behavior, typical completion time, and whether credits are consumed on failure.

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 purpose, then the credit/model table, then the operational steps, ending with the preview note. Every sentence earns its place, though the compressed credit notation ('6 / 11 / 16 credits for up to 5s / 10s / longer') takes a moment to decode.

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 annotations and no output schema, so the description must cover the workflow — and it does, naming the polling companion tool and the cost model. The main residual gap is that it never states what the tool returns (e.g. an outputUrl) or how long the job typically takes, which an agent must know to hand off to wait_for_video.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: videoUrl must be a direct video file URL with concrete .mp4 / outputUrl / upload_file examples, and the model enum is annotated with credit pricing at different durations. That is substantive semantics beyond the schema's 'Direct URL of the video file to upscale.'

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 — 'Upscale a video's resolution and sharpness' — with the parenthetical '(Video Upscaler)' clarifying the feature identity. It is trivially distinguishable from upscale_image by resource type and from create_video by being an enhancement rather than a generation.

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

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

Gives concrete operating guidance: pass a direct video file URL (explicitly a generation outputUrl or upload_file url) and poll with wait_for_video. The per-model credit tables implicitly guide model selection by cost. It does not state exclusions — e.g. max input duration/resolution or when upscaling is inappropriate — so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety/idempotency profile is covered. The description adds genuine behavioral context by implying a non-blocking, single-shot call that returns immediately (as opposed to a polling wait). It does not describe what status values are returned or what happens for an unknown/expired 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 short sentence with the core operation front-loaded and zero padding. It is efficiently written; the terseness is a function of under-specification rather than verbosity, but structurally it is clean.

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

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

With no output schema and 0% parameter description coverage, the description should explain the return (what statuses look like) and how it relates to wait_for_video. Neither is present, so an agent cannot fully reason about the result shape or when to prefer this over waiting.

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, yet it explains neither parameter. It does not clarify that 'id' is a generation identifier, nor that 'tool' must match the type of generation being queried (the enum's 12 values are listed but their relationship to the id is unstated). The schema enum is self-evident, but the id/tool coupling is not.

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

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

The description gives a verb-adjacent phrase ('generation status check') and a scope modifier ('single-shot'), so the agent knows it is a one-off poll. However, it never says the resource is *video* specifically nor distinguishes itself from the many sibling *_status tools (audio_status, image_status, clipping_status). The purpose is implied but not sharply 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 when-to-use or when-not-to-use guidance. Critically, the polling sibling wait_for_video exists and is the obvious alternative, yet the description does not mention it or state when a single-shot check should be preferred over waiting. Only the word 'single-shot' hints at a distinction.

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 say readOnly/openWorld=false; the description adds polling cadence (30s), the terminal states, and what is returned, which is real added value. Minor gap: 'Checks every 30 seconds' reads as a fixed cadence even though intervalSeconds is exposed (2–60), and nothing says what happens when maxAttempts is exhausted.

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?

Purpose is front-loaded and the exclusion clause follows immediately; every sentence carries routing or behavior information. Slight redundancy in stating 'until COMPLETED or FAILED' twice, which could be tightened into one sentence.

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

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

There is no output schema, and the description does cover the return ('clips with output URLs'), which is the most important piece. It omits how long the call can block, what a non-terminal/exhausted result looks like, and whether it errors on an invalid clippingId — meaningful gaps for a tool that may wait hours.

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 three parameters, so the description must carry the load and only partially does: the 30-second figure implies intervalSeconds' default, but maxAttempts (what it counts, its default, and the outcome when it runs out) and the format/validity of clippingId are entirely 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 ('Poll an AI clipping job until COMPLETED or FAILED') plus the return payload ('clips with output URLs'). It does not explicitly distinguish itself from the sibling clipping_status tool, which is the nearest ambiguity an agent faces.

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

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

Gives explicit negative guidance ('Do NOT use this when the live preview panel is rendered') and names the two conditions under which it should be used (hosts without the preview, user explicitly asks for output URLs). This is about as close to definitive routing as a description gets.

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

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

The description contributes the polling cadence and the two terminal states, which annotations (readOnlyHint/openWorldHint only) do not cover. But it omits the most important behavioral fact for a blocking tool: what happens when maxAttempts is exhausted (up to 120 attempts), i.e. whether it times out, throws, or returns a partial job.

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 and short, which is good, but 'until COMPLETED or FAILED' appears twice in two sentences, wasting the opening's emphasis. The tool-name list is dumped inline without explaining what the agent should do with it.

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 long-blocking polling tool with no output schema and three undocumented parameters, the description should state timeout/attempt-exhaustion behavior and what the caller gets back on success versus failure. None of that is present.

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 explains none of the three: generationId, maxAttempts, and intervalSeconds go undefined. Worse, 'Checks every 30 seconds' implies a fixed interval and conflicts with the intervalSeconds parameter (2-60s), potentially misleading the agent into not setting it.

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

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

States a specific verb and resource ('Poll an image job') and enumerates the five creating tools whose jobs it covers (create_image, create_influencer, create_thumbnail, upscale_image, create_movie_material). It is clearly separable from the wait_for_video/wait_for_clipping/wait_for_music siblings, but never distinguishes itself from the closely related image_status sibling.

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

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

The list of originating tools clearly signals 'use this after one of these creation calls,' which is genuine usage context. However, no condition is given for choosing this blocking poll over image_status, nor any warning about how long the caller may be blocked.

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 declare readOnlyHint=true and openWorldHint=false, so the description usefully adds the polling cadence and the two terminal states. It omits blocking/long-running behavior and what happens when polling stops without a terminal state (maxAttempts ceiling of 180 is never mentioned). The stated fixed 'every 30 seconds' also sits awkwardly against a configurable intervalSeconds parameter.

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?

Very short and front-loaded with the terminal conditions, but the second sentence merely restates the first ('until COMPLETED or FAILED' appears twice). The space saved by cutting the redundancy could have documented maxAttempts or timeout semantics.

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?

A blocking polling tool with no output schema, no annotation detail, and zero parameter documentation leaves key questions unanswered: what is returned on timeout, what statuses exist beyond COMPLETED/FAILED, and what the result payload contains. Given the tool's complexity and silent 0% schema coverage, the description is under-built.

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 three parameters, so the description carries full burden and only partially discharges it — it implies the interval behavior but never explains intervalSeconds, maxAttempts, or generationId. The hard-coded '30 seconds' actually obscures the fact that the interval is configurable between 2 and 60.

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 and resource: polls music generation status until a terminal state (COMPLETED/FAILED). This clearly separates it from create_music, but it never distinguishes itself from one-shot status checkers like audio_status, which an agent could easily confuse for a music 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?

Usage is only implied by the 'poll until COMPLETED or FAILED' framing — an agent can infer it goes after create_music. There is no explicit 'use this after submitting a music job' statement and no exclusion such as 'use audio_status for a single non-blocking check'.

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=true already declaring the safe-read profile, the description adds useful behavior (30-second polling cadence, terminal states). But it omits the most operationally important trait: this is a blocking call that can run for a long time (maxAttempts up to 180), and it doesn't say what is returned or whether the call returns early on timeout.

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

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

It is short and front-loaded, but the second sentence largely repeats the first — 'until COMPLETED or FAILED' appears twice while no space is given to unmentioned parameters or return behavior.

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

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

For a blocking poller with zero schema descriptions and no output schema, an agent still lacks what the call returns on success/failure, default attempt/interval values, and typical wait duration. The description covers the happy-path semantics only.

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 all three parameters, so the description must compensate and does not: generationId (required) and maxAttempts are never mentioned. Worse, the claim 'checks every 30 seconds' implies a fixed cadence that conflicts with the intervalSeconds parameter (2–60), which could mislead an agent about tunability.

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 ('Poll a video job until COMPLETED or FAILED') and enumerates exactly which job-producing tools it applies to (create_video, create_motion_control, create_avatar_video, upscale_video). This clearly separates it from wait_for_image, wait_for_music, and video_status.

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

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

Naming the four originating tools gives strong context for when this tool is the right choice. However, it never contrasts with video_status (the non-blocking status check) or states that this call blocks until completion, so the agent must infer why it would pick blocking over a single status read.

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

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

Annotations already carry the safety profile (readOnlyHint=true, openWorldHint=false), so the lower bar applies. The description does add genuinely useful behavior — this is a polling/blocking call with the terminal states COMPLETED and FAILED — but it omits the worst case: with maxAttempts up to 180 at 30s, a call can block for ~90 minutes, and nothing warns about that or about what happens when attempts are exhausted.

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?

Only two sentences, but the second is a near-verbatim restatement of the first ('until COMPLETED or FAILED' appears twice), so half the text earns nothing. The interval detail should have been replaced with parameter and return-value 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?

No output schema exists, so the description must explain what comes back when the job completes or fails — it does not (status field? asset URL? error reason?). Combined with undocumented parameters and no timeout/retry semantics, an agent cannot confidently call this for anything beyond the happy path.

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% for all three parameters, so the description had to compensate and does not: generationId, maxAttempts, and intervalSeconds are never explained. Worse, 'Checks every 30 seconds' states a fixed interval as fact while intervalSeconds is configurable (2–60), which misdirects the agent rather than helping it.

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

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

Specific verb and resource: 'Poll a voiceover or change_voice job' — it names both the resource and the sibling job type (change_voice) it also covers, which helps distinguish it from audio_status or wait_for_video. It stops short of explicitly routing against the other wait_for_* siblings, but the purpose is unambiguous.

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

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

Usage is implied — call it after creating a voiceover or change_voice to block until the job settles. There is no explicit when-to-use/when-not guidance, no mention of the non-blocking alternative (audio_status, list_generations), and no guidance on what to do on timeout or on re-calling after FAILED.

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