PopNow

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

Annotations already declare non-read-only, open-world, non-idempotent behavior; the description adds the cost model (quoted price, user confirmation implied by using max_usd/max_credits), the credit-vs-USD auth split, and the return artifact. It doesn't discuss failure modes or whether a second call re-charges credits.

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 earning its place: what it produces, how billing works, and how to consume the result. Front-loaded with the capability, 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?

Covers the capability, billing/auth branches, and output handoff to compose_video, which is what an agent needs for a 7-param paid tool with no output schema. Minor gaps remain around duration defaults and what happens on partial or failed generation.

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

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

Schema description coverage is 100%, so every one of the 7 parameters is already documented, including the billing semantics of max_usd and max_credits. The description only reinforces billing purpose; it adds no parameter detail beyond the schema, which is the expected baseline of 3.

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

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

Specific verb plus resource: 'Make matching sound effects and ambience for a (silent) video', with concrete examples (footsteps, rain, crowd). The video-input framing implicitly separates it from create_sound_effects and create_music, but 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?

Gives clear operating context: it quotes a price before spending, uses credits under OAuth vs USD under an API key, and tells the agent what to do next (call compose_video with this result as sound_url). It does not state when a user should prefer create_sound_effects or create_music over this tool.

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

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

Annotations only declare the generic mutation profile; the description adds real behavior beyond them: no credits are consumed, in-progress job_ids fill in later, changes are additive-only (never overwritten), and a stale base_version causes a no-op that returns the new version. It also tells the agent to hand the user the canvas link afterwards.

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 and the most decision-relevant facts (free, additive, use create_* first), and the sentences are dense with information rather than filler. The draft-card parenthetical about Shoot and pricing is slightly chatty, but nothing is redundant enough to waste space.

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

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

For a 7-parameter mutation tool with no output schema, the description covers cost, conflict handling, continuation via canvas_id, and the post-call instruction to surface the canvas link. It does not describe the shape of a successful result beyond the link/version hints, 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 100%, so baseline is 3; the description still adds value by explaining placement semantics that go past the enum (right of existing cards, under them, next to a named card, or inside a named group) and by clarifying base_version's usually-omitted role. Most remaining per-item detail (inputs wiring, index, model) lives in the schema rather than the prose.

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 and resource ('Put things on one of the user's PopNow canvases') and enumerates the exact item kinds accepted (media, notes, drafts). It explicitly separates itself from the creation siblings by saying to call create_image/create_video first and then add the result here.

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?

States the triggering user intents ('put things on a canvas', 'lay out a storyboard or board'), names alternatives (create_image, create_video, get_canvas), and gives the continuation rule: reuse canvas_id from the earlier result instead of starting a new canvas. Conflict recovery is spelled out ('call get_canvas and try again').

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 non-readonly, openWorld, non-idempotent, non-destructive. The description adds real value beyond that: two separate billing wallets (site credits vs USD), a per-image credit floor, and a mandatory quote-then-confirm gate before spending. It doesn't disclose the return shape or whether the result is synchronous, 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?

Three sentences, front-loaded with the purpose before billing and approval mechanics. Each sentence carries distinct information with no filler. Slightly dense in the pricing parenthetical, but nothing is redundant.

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

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

No output schema exists, and the description never says what comes back or whether the agent must poll get_job, which is a real omission for an openWorld, non-idempotent generation tool. On the input side it is complete, since the schema fully covers the image vs image_url split and the approval parameters.

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

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

Schema coverage is 100%, so baseline would be 3. The description still adds sequencing semantics the schema can't express: max_credits and max_usd must only be set after the user confirms a quoted price, and the currency field must match the auth type. That ordering constraint is genuinely beyond the per-field schema text.

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

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

States a specific verb and resource transformation: anime/cartoon character picture into a photo-real version. This is distinguishable from siblings like upscale, edit_image, or relight_photo because the input domain (anime/cartoon) and the output (photo-real) are both named. It doesn't explicitly name a sibling it replaces, 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?

Gives an explicit required workflow: omit approval to get a quote, then confirm with max_credits (OAuth) or currency USD + max_usd (API keys). This tells the agent the two-step call sequence. It doesn't say when to prefer this over edit_image or upscale for similar-looking requests, so no exclusions are stated.

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

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

Annotations already declare this is a non-read-only, non-idempotent, open-world mutation. The description adds valuable behavioral context beyond annotations: videos take 1–3 minutes, billing differs between OAuth credits and API-key USD, and the tool quotes the price before spending. It does not cover return values, but that is acceptable without an 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?

The description is front-loaded with the core action and examples, then adds timing and billing information. It is appropriately sized and readable, though the example list could be trimmed slightly without losing meaning.

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

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

For a mutation tool with full schema coverage and annotations, the description provides the key missing context: latency and payment/quotation behavior. It does not explain return payloads, but no output schema exists, and the core calling information 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 100%, so parameter meaning is already well documented. The description adds only billing context and a mention that the tool quotes price, without expanding on parameter constraints beyond what the schema already says.

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

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

The description clearly states a specific verb and resource: turning a photo into an effect video or photo makeover, with named examples. It does not explicitly differentiate the tool from siblings like create_video or edit_image, but the effect-focused phrasing makes its niche understandable.

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 use-case examples but no explicit guidance on when to choose apply_effect over alternatives such as edit_image or create_video. Usage is implied by 'fun effect video' and 'photo makeover,' but there is no when-not or alternative-routing instruction.

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 non-read-only, open-world, non-idempotent but non-destructive, and the description adds real context on top: site credits starting at 30 per image on the default model, a separate USD wallet for API keys, and the quote-then-confirm gate. It does not say whether the call returns a quote object or an async job, which would close the loop.

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 purpose before billing mechanics, with no filler. The billing sentence is dense and packs two payment paths plus a two-step confirmation into one line, which is efficient but slightly overloaded.

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-object tool with full schema coverage and no output schema, the description covers purpose, cost model, and the approval prerequisite an agent needs before invoking. The main gap is the return shape — the description implies a quote is returned if unapproved but never says what an approved call yields.

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 parameter documentation is already baseline-adequate. The description still adds value beyond the schema by tying max_credits to the OAuth path, currency/max_usd to API keys, and explaining the quote-confirm sequencing — though it doesn't clarify the image vs image_url split (left entirely to the schema).

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

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

States a concrete transformation verb ('Show the same scene or subject from a different viewpoint'), which is more specific than the title and clearly distinct from sibling transforms like change_pose or relight_photo. It never names a sibling or states the boundary, so the differentiation is implied rather than explicit.

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

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

Gives a procedural rule for the two-step approval flow ('Omit approval to get a quote, then confirm max_credits...'), which is genuine usage guidance for how to call it. However, it says nothing about when to pick this over change_pose / edit_image / create_image, or what input is required (a source image), leaving the main selection decision 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 non-read-only, open-world, non-idempotent. The description adds real behavioral context the annotations don't carry: credit pricing from 30 credits/image, a separate USD wallet for API keys, and a quote-then-confirm two-step approval flow. It omits whether the call is async or returns a job handle for polling.

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 operation before the billing detail. The final sentence is dense but each clause (quote, max_credits, currency/max_usd) maps to a distinct action, so little is wasted.

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

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

For a 7-parameter, nested-object, open-world generation tool with no output schema, the description covers the hardest part (billing approval) well but says nothing about what comes back — presumably a job to poll via get_job — or whether the call is asynchronous. That is a meaningful gap given the absence of an 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 100%, so every parameter, including the nested image object and the max_credits/max_usd distinction, is already documented in the schema. The description restates the OAuth vs API-key approval parameters but adds no syntax or constraint beyond what the schema says (e.g. 'Never convert max_credits'). 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 — 'Re-pose the person in a photo to match the pose in another picture' — which is concrete enough to separate it from near neighbors like change_camera_angle, copy_motion, and relight_photo. The two-input structure (subject photo + pose reference) is made explicit.

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

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

Gives clear procedural guidance for the billing path: omit approval to get a quote, then confirm max_credits (OAuth) or currency/max_usd (API keys). It does not address when to choose this over a sibling such as copy_motion, but the 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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond that by disclosing that the return type varies with the authentication method, which annotations cannot express.

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

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

A single sentence with no filler, front-loaded with the action and immediately followed by the two result variants. Nothing could be removed without losing information.

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

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

With no parameters, no output schema, and full annotation coverage, the description covers the only remaining unknown: what the returned balance means under each auth mode. That is exactly the gap an agent would otherwise hit.

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

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

The tool takes no parameters, so the schema carries no semantics to supplement and the baseline of 4 applies. The description's only semantic note concerns the output shape, not inputs, which is appropriate here.

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

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

States a specific verb and resource (show wallet balance) and immediately clarifies the two distinct result shapes: site credits for OAuth vs. decimal USD for API keys. It is trivially distinguishable from every sibling, all of which are media creation/editing 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?

There is no explicit when-to-use or when-not-to-use guidance, but for a zero-argument read tool with no functional sibling there is little to disambiguate. The account-type split implicitly tells the agent what it will get back depending on auth context.

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

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

Beyond the annotations, the description adds important behavioral context: composition is free for OAuth and API keys, neither wallet is charged, it only edits existing media, it takes about a minute, and it returns a link. These details materially help an agent understand cost, runtime, and output.

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 front-loaded with the core action and scope, followed by cost, runtime, and return behavior. Despite covering several important points, it remains tight and avoids unnecessary 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?

For an 11-parameter composition tool with no output schema, the description supplies the missing behavioral context: cost model, runtime, output link, and the boundary between editing existing media and generating new media. Combined with the fully documented schema, this is complete enough to call the 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 description coverage is 100%, so the input schema already explains all parameters, including clip motion, timing, music, subtitles, and transitions. The description adds little parameter-level detail beyond the schema, so the baseline score 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?

The description states a specific verb and resource: cutting videos and pictures from earlier results into one finished MP4, in order. It also explicitly contrasts this with generating new media, which helps distinguish it from sibling 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?

It clearly says to use this when combining existing clips into one video, and explicitly warns that new media should be generated separately. However, it does not name specific alternatives such as create_video or edit_video, so the guidance is strong but not exhaustive.

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

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

Annotations only declare openWorldHint, non-idempotent and non-destructive; the description adds substantial context beyond that — dual billing rails (OAuth site credits vs API key USD wallet), a concrete price floor (101 credits per second with the default model), and a two-step quote-then-approve protocol. It does not disclose the return shape (e.g. whether a job id is returned and must be polled via get_job), which is the one notable behavioral 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?

Purpose is front-loaded in one sentence, then billing/approval rules follow in a logical order. The final sentence is dense with billing jargon but every clause carries actionable information; nothing is padded.

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

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

For an 8-parameter, nested-object, open-world generation tool with no output schema, the description covers inputs, billing modes, and the cost-confirmation protocol well. What it omits is post-call behavior — whether this submits an async job and what the response contains — which matters given the sibling get_job exists.

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 ordering semantics the schema does not: pricing parameters are only to be set after the user confirms a quote, and max_credits/max_usd are mutually tied to the auth mode. That cross-parameter relationship is genuine value beyond the 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?

The opening sentence states a precise verb+resource+mechanism: animate a character picture using the motion of a separate video. That combination of inputs (still image + motion source clip) clearly separates it from siblings like change_pose, create_video_from_references, and compose_video, which an agent can distinguish 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?

The description gives real workflow guidance for the approval/quote cycle (omit approval to get a quote, then confirm max_credits or max_usd), which is useful. However, it never says when to pick this over the many sibling motion/video tools, and gives no exclusions or prerequisites for the source inputs.

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

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

Beyond the annotations (non-readOnly, non-idempotent, non-destructive), the description adds genuinely useful behavior: spend is charged in site credits under OAuth or USD under an API key, the tool quotes the price first, and it returns the picture plus a link. The cost/quote disclosure is exactly the kind of spending context annotations do not carry. It does not mention whether a job id is returned for polling, which is a minor gap.

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

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

Three short sentences with zero filler: purpose first, then billing mechanics, then return value. Every sentence earns its place and the most decision-relevant fact (what the tool does) is front-loaded.

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

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

With no output schema, the description correctly covers the return value (image plus link) and the cost/quote flow, which is the riskiest aspect of an irreversible spend. The remaining gap is execution model: the presence of get_job among siblings suggests possible asynchronous job submission, which the description does not address.

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

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

Schema description coverage is 100%, so the schema already documents prompt, model, aspect_ratio, currency, max_credits and max_usd in detail. The description reinforces the currency/credits vs USD split and the quote-then-confirm flow but adds no syntax or format detail beyond the schema. Baseline 3 applies.

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

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

"Make a new picture from a description" states a specific verb (generate) and resource, and the phrase "new picture" implicitly separates it from edit_image, expand_image, upscale and remove_background. It stops short of naming those siblings explicitly, so differentiation is inferred rather than stated.

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 conveys implied usage (generate a fresh image from a prompt) and explains the two billing modes, but gives no explicit when-to-use / when-not-to-use guidance against siblings like edit_image or create_video_from_references. An agent must infer the selection rule from the tool name and schema.

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

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

Annotations cover the mutation/safety profile, and the description adds genuinely useful behavior: the operation spends credits or USD, distinguishes auth modes, and quotes a price before the agent commits. It omits whether generation is asynchronous and returns a job to poll via get_job, which is a notable 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?

Two tight sentences, front-loaded with the core action and followed by the billing model. Nothing is redundant or padded.

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

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

For an 8-parameter, credit-spending creation tool with no output schema, the description supplies the essential pricing and auth context. It stops short of explaining the async execution model or what the call returns, which an agent needs in a job-based sibling ecosystem.

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 all eight parameters including the billing split and confirmation requirement. The description restates the OAuth/USD distinction rather than adding syntax or format detail beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Make an original song or instrumental track') with the input basis ('from a description'). It clearly separates the tool from siblings such as create_sound_effects and create_speech, which produce other audio types.

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

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

Usage context is only implied through the billing sentence (credits with OAuth, USD with an API key). There is no explicit 'use this when X, use sibling Y instead' routing, even though several audio-creation siblings exist.

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

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

Annotations only declare a non-readonly, non-idempotent, open-world generation call; the description adds substantive behavior beyond that: dual billing rails (site credits vs. USD wallet), a ~360-credit default cost, and a two-step quote-then-confirm flow. It does not explain async behavior or how results are retrieved (get_job), which would round this out.

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

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

Three sentences, front-loaded with what the tool makes, then the billing mechanics. Dense but every clause carries information; the billing sentence is compressed to the edge of readability 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 6-parameter, non-idempotent, 360-credit generation tool with no output schema, the description covers the critical decision surface: cost model, quote-then-confirm safety, and per-auth billing fields. The only gap is what happens after submission (result retrieval/polling), which an agent would need to guess.

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

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

Schema coverage is 100%, so prompt, image, image_url, currency, max_credits and max_usd are already fully documented, and the description largely restates that billing pairing. It does add the useful constraint 'never convert max_credits' and the credit-cost magnitude, but the schema does most of the work, 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?

The first clause names a specific verb and resource — building a short audio scene of sound effects, ambience and acted voices — which implicitly separates it from siblings like create_music and create_speech. It stops short of naming those siblings explicitly, so an agent must infer the boundary from the phrasing.

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 a concrete approval workflow: omit approval to get a quote, then confirm max_credits (OAuth) or currency/max_usd (API keys). That is genuine usage guidance, but there is no when-to-use-this-vs-create_music/create_speech guidance, so an agent choosing among audio tools gets no help.

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

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

Annotations only declare the safety profile (not read-only, not destructive, not idempotent). The description adds genuine context beyond that: the operation is metered by text length, billed in site credits for OAuth or USD for API keys. It does not disclose latency, async/job behavior, or rate limits, which keeps it from a 5.

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

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

Two short sentences with no waste, and the core capability is front-loaded ahead of the secondary pricing detail. Nothing needs trimming or reordering.

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 generative tool with no output schema, the description leaves a real gap: it never states what comes back (audio payload vs job id) or that generation may be asynchronous. Purpose and cost model are covered, but an agent still cannot predict the response shape.

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

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

Schema description coverage is 100%, so every parameter including voice, style, currency, max_usd and max_credits is already documented with examples and constraints. The description adds no parameter-level meaning; the pricing sentence merely echoes the credits-vs-USD distinction the schema already spells out.

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: 'Turn text into natural speech, in many voices and languages.' This is unambiguously a text-to-speech tool and is readily separable from siblings such as create_music, create_sound_effects and transcribe_audio 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?

No when-to-use or when-not-to-use guidance and no named alternatives. The only conditional content is billing-related ('OAuth or USD with an API key'), which is about payment mode rather than tool selection, so an agent gets no explicit routing help.

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

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

Annotations only cover safety/idempotency; the description adds genuinely new behavior: the cost model (site credits with OAuth, USD with an API key) and expected latency of 1-3 minutes. It omits how the result comes back (async job, presumably polled via get_job), which would be the next valuable 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?

Two compact sentences with zero waste; the capability statement comes first and the cost/latency facts second. Nothing redundant with annotations or schema.

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

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

For a 9-parameter, nested, non-idempotent, open-world creation tool with no output schema, the description covers cost and latency but says nothing about the asynchronous job lifecycle (submit -> poll get_job) or what identifier is returned. That is a meaningful gap for an agent to call it end-to-end 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 all nine params, including the image vs image_url split and max_usd confirmation flow. The description's 'bring a photo to life' echoes image_url's own text rather than adding new meaning, so baseline 3 applies.

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

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

States a specific verb and resource ('make a short video') plus the two input modes (text prompt or photo). It does not name or differentiate itself from close siblings like create_video_from_references or extend_video, which is the only thing keeping it from 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?

It gives useful context (billing by OAuth credits vs API key USD, 1-3 minute runtime) from which usage can be inferred, but never states when to pick this over create_video_from_references, compose_video, or extend_video. The agent is left to infer the routing.

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

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

Beyond the annotations (which only mark it as a non-readonly, open-world, non-idempotent write), the description discloses the cost model (from 25 credits per second with the default model), two separate billing wallets depending on auth mode, and a mandatory quote-then-confirm approval handshake. These are exactly the behavioral facts an agent needs before spending a user's money.

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: capability first, cost model second, approval workflow third — properly front-loaded with no filler. The billing sentence is dense but every clause carries information the agent cannot get from the structured fields.

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

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

For a 9-parameter, open-world, nested-object generation tool with no output schema, the description never says what comes back — a finished video, or (given sibling get_job) a job handle that must be polled. It also doesn't mention reference image limits or ordering beyond what the schema says. Cost and approval are well covered, return behavior is not.

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 would be 3, but the description adds cross-parameter semantics the schema only states in isolation: the sequencing where no approval yields a quote, and only a confirmed quote unlocks max_credits (OAuth) or currency=USD with decimal max_usd (API keys). It reinforces rather than contradicts the per-field schema text.

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

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

The opening sentence names a specific verb and resource plus the distinctive capability: making a video that preserves characters, products, outfits or places from reference pictures, driven by a shot description. That clearly separates it from plain create_video, but the sibling is never named, so the agent must infer the boundary from the phrasing alone.

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

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

The description gives explicit procedural guidance: omit approval to obtain a quote first, then confirm max_credits for OAuth or currency=USD plus max_usd for API keys, and it states which billing path applies to which auth mode. It does not cover when to choose this tool over create_video, extend_video or compose_video, which is the remaining gap.

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

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

Annotations already declare non-read-only, open-world, non-idempotent behavior. The description adds genuinely new behavioral context beyond annotations: dual billing paths (OAuth credits vs API-key USD) and, importantly, that the tool quotes a price before committing spend. It does not describe the return format or async job behavior, but for an annotation-backed definition this is solid added value.

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 waste: the functional purpose is front-loaded, followed by the commercial/billing constraint. Every clause earns its place.

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

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

With 9 parameters, a nested image object, and no output schema, the description covers purpose and billing but says nothing about what the agent gets back (an edited image? a job id?), whether the call is synchronous, or what the quoted-price confirmation flow looks like end to end. Adequate but with clear gaps for a tool of this complexity.

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

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

Schema description coverage is 100%, so every parameter including max_usd, currency, image vs image_url split, and more_image_urls is already fully documented in the schema. The description adds no parameter-level detail beyond what the schema provides, which is the correct baseline-3 case.

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 ('Change a photo') plus concrete examples of the edit types it supports (style, outfit, background, add/remove). It implicitly distinguishes itself from narrow siblings like erase_object, remove_background, or relight_photo, but never names an alternative, so it falls short of a 5.

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

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

The prompt-based editing use case is implied clearly by the examples, and the billing modes are noted. However, there is no explicit guidance on when to choose this over siblings such as create_image or erase_object, and no exclusions or prerequisites 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?

Beyond the annotations (which only mark it as non-read-only, open-world, non-idempotent, non-destructive), the description discloses pricing (127 credits/second baseline), two separate billing wallets by auth method, and a quote-before-charge confirmation flow — genuinely valuable behavior. The weakness is the phrase 'Omit approval', which does not correspond to any parameter name, leaving the agent to work out that approval means omitting max_credits/max_usd.

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 compact sentences: capability first, billing second, confirmation procedure last — well front-loaded with no filler. The only friction is the undefined term 'approval', which forces a reread against the schema to map onto concrete fields.

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

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

For a 7-parameter mutation tool with no output schema, the description covers cost, auth branching, and input clip length well. It never says what a call returns — a job id, a quote object with cost_usd, or a finished asset — even though the quote flow depends on the agent reading cost_usd from that response, which is a meaningful gap for correct multi-step invocation.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns slightly more by tying parameters to a workflow (quote first, then confirm max_credits or max_usd) and by supplying the per-second pricing that has no schema equivalent. It does not explain model selection or reference_image_urls beyond what the schema already says, so the added meaning is real but partial.

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 and resource ('Change a short video with words') and enumerates the editable dimensions (subject, outfit, setting, style, weather) while constraining behavior ('keeping the motion'). That scope implicitly separates it from siblings like change_camera_angle, copy_motion, and extend_video, but it never names an alternative, so an agent must still infer the boundary itself.

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

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

It clearly explains the two-step usage pattern: call without approval to obtain a quote, then re-call with max_credits (OAuth) or currency USD plus max_usd (API keys) to confirm. It also branches guidance by auth type. It stops short of saying when to prefer this tool over edit_image or the other video siblings, so the routing guidance is contextual rather than explicit.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is partly covered. The description adds meaningful behavioral context: credit-based OAuth pricing, a separate USD wallet for API keys, and a quote-then-confirm approval workflow. It still does not explain the output format or whether the original image is preserved.

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: purpose first, then billing context, then the approval workflow. Every sentence is relevant and front-loaded, 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?

The description covers the core operation, billing modes, and approval sequence, and the schema handles parameters fully. For a tool with no output schema, it could say more about the returned value (e.g., resulting image or job handle), but the essential invocation information 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 coverage is 100%, so the schema already documents all seven parameters, including the nested image object and the billing fields. The description adds only a workflow tie-in for quote/approval and does not add semantic meaning to prompt, mask_url, image_url, or image beyond what the schema provides. 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 first sentence states a specific verb and resource ('Remove an object or person from a photo') and adds the gap-fill behavior, so the action is clear. It does not explicitly distinguish this tool from siblings like edit_image or remove_background, so it falls short of full sibling differentiation.

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

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

The description gives procedural guidance for quote/approval and billing modes, which helps an agent decide how to invoke the tool. However, it never says when to choose erase_object over alternatives such as edit_image, remove_background, or remove_shadow, nor does it provide exclusions. Usage is implied by the purpose rather than explicitly routed.

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 a non-idempotent, open-world write, and the description goes well beyond them by disclosing the dual billing model (site credits for OAuth vs. USD wallet for API keys), the 24-credit floor, and a quote-then-confirm approval gate. It does not disclose what the call returns (e.g., a job handle for get_job polling), which is a real gap given 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?

Three sentences, purpose front-loaded, no wasted framing. The billing sentence is dense and packs multiple conditional branches, but every clause carries operational information an agent needs before spending money.

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-object, financially-gated tool with no output schema, the description covers cost/approval well but leaves the return contract (job id, polling with get_job) unspecified. An agent knows how to pay but not what it gets back.

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 baseline is 3; the description adds value by tying the approval parameters into a coherent sequence (quote first, then confirm max_credits for OAuth or currency=USD plus decimal max_usd for API keys). It does not discuss aspect_ratio or the image/image_url split, but those are fully documented in-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 with scope: 'Extend a photo beyond its edges to a wider or taller shape, filling in matching scenery.' The action is unambiguously distinct from siblings like upscale, edit_image, and extend_video (which operates on video).

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 procedural guidance for the billing flow (omit approval for a quote, then confirm max_credits or max_usd), but never says when to choose this over upscale, edit_image, or change_camera_angle. Usage is only implied by the purpose statement.

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

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

Annotations already declare the mutation profile (readOnlyHint=false, idempotentHint=false, openWorldHint=true), so the safety story is covered. The description adds genuinely non-obvious behavior the annotations don't carry: per-second credit pricing (from 25 credits/sec), a separate USD wallet for API keys, and a quote-then-confirm gate before charges. It does not disclose whether the call returns a job handle or is asynchronous, which matters for a long-running generation.

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, then pricing, then approval mechanics. Dense but every clause carries operational information; the billing explanation is somewhat compressed and could be split more cleanly.

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

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

For a 7-parameter, open-world mutation with no output schema, the description covers cost, auth-path branching, and the confirmation gate well. The notable remaining gap is return behavior — whether a job id is produced and how to poll it (get_job siblings imply async).

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 cross-parameter meaning the schema alone leaves implicit: which of max_credits (OAuth) vs currency + max_usd (API keys) applies to which auth path, and that no cost field should be supplied until a quote is confirmed. The 'omit approval' phrasing is slightly indirect since no parameter is literally named approval.

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?

'Continue a video: add a few more seconds after its last frame' is a precise verb + resource + mechanism, and the phrase 'after its last frame' cleanly separates it from create_video and edit_video in the sibling set. An agent knows exactly what operation this performs 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?

The description spells out the two-step approval workflow (omit approval to get a quote, then confirm max_credits or max_usd) and which billing path applies to OAuth vs API keys, which is real usage guidance. It stops short of explicitly naming when to choose this over create_video or compose_video.

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 read-only, idempotent, non-destructive; the description adds value beyond them by disclosing cost ('Free: nothing is charged'), result count and ordering ('up to 4 options, best first'), and the required conversational follow-up before invoking use_skill.

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

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

Front-loads the purpose and workflow compactly with no filler, though the trailing parenthetical about list_my_skills and the exclusion sentence make it denser than strictly necessary.

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 still conveys what comes back (named styles with preview video or picture), how many and in what order, that it's free, and what to do next—everything an agent needs to call it and handle the result.

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 intent, type enum, and limit bounds are already documented. The description's examples of result kinds loosely echo the enum values but add no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource ('find ready-made skill presets'), enumerates concrete result kinds (launch videos, slide decks, landing pages, editorial images), and explicitly distinguishes itself from the sibling list_my_skills. An agent can immediately tell this apart from use_skill and list_my_skills.

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 full workflow (show options with preview links, ask the user, then call use_skill with the slug) plus explicit negative guidance: not for bookings, shopping, live data, or tasks PopNow can't do. Both when-to-use and when-not-to-use are stated.

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

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

Annotations already declare readOnlyHint/idempotent/non-destructive, so the bar is lower; the description still adds real behavior: pagination via next_offset, short-lived preview link expiry, and that the call is free. Those are traits the annotations cannot express.

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 return contents, then pagination, then cross-tool link reuse. One long first sentence is dense but every clause carries information; 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?

With no output schema, the description correctly carries the burden of describing return values and does so in detail, including pagination semantics. Only the exact shape of the 'outline' and preview link lifetime is left vague.

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 canvas_id, limit and offset are already documented in the schema. The description reinforces the offset/next_offset round-trip but adds little that the schema doesn't already state, 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 ('Read one of the user's canvases') and immediately enumerates what is returned: name, groups, card outline fields, links. An agent can distinguish it from list_canvases or open_canvas purely from this text.

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 downstream guidance: 'pass next_offset as offset to read more', 'Reuse the popnow:// links as inputs for other PopNow tools, and the card ids for add_to_canvas.' It does not explicitly say when to prefer this over list_canvases or open_canvas, but the operational context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the call waits and returns the result once ready, which is useful, but it doesn't disclose what happens on timeout or when the job is not yet finished.

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

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

A single short sentence with no filler, and the polling purpose is front-loaded. It is efficiently stated, though it is arguably terse to the point of underspecification rather than maximally informative.

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 2-parameter tool with full schema coverage and annotations covering the safety profile, this is adequate. However, with no output schema, the description does not explain what is returned when the job is still pending versus finished, leaving a real gap for a result-fetching tool.

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

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

Schema description coverage is 100% (job_id and wait_seconds are both documented in the schema), so the schema carries the parameter burden and baseline is 3. The description adds no syntax or meaning beyond the schema, so it neither compensates nor detracts.

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 conveys a specific action in plain terms: check a pending creation and retrieve its result when done. It is clear enough that an agent understands this is a polling/result-fetch tool, but the resource is described loosely as 'something that is still being made' and it draws no boundary against siblings like list_my_creations or run_model.

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: you call it on work that is 'still being made.' There is no explicit statement of when to poll versus when to use list_my_creations or the creation tools, and no guidance on when not to call it (e.g. after the job has already completed).

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, closed-world and non-destructive, so safety is covered. The description adds real behavioral context beyond them: the run may not be finished yet and results are only returned 'when they're ready', which tells the agent to expect a pending state and poll. It stops short of saying what a not-ready call actually 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 sentence, zero waste, with the resource and the payoff front-loaded. Nothing is padded or repeated from the title.

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

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

With no output schema, the description carries the burden of explaining return values, and it only says 'get its results' without indicating shape, pending/error states, or whether results persist. For a polling tool this leaves a meaningful gap, though the annotations and 100%-covered schema keep it functional.

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?

Single parameter with 100% schema description coverage, so the schema already explains run_id and ties it to run_my_recipe. The description adds nothing further about format or validity, which is the expected baseline when the schema does the work.

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

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

States a specific verb ('check on') and resource ('recipe or workflow run') plus the outcome ('get its results'). It is distinguishable from run_my_recipe and resume_recipe_run, though it does not explicitly separate itself from the sibling get_job, which likely polls non-recipe jobs.

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

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

Usage is only implied: the schema note 'The run id from run_my_recipe' tells an agent to call this after starting a run, and 'when they're ready' hints at polling. There is no explicit when-to-use/when-not, no guidance on polling cadence, and no pointer to resume_recipe_run for stalled runs or get_job for other job types.

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

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

Adds real behavior beyond annotations: newest-first ordering, the exact fields returned per canvas (name, card count, last update, id), and cost/free-ness. "Read-only" largely restates readOnlyHint=true, so it earns a 4 rather than a 5, but the ordering and per-item payload disclosure are genuine value.

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 verb and ordering, then the usage routing. The middle clause defining canvases is slightly verbose but justifies itself by grounding an unfamiliar product concept.

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 compensates by enumerating the returned fields. With only two well-documented optional params and annotations covering the safety profile, nothing an agent needs to call this 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 description coverage is 100%, so limit (1–50, default 20) and search are already fully documented. The description says nothing about either parameter — no hint that search matches names or how limit interacts with result ordering — 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?

Specific verb + resource ("List the user's PopNow canvases") plus a concrete definition of what a canvas is (boards with pictures, videos, notes and shots) and the ordering (newest first). It also implicitly separates itself from get_canvas by framing this as the discovery 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?

Explicitly states the workflow role: "Use it to find the canvas the user means before get_canvas or add_to_canvas." That names both alternatives and the condition that selects them, so an agent knows this is the lookup-first tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'read-only; it doesn't create anything' largely restates structured data. It does add value by disclosing the return content (prices and the corresponding PopNow tool per model), which annotations don't cover, but offers no detail on result format beyond that.

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

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

Two compact sentences that front-load the purpose and then the return content. The trailing 'it doesn't create anything' is mildly redundant against the readOnlyHint annotation, but it costs little.

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

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

With no output schema, the description usefully states what a call returns (models/effects, prices, the PopNow tool to use). For a two-optional-parameter lookup tool this is nearly sufficient; only finer detail on result structure is 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 100% and both parameters are documented in the schema, including the enum and default for category. The description mentions the image/video/audio/effects scope but adds no syntax or behavioral nuance for the model id parameter, so the baseline 3 applies.

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

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

Specific verb ('look up') plus a precisely scoped resource (PopNow's AI models and video effects), with what's returned (prices, the PopNow tool to use for each). This clearly separates it from the many creation/manipulation siblings like create_image or apply_effect, which produce artifacts rather than catalog metadata.

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?

Implies the usage context well: an agent consults this to learn which tool and settings to use for a given model, i.e. before invoking a creation tool. It does not explicitly name alternatives or state when not to use it, but the 'which PopNow tool does it' framing makes its role as a discovery step clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that results include links and are 'recent', which is mild extra context, but says nothing about ordering, default limit behavior, or pagination.

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

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

A single short sentence with no filler, and the core action/resource is front-loaded. It is efficient, though it could have used the saved space to mention the kind/limit filters.

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

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

For a simple read-only list tool with a fully described two-parameter schema and annotations covering safety, the description is nearly sufficient. The minor gap is that 'recent' is undefined and no output/return detail beyond 'links' is given, despite there being no 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 description coverage is 100%, so the enum values for kind and the 1-20 range/default of limit are fully documented in the schema. The description adds no parameter meaning beyond that, 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: showing the user's recent PopNow creations, with a hint at the payload ('with links'). It is clearly distinguishable from the many creation siblings (create_image, compose_video, etc.), though it does not explicitly name any alternative listing tool.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives. The only contextual cue is the word 'recent', which is left for the agent to interpret before or after creating content.

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 destructiveHint=false, so safety is covered. The description adds useful scope context — that team-shared items are included and that returned entries carry their input definitions — which the annotations do not convey.

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

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

Two short sentences: the scope/return statement comes first, the sibling hand-off second. No filler and no restating 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?

There is no output schema, so the description must hint at return content — it does so by saying entries include the inputs each recipe takes. Given a zero-param, read-only list tool this is nearly complete; a note on ordering or empty-result behavior would close the gap.

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

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

The tool takes zero parameters, so there is nothing to mistranslate; the baseline for a no-param tool is 4. The description correctly implies no filtering arguments are available.

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+resource: shows the recipes and workflows a user saved, including team-shared ones, along with each one's inputs. This clearly separates it from sibling list tools such as list_my_creations and list_my_skills.

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 run_my_recipe for execution, which is the natural follow-on action. It lacks explicit when-not-to-use guidance (e.g. 'use get_recipe_run for past runs'), 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?

The annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds useful domain context about what a skill is, but does not describe the return format, ordering, pagination, or whether all skills are shown.

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

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

The description is two compact sentences, front-loads the purpose, and uses the final sentence only to point to the natural follow-up tool. No sentence is wasted.

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

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

For a zero-parameter, read-only listing tool with full annotation coverage, the description is nearly complete. The main remaining gap is that it does not explicitly state that it returns a list of skills, though 'Show' implies this.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and nothing in the description undermines 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: 'Show the user's PopNow skills', and defines them as saved ways of working with steps, models, and checks. It is clear, but does not explicitly distinguish this from the sibling find_skills or list_my_recipes.

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

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

The description gives clear usage context by framing this as listing the user's own skills and explicitly routes detailed reading to use_my_skill. It does not state when to use find_skills or list_my_recipes instead, so exclusions are missing.

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 destructiveHint=false, so 'read-only' largely restates them. 'Free' adds genuine cost information not present in the annotations, and 'Get a link' hints at the return shape, but there is no note on link lifetime, permissions, or whether the link is public.

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

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

One sentence, front-loaded with the core action and value, with no filler. 'Read-only' is slightly redundant against the annotations, but nothing else is wasted.

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

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

For a one-parameter read tool with complete annotations and full schema coverage, the description covers what it does and roughly what it returns (a link). Missing only link-scope details such as expiry or access control, which are minor for this operation.

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

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

Schema description coverage is 100% and the single canvas_id parameter is already documented as coming from list_canvases or add_to_canvas. The description adds no further meaning about the id's format or validity, so the schema carries the full burden.

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: it returns a link that opens one of the user's canvases on popnow.ai. It does not explicitly contrast with the sibling get_canvas or list_canvases, but the 'link that opens' framing is distinct enough that an agent can infer the difference.

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

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

The phrase 'for example to hand it over after adding cards' supplies a concrete use case, which implies when to reach for it. There are no exclusions and no named alternatives, so the agent must infer that get_canvas is the choice when canvas contents rather than a shareable link are wanted.

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 a non-read-only, non-idempotent, open-world operation; the description adds the crucial behavioral context that isn't in structured fields: the credit cost floor (30 credits/image default model), the separate USD wallet for API keys, and the quote-before-charge confirmation protocol. It does not describe what happens on failure or whether a partially-spent quote expires.

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

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

Three sentences, front-loaded with the purpose before the billing mechanics. The dense billing sentence carries a lot at once (credits vs USD wallet, quote then confirm) but every clause is actionable and there is 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 6-parameter, cost-incurring, non-idempotent tool with no output schema, the description covers cost and approval well but says nothing about the return value — an agent can't tell whether it gets a finished image or a job handle to poll with get_job. The image vs image_url split is left entirely to schema descriptions.

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 baseline is 3, but the description adds the relational semantics the schema only implies: omitting the approval fields triggers quote mode, and max_credits vs currency/max_usd are mutually exclusive per auth type. It reinforces rather than duplicates the per-parameter docs.

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 ("Change the lighting of a photo") plus three concrete examples of the transformation. An agent can distinguish relighting from sibling tools like apply_effect or edit_image by intent, though the description never names those alternatives explicitly.

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

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

Gives a clear procedural rule: omit approval to get a quote, then confirm max_credits (OAuth) or currency + max_usd (API keys). It also tells the agent which billing path applies to which auth method. It stops short of saying when to pick this tool over edit_image or apply_effect for lighting-like effects.

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 safety (non-read-only, non-idempotent, non-destructive, open-world). The description adds the crucial behavioral fact that this is a paid operation with two billing paths and a price quote before spend, which annotations do not convey. It omits whether the call is async and how the result is retrieved.

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

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

Two tight sentences; the capability comes first followed by the billing constraint. No filler or repeated structured data.

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 paid, non-idempotent media tool with zero required parameters and no output schema, the description should clarify that image or image_url must be supplied and how the processed image comes back. It covers cost but not the call contract.

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 each parameter is already documented, including the image vs image_url split and the max_usd/max_credits confirmation rules. The description only contributes the notion that a price is quoted first, which loosely ties to the max_* parameters; 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 outcome: cut out the subject and make the background transparent. That distinguishes it implicitly from erase_object (removes a thing) and split_layers (separates layers), but 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 description gives billing context (credits via OAuth, USD via API key, with a quoted price) but never says when to pick this over erase_object, remove_shadow, or split_layers. Usage is only implied by the stated outcome.

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

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

Adds substantial behavior beyond annotations: OAuth credits vs API-key USD wallet, starting cost, and the quote-then-confirm flow using max_credits or max_usd. This tells the agent how a call can result in charges and how to avoid unintended spend.

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

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

Front-loads the purpose, then follows with billing and approval details in two compact sentences. Every sentence carries operational value for invocation.

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 purpose, billing, and approval well enough to invoke correctly, and the schema documents the image fields. With no output schema, it could have said more about the returned result, but the core invocation context is complete.

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

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

Schema coverage is 100%, so the schema already defines all five parameters in detail. The description adds meaningful workflow semantics by linking max_credits to OAuth and currency USD/max_usd to API keys, and by saying to omit approval first for a quote.

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 ('Remove harsh shadows from a photo') with useful examples ('product shot or a face'). It is clear on its own, but does not explicitly distinguish itself from nearby siblings such as relight_photo or edit_image.

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

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

Gives clear usage context with examples and explains the quote/approval workflow before spending credits or USD. It does not state when not to use this tool or name alternatives for shadow correction.

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 non-read-only, non-idempotent, open-world operation. The description adds meaningful behavioral context beyond annotations: approval is required, omitting it yields a fresh quote, and the original key and payer are preserved.

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

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

The description is short and front-loads the core purpose. The procedural sentences are useful, though the reference to 'approval' is slightly confusing because there is no approval parameter in the schema.

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

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

For a four-parameter mutation tool with no output schema, the description covers the key operational flow: quote first, then provide currency, budget, and quote_id, while preserving the original key and payer. It still omits return behavior and error cases, so it is not 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 description coverage is 100%, so all four parameters are already documented in the input schema. The description reinforces the quote flow and budget/currency confirmation but does not add parameter syntax or constraints beyond what the schema already provides.

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

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

The description gives a specific verb and resource: 'Resume a paused API-key recipe or workflow.' That clearly distinguishes resuming from siblings like get_recipe_run or run_my_recipe, though it does not explicitly name 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?

It provides clear procedural guidance: omit approval to get a fresh quote, then confirm currency, max_usd, and quote_id. It does not explicitly state when not to use this tool versus related tools like run_my_recipe or get_recipe_run, so it falls short of a full when/when-not/alternatives statement.

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

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

Annotations already declare the safety profile (not read-only, open world, non-idempotent, non-destructive), but the description adds important behavioral context: billing is split by auth type, API-key runs use a USD wallet, pricing and key limits are checked on every step, and idempotency keys must be reused after a lost response. This goes meaningfully beyond the annotations and 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?

The description is four dense but well-structured sentences. It front-loads the core action and then layers the auth-specific execution flow without filler. Every sentence contributes 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?

Given eight parameters, nested inputs, auth branching, and no output schema, the description covers the critical execution path and billing/idempotency behavior well. It does not mention what the tool returns or how to check run status, which is a minor gap given the sibling get_recipe_run exists.

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 would be 3, but the description adds semantic flow by linking max_credits to OAuth, and max_usd/quote_id/currency/idempotency_key to API-key execution. It helps the agent understand which parameters belong together in the quote-confirm-run sequence, which is more than the schema alone conveys.

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

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

The description clearly states the verb and resource: run a saved recipe or workflow with new material. It distinguishes itself from related siblings like list_my_recipes implicitly through 'saved recipe' and 'new material', but it does not explicitly contrast with resume_recipe_run or get_recipe_run. The purpose is nonetheless understandable 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 provides concrete guidance for OAuth versus API-key usage: OAuth uses max_credits, while API keys must first quote then confirm currency, max_usd, quote_id, and idempotency_key. It also explains idempotency-key reuse after a lost response. It lacks explicit guidance on when to use this versus resume_recipe_run, so it stops short of full 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?

Annotations only say the tool is non-read-only, open-world, non-idempotent and non-destructive; the description goes well beyond that by disclosing the dual billing model (site credits ~42 per image at default vs. a separate USD wallet for API keys) and the quote-then-confirm cost-approval protocol. That is exactly the non-obvious behavioral context an agent needs before spending user money.

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 compact sentences with the purpose front-loaded, then cost model, then the approval protocol. Dense but every sentence carries decision-relevant information; 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 compensates by stating the output is transparent PNG layers. It covers cost and approval flow fully. It does not mention that generation is asynchronous or that results are retrieved via get_job, which is a small but real gap given the sibling set.

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 per-parameter descriptions already carry most semantics and the baseline is 3. The description adds value by linking parameters into a workflow: which approval field pairs with which auth type (max_credits for OAuth, currency=USD plus decimal max_usd for API keys), which is a cross-parameter relationship not obvious from any single field.

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 and resource: 'Separate a finished picture into editable layers (text, people, objects, background) as transparent PNGs.' The enumerated output layer types make it clearly distinct from nearby siblings like remove_background or erase_object, which produce a single modified image rather than a multi-layer breakdown.

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 procedural guidance: omit approval to obtain a quote, then confirm max_credits (OAuth) or currency=USD with max_usd (API keys). It does not explicitly state when to prefer this over remove_background, so the alternative-selection guidance is implied by the layer breakdown rather than spelled out.

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

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

Annotations already declare this is a non-read-only, non-destructive, open-world operation. The description adds important behavioral context about OAuth credits versus API-key USD billing and the quote-confirmation flow, though it does not mention output format or whether transcription is synchronous.

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 front-loaded with the core purpose and then covers billing details in two compact sentences. The billing explanation is dense but each sentence carries relevant 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?

The description covers the critical cost and auth workflow, which is valuable for an open-world write tool with no annotations about billing. It remains incomplete about return format, output structure, and whether the caller should expect a job/polling flow, which matters more because there is no 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 description coverage is 100%, so the schema already documents all six parameters in detail. The description reinforces the OAuth versus API-key billing dependencies, but it also references an 'approval' action that does not appear as a parameter in the schema, which may create slight 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?

The description states a clear verb and resource: turning speech in a recording into text. It is semantically distinct from siblings like create_speech, but it does not explicitly name alternatives or route the agent among siblings.

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

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

The description gives billing workflow guidance, including omitting approval to get a quote and confirming max_credits or max_usd afterward. However, it does not say when to choose this tool over alternatives such as create_speech or other audio tools.

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

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

The annotations already declare this is a non-readonly, non-destructive, non-idempotent, open-world operation; the description adds real value on top by disclosing the dual billing model (site credits under OAuth, USD under an API key) and that video cost is length-dependent. It stops short of describing that this likely creates an async job whose result must be fetched, which is the main behavioral 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?

Two short sentences with the core action first and the billing caveat second; nothing is wasted and the important constraint (cost depends on medium and auth type) lands early.

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

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

For a 7-parameter, nested-object, cost-incurring mutation tool with no output schema, the description is thin: it never says what the call returns, whether the result is synchronous or a job to poll via get_job, or what happens to credits on failure. The schema covers parameters well, but the operational contract is left implicit.

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

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

Schema description coverage is 100%, so size options, the image object, image_url/video_url, and the max_credits/max_usd confirmation flow are already fully documented in the schema. The description only adds that video pricing depends on length, which is marginal over the structured data.

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

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

A specific verb-plus-resource statement ('Make a photo or video sharper and bigger') that immediately tells an agent this is the enlargement/enhancement tool. It is distinguished from siblings by its stated scope but never references adjacent tools such as edit_image or expand_image, so there is no explicit sibling differentiation.

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

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

The billing sentence implies two usage contexts (OAuth session vs API key) and warns that video cost scales with length, which nudges the agent toward a cost check. However, there is no explicit 'use this instead of X when...' guidance and no statement of preconditions or 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?

The annotations already declare readOnlyHint, idempotentHint, non-destructiveness, and closed-world behavior, so the description’s additional context is valuable but not solely responsible for safety disclosure. It adds that the returned content is instructions to follow with other tools and notes the restriction on team-shared use-only skills. It does not describe error cases or authentication requirements, but the annotation coverage lowers that burden.

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 action and followed by the key caveat. Every sentence earns its place with no repetition or filler.

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

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

For a simple one-parameter read-only tool with full schema coverage and annotations covering safety traits, the description is nearly complete. It explains the return intent (instructions to follow) and the main usage restriction, though it could briefly mention whether invalid skill ids or inaccessible skills produce errors.

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 has 100% description coverage and the single parameter is already documented as 'The skill id from list_my_skills'. The description adds no syntax, format, or selection detail beyond what the schema provides, 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?

The description states a specific action and resource: get the instructions of one of the user's skills and then follow them with other PopNow tools. It clearly identifies personal/user skills and distinguishes them from team-shared use-only skills, but it does not explicitly differentiate from the sibling tool use_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?

It gives a clear workflow: retrieve instructions, then apply them with other PopNow tools. It also includes an explicit exclusion for team-shared use-only skills, which cannot be read here. However, it does not name use_skill or find_skills as alternatives, leaving some sibling selection 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?

Annotations already cover the read-only/idempotent/no-destruction profile, and the description layers on genuinely non-obvious behavior: the download link is short-lived, skill use itself is free, generation is quoted before running, and OAuth vs API-key connections draw from separate wallets (API wallet starts at $0, no transfers). That is real cost/authorization context an agent cannot get from the annotations.

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

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

Purpose is front-loaded in the first clause, but the single run-on sentence stacks outputs, an aside about quoting, and a multi-clause billing primer. The wallet/OAuth detail is useful but bloats a retrieval tool whose primary action is 'fetch the preset'.

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

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

With no output schema, the description does the work of describing returns (playbook contents, download link, install commands, media tool mapping). Cost and connection-type behavior are disclosed, so an agent knows what it will get and that calling is free; only the sibling/ordering relationship to find_skills and use_my_skill is left unaddressed.

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

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

Schema description coverage is 100%, so both slug and agent are fully documented in the schema; baseline applies. The description restates the agent intent ('where it will run, or chat when there is no file system') but adds no new syntax or edge-case detail about the 29-value enum or what happens when agent is left empty beyond what the schema already says.

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 ('Get the skill preset the user picked') and enumerates what comes back: SKILL.md playbook, short-lived download link with install commands, and PopNow media guidance. It does not distinguish itself from the sibling use_my_skill or explain the relationship to find_skills, so an agent must infer that split.

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

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

Usage is only implied through 'the skill preset the user picked' and 'Set agent to where it will run, or chat when there is no file system'. There is no explicit instruction to call find_skills first or any exclusion against use_my_skill / list_my_skills, which is a real gap given three skill-related siblings.

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