PrismPoster Studio

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive behavior, so the tool's safety profile is largely covered. The description adds genuinely useful context beyond that: the actual payment happens on an external secure checkout page and 'this tool never charges anything itself,' which resolves the ambiguity of a tool named 'buy'.

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

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

Three tight sentences, front-loaded with what the tool returns, then when to use it, then the payment-safety caveat. No sentence is filler.

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

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

For a no-param, no-output-schema tool with annotations present, this covers the essentials — purpose, trigger, and the fact that charging happens elsewhere. It could go slightly further on what the returned link looks like or whether it expires, but nothing critical 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?

Zero parameters, so there is nothing for the description to disambiguate and no schema gap to compensate for. The baseline for a no-param tool applies cleanly.

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 and resource — returns a link to a credit pack purchase — with the key distinguishing detail that it's a one-time pack, not a subscription. An agent can immediately tell this apart from account/quote siblings like get_account or quote_job.

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

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

Explicitly states trigger conditions: 'when the account is out of credits or the person asks to top up.' Clear context for invocation, though it doesn't name an alternative (e.g., get_account for checking balance) or state when not to use it.

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

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

Far beyond what the annotations declare: credits are spent at prismposter.com parity rates, the original clip is preserved, output lands in the PrismPoster library, and any request needing human consent returns approval_required with nothing running. It also discloses a pre-charge refusal policy, which is exactly the kind of gating behavior an agent must anticipate. Fully consistent with destructiveHint=false and readOnlyHint=false.

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

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

Front-loaded with the action and its invariant, then cost and approval semantics. Dense but every sentence carries decision-relevant information; the long parenthetical listing consent cases is the one spot that could be tightened.

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, no-required-field mutation tool with no output schema, the description still covers what is returned (a new clip, original kept), where it is stored, what it costs, how failures/approvals surface, and policy refusals. An agent has everything needed to call it correctly and interpret 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 coverage is 100%, so baseline would be 3, but the description adds workflow-level meaning the schema lacks: the quote_job pre-pricing step, the resolve-then-rerun approval loop keyed on approval_id, and the cost implication behind choosing a resolution. It does not separately explain engine, aspect_ratio, or idempotency_key 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 and resource ('Change a clip the account made') plus an enumerated scope of edit types and the invariant ('keeping everything else'), with a clear constraint on clip length. An agent can distinguish it from create_video, extend_video and remake_* without opening any schema.

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

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

It clearly establishes the operating context: quote_job prices first for free, the approval_required path halts execution, and content involving minors or public figures is refused before charging. It also constrains length ('up to one take long; for longer clips change only the last stretch'). It does not explicitly name sibling alternatives such as extend_video for longer material, so it stops one step 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?

Goes well beyond the annotations: ~2 minute runtime, credits are spent at the same rate as the website, approval_required pauses everything until the person answers in the PrismPoster card or link, output lands in their library, and requests involving minors or public figures are refused before any charge. These are exactly the side-effect and safety facts an agent needs for a credit-spending mutation.

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

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

Front-loads what gets produced, then layers cost, approval, and policy. Every sentence carries information, though the closing sentences are long chained clauses that could be split for faster scanning.

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

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

For a fixed-price, credit-spending generation tool with no output schema, the description covers outcome, cost, timing, approval gating, refusal policy, and where results are stored. The only unstated detail is the exact return payload (job id), which get_job and the approval_required flow already imply.

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

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

With 50% schema coverage, the description compensates by enumerating the optional attributes (age, hair, eye colour, clothing, height, personality) that the undescribed enum parameters carry, and it explains the naming/@tag mechanic behind `name`. It leaves `approval_id` and `idempotency_key` to their schema descriptions, which already document them adequately.

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 (design a character sheet with full-body turnaround views and an expression grid) and explains the outcome — visual consistency across later images and videos. That clearly separates it from create_image, edit_image, and preview_remake_cast without requiring the sibling schemas to be opened.

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 usage context: describe freely, optionally pin age/hair/eyes/clothing/height/personality, and name it to get an @tag for later prompts or Remake casting. It also points to quote_job for a free price check before spending. It never explicitly says when NOT to use it (e.g. use create_image for a one-off picture of an existing subject), so it stops short of full alternative routing.

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

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

Goes well beyond the annotations: discloses that credits are spent at the same rate as the website, that approval_required halts execution and nothing runs or charges until answered, that output is saved to the library, and that under-18 or public-figure requests are refused before any charge. These are exactly the side effects an agent needs for a non-destructive-but-charging write tool.

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

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

Purpose and capability set are front-loaded in the first sentence, with cost, approval and refusal semantics following. The prose is dense but nearly every clause carries information; the long aspect-ratio enumeration is slightly redundant with the schema enum.

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 covers the two return behaviors that matter (approval_required vs. saved-to-library) and discloses the billing and refusal rules. It does not describe the successful job payload (job id, status, polling via get_job), leaving a small gap for a charging async tool.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds real meaning on top by explaining reference 'use' as keep-subject vs borrow-style, tying aspect ratios to concrete outputs (Instagram post, story, thumbnail), and noting resolution affects cost. It omits any guidance on approval_id/idempotency_key, though the schema documents those thoroughly.

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

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

Opens with a specific verb+resource ('Make an AI image from a prompt') and enumerates the capabilities that distinguish it: styles, reference matching, saved characters, aspect ratios, resolution tiers. An agent can tell this apart from edit_image or create_video 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?

Gives concrete use conditions (references for keeping a product/person, @tag for a saved character, approval flow when a person must decide) and points to quote_job as the free pricing alternative. It does not explicitly exclude edit_image for modifying an existing picture, so the when-not side is implied rather than stated.

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

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

Goes well beyond annotations by disclosing credit spend, per-cut export-equivalent pricing, free quote preflight, approval_required gating, saved library outputs, and the editor-project side effect for the tallest cut. The opt-in idempotency_key also adds retry behavior without contradicting idempotentHint=false.

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

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

The purpose is front-loaded and the description is structured around what it does, prerequisites, pricing, approval, and refusals. It is somewhat long, with a few side-effect sentences that could be compressed, but the length is largely justified by billing and approval complexity.

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

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

Covers prerequisites, cost, approval flow, refusal rules, and where outputs are saved, which is substantial for a complex mutation tool. However, without an output schema, it does not explain what a normal successful response contains, such as job identifiers or cut references.

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 parameters are already well-documented. The description repeats caption safe-area placement, clip sources, and placement defaults, but adds little syntax or meaning beyond the schema itself.

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: turning one finished clip into placement-specific cuts, with cropping and optional captions. It enumerates placements and distinguishes prerequisite siblings like create_video and list_library, so the agent can identify the tool's role immediately.

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

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

Explicitly says to make or pick the clip first via create_video or list_library, to use quote_job for free pre-pricing, and that approval_required pauses execution until the person answers. It also states hard refusal cases for minors, public figures, and office holders, giving clear when-to-use and when-not-to-use 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 readOnly=false, destructive=false, openWorld=false, idempotent=false; the description carries far more — credits are charged at prismposter.com parity, each job yields two takes in about a minute, the approval_required gate blocks all execution until the person answers, output is auto-saved to the library, and disallowed content is refused before any charge. The stated idempotency_key behavior is consistent with idempotentHint=false, since a fresh call still charges.

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

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

Front-loaded with the purpose and the vocal/instrumental branch, then moves through cost, approval gate and refusals in a logical order. Sentences are long and the downstream-capability list ("then remix, extend, split into stems...") is more promotional than operative, but nearly every clause carries decision-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?

Given 11 optional params, real credit charges and no output schema, the description covers cost, latency, the approval loop and content policy well, and hints at the return (two takes). It does not say how to retrieve results after the job starts — no mention of get_job or track/job identifiers — which is the main gap for a tool with 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% and the schema already explains style, lyrics vs prompt, instrumental, approval_id, idempotency_key and the reference_audio/clips/images exclusivity rules in detail. The description restates the broad shape ("set style, tempo, instruments, title and target length up to six minutes") but adds no syntax or edge-case meaning 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?

Opens with a specific verb+resource ("Make an original song") and immediately splits the two modes — vocal from supplied lyrics, or instrumental from a description — which is the exact distinction an agent needs. It also names the adjacent capabilities (remix, extend, stems, lyric/music video) so the agent knows where the boundary with edit_song, extend_video and make_music_video lies.

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 real routing context: quote_job prices first and is free, and approval_required is returned when the person must decide something before anything runs. It states what is refused up front (under-18, public figures). It stops short of explicitly contrasting create_song with edit_song or extend_video for iterating on an existing song, so it is strong but not complete.

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?

Strong on cost and lifecycle: credits are spent at prismposter.com parity, renders take one to a few minutes, results land in the user's library, and content involving minors or public figures is refused before charge. However, the description does not tie its behavior to the annotations and never states that the call is non-destructive or how retries are safe by default (the idempotency_key opt-in is documented only at the parameter level). With annotations already covering the safety profile, this adds cost and gate context but leaves the mutation/retry safety partly implicit.

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

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

The first sentence is front-loaded and strong, but the paragraph sprawls into long run-on clauses with heavy parenthetical stacking (aspect ratio list, engine tradeoff, approval and refusal policy all in one block). Almost every clause earns its place, yet the same facts could be conveyed in half the space with clearer separation between capability, cost, and guardrails.

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

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

For a 13-parameter generative tool with no output schema, the description covers what an agent needs to call it correctly: pricing, latency, polling, escalation to human approval, content refusals, and where output is stored. The remaining gap is the shape of the immediate return (job handle fields) and that failure of the description to reconcile with idempotentHint=false.

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 explains every one of the 13 parameters, and the description correctly does not restate them. It does add value beyond the schema: @tag semantics for saved characters, end_image_url as a controlled transition, and platform-to-aspect-ratio mapping (9:16 for Reels/TikTok/Shorts) that an agent would otherwise have to infer.

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 plus scope: 'Make an AI video clip with sound from a prompt', and enumerates the controllable dimensions (camera moves, look, aspect ratio, engine). It is clearly distinguishable from create_image, change_video, extend_video and upscale_video, which are named later as follow-on tools rather than 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?

Explicitly routes the agent: poll get_job after submitting, use quote_job to price first, continue with change_video/extend_video/upscale_video on an existing result, and start from a picture when a first frame is wanted. It also states the approval_required path and the refusal conditions, which are real when/when-not rules rather than generic 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?

Goes well beyond the annotations: it discloses credit spend at prismposter.com parity, the approval/consent gate for price thresholds, real people, and licensing, plus where outputs land. The refusal policy for minors, public figures, and office holders is stated as pre-charge, which an agent cannot infer from readOnlyHint=false / destructiveHint=false alone.

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?

Capabilities are front-loaded in the first sentence and each later sentence carries real information (cost, approval gate, storage, refusals). It is longer than typical but not padded; minor tightening is possible in the approval sentence.

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

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

For a 7-parameter generative mutation with billing, consent, and refund-policy implications, it covers the decisive unknowns: who pays, what blocks execution, what happens to the output. Only the shape of a successful response (job id vs URL) is left implicit, which is expected given 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 coverage is 100%, so every parameter including approval_id and idempotency_key is already documented, setting the baseline at 3. The description adds only light cross-parameter framing (edit vs upscale, approval resumes the approved job), not syntax or new semantics.

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

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

Names a specific verb and resource plus the full capability envelope (background replace, object add/remove, restyle, in-image text, 2x/4x upscale). It is clearly separable from create_image (creates from nothing) and upscale_video (video, not pictures) in the sibling list.

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

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

States the routing rule for cost (quote_job prices it first, free) and the branch where approval_required is returned before anything runs. It does not explicitly say when to prefer a sibling like create_image or open_in_editor, but the context needed to choose 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 only supply the safety profile (readOnly false, destructive false, idempotent false), while the description adds substantive context: credits billed at the site's price, the free quote_job pre-check, the approval_required gate that halts execution until the person answers, results landing in their library, and a content policy that refuses minors/public figures before any charge. It also confirms the original is preserved, consistent with destructiveHint=false.

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

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

The lead clause is front-loaded on what the tool does and the operation list follows immediately. It is a dense single paragraph carrying seven actions plus billing and approval semantics, which is justified by the tool's complexity, though breaking the billing/approval sentences out would improve scanability.

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, zero-required, multi-action tool with no output schema, the description covers operations, cost, approval flow, policy refusals, and result persistence well. The one real gap is that it never says what a successful call returns (a job to poll via get_job), leaving the agent to infer the completion loop.

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

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

Schema coverage is 91%, so the schema already documents each parameter thoroughly, including action and voice enum meanings. The description's action list largely restates the enum descriptions, and it adds no syntax or formatting detail beyond what is already in 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?

The description names a specific verb-plus-resource ('Work on a song the account made, or on the person's own audio from a link') and then enumerates every supported operation: remix, extend, stems, replace_section, add_vocals, add_backing. That map is precise enough to separate the tool from create_song, keep_song, and extend_video without opening a schema.

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

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

It clearly frames when to use it: an existing track or the person's own uploaded audio, with 7 concrete transformations listed. It also routes the agent to quote_job for pricing and back to the approval card when approval_required returns. It never states the inverse — e.g. to start a brand-new song use create_song — so the exclusions remain 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?

Goes well beyond the annotations: billing is on added seconds only, credits are spent at quoted prices, original clip is preserved, output lands in the user's library, and approval_required blocks execution until the person answers. Content refusals for minors and public figures are disclosed before any charge, which the idempotentHint/destructiveHint fields say nothing about.

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 and each sentence carries distinct information (behavior, pricing, approval, policy). It is dense but slightly overloaded near the end with refund/policy detail in a single long run-on.

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, zero-required, credit-spending mutation with no output schema, the description supplies what's missing: what is returned (longer clip), what happens to the original, how charging works, and the approval/resume path.

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

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

Schema description coverage is 100%, so engine, resolution, direction and add_seconds are already fully documented. The description only reinforces that pricing scales with added seconds; it adds no format or constraint detail the schema lacks, 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 plus mechanism: 'continue the same scene from its last frames for a few more seconds.' That distinguishes it from create_video (new clip), change_video and upscale_video without the agent needing 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?

Says when to use it (make an existing clip longer) and routes to quote_job for a free price first, plus the approval_required branch. It does not explicitly exclude sibling alternatives like change_video or remake_render, so sibling differentiation is only partial.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description only needs to add what they don't cover, and it does: the tool exposes a spend ceiling for this connection and the point at which the owner is asked for approval. It does not state freshness of the credit figure or whether the call itself costs anything.

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 what the tool returns, then the invocation triggers. No restatement of the title, 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 and no parameters, the description must convey the return shape, and it does at a useful level (credits, plan, remaining spend before approval). It stops short of specifying units, currency, or how a 'spend today' reset works, which an agent may want when reasoning about limits.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly spends its words on the returned data instead of inventing input semantics.

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

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

The description names the exact payload: credits available, the account's plan, and the per-connection daily spend allowance that triggers owner approval. That is specific enough to separate it from sibling read tools like get_job or get_capabilities, though the action verb ('get') lives only in the name/title rather than the prose.

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 two concrete trigger conditions: call before paid work (create_image, create_video, quote_job, etc.) and call when a job is refused for credits. That is strong positive guidance, but no explicit when-not or named alternative (buy_credits) is offered for the top-up path.

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 establish that this is a safe, read-only, idempotent, non-destructive, closed-world lookup. The description adds useful return-content context by naming the link and details such as prompt, size, and lyrics, but it does not mention permissions, error behavior, or other operational traits.

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

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

It is a single front-loaded sentence that immediately states the scope and returned information. Every phrase adds useful meaning without repetition or clutter.

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 lookup with rich annotations and no output schema, the description gives enough context about what is returned. A brief note about missing or invalid asset_id behavior would make it fully complete.

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

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

Schema coverage is 100%, so asset_id is already well documented as coming from list_library. The description only reinforces that lookup is by asset_id and does not add format or source detail beyond the schema.

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

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

The description clearly states it retrieves a single library item by asset_id and lists the returned details. It distinguishes itself implicitly from list_library by specifying 'One item', though it does not name the sibling alternative.

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

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

There is no explicit guidance on when to use this tool versus list_library or other lookup tools. The implication is that the caller must already have an asset_id, but the description does not say that or describe prerequisites.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so safety is covered. The description adds value beyond that by disclosing return contents (engines, costs, sizes, characters) and the "call once" caching implication. With no output schema, the return description could go further on response shape or staleness.

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

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

Two sentences, zero filler; the capability enumeration is front-loaded and the operational instruction comes last. The dense list format efficiently conveys the breadth of the return value.

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

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

With no output schema, the description carries the burden of telling the agent what comes back, and it does so at a category level (engines, costs, sizes, looks, song/lyric/character types). Anything more detailed would be guesswork, but a hint on structure (e.g., grouped by product type) would fully 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?

Zero parameters, so there is nothing to disambiguate and the description correctly spends no words on arguments. Baseline 4 applies for a no-arg tool.

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

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

Names a definite resource (this account's creative capability catalog) and enumerates its contents concretely: video engines with lengths/resolutions/shapes, image sizes and looks, edits, songs, lyric/music videos, characters, Remake. An agent can distinguish it from get_account (account facts) or list_characters (one collection) purely from this sentence.

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

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

Gives an explicit directive: "Call it once at the start to know the full creative range to offer" — establishing both timing and cardinality, which is unusual and useful guidance. It doesn't name an alternative for the case where an agent only needs one sub-collection (e.g., list_characters vs. this), so there is no explicit exclusion.

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 readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it explains the possible job states, including approval_required (waiting for a person) and failed (with any refund), and notes that complete jobs include media links and continuing ids. It does not cover rate limits or auth, but the annotations already carry the safety profile.

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 dense sentence front-loads the core purpose and efficiently packs the state list and polling instruction. No sentence is wasted, and the most important operational cue (polling cadence) is included without burying the lede.

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

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

There is no output schema, so the description carries the full burden of explaining return values and does so: statuses, media links, ids for follow-up work, and refund on failure. For a single-parameter getter with clear annotations, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100%, and the schema itself documents that job_id is 'returned by a create tool.' The description reinforces that this works with 'any job a tool started' but adds no format, syntax, or constraint details beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Status and results of any job a tool started') and enumerates the exact return states (processing, approval_required, ready, complete, failed). This lets an agent distinguish it from creation siblings like create_video or remake_start without opening the schema.

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

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

Explicitly tells the agent to poll every 15-30 seconds until the job settles, which is the critical usage pattern for an asynchronous job-status tool. It lacks an explicit when-not or named alternative, but no sibling serves the same polling purpose, so the guidance is effectively complete.

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 meaningfully beyond the annotations: a 200 MB size cap, the direct-file-link requirement, and that it is free. Annotations already cover mutability and non-idempotence, so the remaining gap is what happens after upload (asset id vs. job) and whether the import is asynchronous.

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, front-loaded with the action and the constraint, followed by the purpose and cost. Nothing is wasted and nothing important is buried.

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

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

For a one-parameter import with no output schema, the description covers input constraints, cost, and intended downstream use. It could be complete by stating what the call yields (an asset reference or a job to poll), which an agent will need to chain into other tools.

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

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

Schema coverage is 100%, so baseline is 3, and the description earns above that by adding the 200 MB size limit and reinforcing that it must be a direct https link to the person's own media rather than a page URL. Type scope (video/audio/picture) is also restated usefully.

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 ('bring in') plus resource ('video, audio or picture') with the key qualifier that it must be the person's own media from a direct https link. This distinguishes it from the generation siblings like create_video, create_image, and create_song without having to compare schemas.

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

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

Gives the downstream reason to call it ('so other tools can use it: a clip to remake, a song to remix or extend, a photo to animate') which effectively points at remake_*, edit_*, and extend_* as follow-ups. It stops short of an explicit 'use this instead of create_* when the media already exists' exclusion.

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 behavior the annotations do not carry: it is free (no credits), it writes the take into the user's library, and the losing take is discarded. The discard side effect is the one borderline point against destructiveHint=false, but the tool's target resource is being preserved, not destroyed, so this reads as transparent rather than contradictory. It does not say whether the discard is reversible or what is returned.

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

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

Three short sentences with no waste, ordered from what the tool does to when to use it to the downstream dependency. The prerequisite is placed last where it is most likely to be acted on.

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

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

For a single-parameter mutation with no output schema, it covers cost, side effects, and downstream dependency, which is most of what an agent needs. The remaining gap is what the call returns and whether a kept take can be swapped later.

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

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

Schema coverage is 100% and the parameter description already says track_id comes from get_job. The description only adds that the id is the take the person chose, which is context rather than format or constraint detail, so baseline 3 applies.

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

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

States a specific verb and outcome: choose one of two takes, save it to the library as the song, discard the other. The two-take framing makes it unmistakable against siblings like create_song or edit_song.

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 trigger ('after the person has heard both') and an explicit prerequisite naming a sibling: 'A take must be kept before make_music_video can use it.' An agent knows both when to call it and why a downstream tool would fail without it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds useful return context: saved characters, @tags, and preview pictures. It does not mention ordering, limits, or pagination, but for a no-parameter list tool that 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?

Two compact sentences, front-loaded with the resource and return content, followed by concrete usage guidance. 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?

Given a zero-parameter, read-only list tool with no output schema, the description supplies the essential return shape and the two main ways to use the results. An agent has enough to call it and act on the output.

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

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

There are zero parameters, so the baseline is 4. The description correctly does not spend words on nonexistent inputs and instead focuses on what the returned characters can be used for.

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

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

States a specific resource and scope: 'the account's saved characters,' and adds what each entry includes (@tags and preview pictures). This distinguishes it from create_character and other siblings without requiring 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?

Gives clear downstream usage: put @tag in create_image or create_video prompts, or cast by character_id in remake_render. It does not explicitly compare with list_library or say when not to use this tool, so it stops short of full alternative routing.

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

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

The annotations already declare the read-only, idempotent, non-destructive, closed-world profile, so the description's job is lighter. It still adds real context the annotations lack: result ordering ('newest first') and the fact that results are paged via next_cursor.

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

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

Two sentences, no filler, with the resource and ordering front-loaded. The trailing fragment 'Pages with next_cursor.' is terse but slightly clipped rather than a complete sentence.

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

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

With no output schema, the description responsibly states what comes back — items with links and ids — and covers paging. Nothing critical for calling it correctly is missing, though a note on empty libraries or the cursor's default absence would round it out.

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 all three parameters are documented inline, so the schema carries the parameter burden. The description only echoes the content types and the cursor paging already in the schema, adding no format or semantics beyond it.

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

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

The description names the resource ('the account's saved work'), its contents (images, videos, songs), and the ordering (newest first), so the agent knows exactly what is listed. It does not distinguish itself from the nearby list_characters or from get_asset, 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?

Usage is only implied: 'links and ids to keep working with' suggests the intended flow of listing then acting on an id, but no alternative or exclusion is named. An agent must infer that it should call this rather than list_characters when it wants mixed saved media.

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

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

Adds real context beyond the annotations: the job is free and the result lands in the person's library, and it flags the approval-gated path. Annotations already cover safety and idempotency hints, so the remaining gap is minor (no mention of async/job completion behavior).

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

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

Four compact sentences, front-loaded with what the tool produces, then the choice, then cost/output, then the prerequisite. Slightly dense with semicolon-joined clauses but no wasted sentences.

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 things an agent would otherwise guess wrong: cost, where output goes, and the source-audio prerequisite. With no output schema, it could still say more about the return value (a job handle to poll via get_job), which is the main omission.

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 still adds meaning by framing the cut choice as short-form vs whole song and by explaining that track_id must come from a song made here unless the audio is first edited via edit_song. It doesn't elaborate on idempotency_key or approval_id 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 and resource ('turn a song with lyrics into a lyric video') and immediately characterizes the output (words timed to vocals over animated visuals). This clearly separates it from siblings like make_music_video or create_video without opening their schemas.

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

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

Explicitly routes the agent: use hook vs full, and use edit_song first when the audio is the person's own rather than a song made here. It doesn't name the nearest sibling (make_music_video) as an alternative for comparison, which keeps it below a 5.

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

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

Beyond the annotations, it discloses credit spending, price parity with prismposter.com, several-minute runtime, approval-required behavior with nothing running until answered, library saving, and refusal rules for minors/public figures before charge. This is unusually rich behavioral context for a non-read-only generation tool.

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

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

The purpose is front-loaded in the first sentence, and the remaining sentences pack in prerequisites, pricing, approval, saving, and refusal rules without filler. Every sentence adds operational value.

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

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

For a complex, credit-spending generation tool with no output schema, it covers prerequisites, pricing, approval, refusals, runtime, and saving. Its main gap is that it does not describe the successful return value or explicitly tell the agent to poll get_job for 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 coverage is 100%, so the schema already documents all four parameters, but the description adds meaningful track_id context by requiring a kept song or an edit_song-derived source. It also reinforces the approval_id flow, though it says nothing extra about idempotency_key beyond the schema.

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

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

It states a specific verb and resource: make a full-length music video for a whole song, with generated scenes cut to the music from start to end. The scope contrast with lyric videos and generic video tools is implicit but clear enough from 'full-length music video' and 'generated scenes cut to the music'.

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 explicitly says to use a kept song made here, and to remix or extend the person's own audio with edit_song first. It also names quote_job for pricing and explains the approval_required path when the person must decide something first.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false; the description adds that a *new* project is created (consistent with non-idempotent) and that it returns a link, plus the cost signal "Free." That cost detail is genuinely useful next to buy_credits/quote_job siblings and is not captured in annotations, though no permission or rate-limit context is given.

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 the core action and return value front-loaded in the first clause. The trailing editor-capabilities sentence (trims, captions, music, upscales, exports) is mildly ornamental but does orient the agent to the tool's downstream purpose.

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

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

For a two-param, low-destructive creation tool with no output schema, the description covers the action, resulting artifact (a new project plus link), accepted ID sources, and cost. Missing elements are minor: no statement about what happens on repeat calls or whether project limits/quota apply.

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 clip_id description in the schema already spells out all three accepted ID sources in more detail than the prose. The description adds no extra meaning for the optional 'name' param, 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: "Put a clip in a new PrismPoster editor project and get its link." It also clarifies the two clip provenances (account-made clip vs. the person's own clip imported via import_media), which separates it from pure-creation siblings like create_video, though it never names a conflicting sibling to avoid.

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

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

Usage is implied rather than stated: the description explains where clip_id can come from (get_job, list_library, import_media), which is really input routing, and sketches what the editor is used for afterwards. There is no explicit when-to-use/when-not-to-use or alternative-tool guidance against the 27 sibling 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?

Goes well beyond the annotations, which only declare it is not read-only, idempotent, or destructive. The description adds cost (free), a quota ("A few previews per Remake and per day"), and a consent requirement for real people, all of which change how an agent should call it. It stops short of describing the returned preview artifact.

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

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

Front-loaded with the key fact ("Free:") and kept to three sentences with no filler. The final sentence is dense but each clause carries operative constraints (consent, rate limit, argument reuse).

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 cost, quota, consent/legal prerequisites, and argument compatibility for a low-risk generation call, which is enough for correct invocation. With no output schema, the description leaves the returned frame's format unspecified, which is the only real gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine cross-tool semantics: cast/performers take the same shape as in remake_render, so an agent can reuse a payload rather than re-deriving it. The approval_id consent flow is left to the schema.

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

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

States a specific verb and artifact ("draws the Remake's opening frame with the chosen cast") and names the sibling it precedes (remake_render), so an agent can distinguish it from the paid render step without reading either schema.

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

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

"before paying for remake_render" gives a clear selection context versus the render sibling, and "Takes the same cast or performers as remake_render" tells the agent it can reuse arguments. It does not state explicit when-not conditions, but the sequencing plus quota note makes usage unambiguous.

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

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

Annotations already cover readOnly, idempotent, non-destructive, but the description adds substantive context the annotations cannot: the quote reports balance sufficiency, today's limit, and the owner's ask-first amount. "Charges nothing" reinforces the safety profile in economic terms.

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

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

Three short sentences, front-loaded with the core definition, then the parameter instruction, then the no-charge note. 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 names what the quote returns (price, balance fit, limit, ask-first) so the missing output schema is tolerable, and it explains how to frame the nested arguments payload. It stops short of describing error conditions, such as an unknown tool name or invalid arguments.

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

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

Schema coverage is 100% and the schema already documents both `tool` and `arguments` with examples. The description's "Pass the tool's name and the arguments you would call it with" restates the schema rather than adding syntax, validity rules, or failure behavior.

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 resource (the exact credit price of a job) and a specific operation (quoting it before execution), with a clear scope that separates it from buy_credits and get_job. An agent can immediately tell this is a dry-run cost estimator rather than an executor.

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?

"before making it" gives an explicit call-ordering rule, which is the key usage signal for a pre-flight estimator. No explicit exclusion or named alternative is given, but the guidance is unambiguous in practice.

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 (readOnly=false, destructive=false) only sketch the safety profile; the description adds substantial context beyond them: it spends PrismPoster credits at a stated price, renders in minutes, saves to the library, blocks under-18/public-figure requests before charging, requires consent for real people in photos, and returns approval_required with nothing running until answered. That is exactly the behavioral detail annotations cannot convey.

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

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

Well front-loaded: the core render capability leads, with consequences (credits, approval, refusals) trailing. It is a dense run-on paragraph, so some policy sentences about consent/refusal could be tightened, but nearly every clause carries actionable information.

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

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

For a mutation tool with no output schema, the description covers cost, timing, consent, approval flow, and refusal policy well. It does not describe the successful return payload (presumably a job object), though it does note the approval_required answer, leaving a small gap for an agent parsing responses.

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 prose adds real meaning: it explains the cast-vs-performers split (one entry per person vs a Trend's performers filled left to right), that groups of up to 30 are allowed, that speech regenerates the original words, and that scenes keep moves and timing. It goes beyond restating the schema 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?

Names a specific verb and resource ('Render a prepared Remake') and defines scope sharply: replace one person or everyone, keep the rest as filmed, change setting/shape/sound. It is clearly distinguishable from remake_start, preview_remake_cast, and quote_job, which are named as prior or adjacent steps.

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 when-to-use context: poll get_job after, quote_job prices first for free, remake_id comes from remake_start, and approval_required if the person must decide. It stops short of explicit when-NOT-to-use or a direct comparison to preview_remake_cast, so it is clear but not fully exclusionary.

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 flags; the description adds the important behaviors: starting is free, preparation takes about a minute, brought clips require the person's confirmation via PrismPoster's card, and an approval_required answer locks the job to what was approved. It doesn't disclose what happens on conflicting inputs (e.g. trend_id plus clip_asset_id) or how failures surface, which keeps it below a 5.

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

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

The concept is front-loaded in the first sentence, followed by the input paths, the approval caveat, then the polling step. Sentences are dense but each carries workflow information; the only real redundancy is repeating the 3-30 second constraint already in from_seconds/to_seconds.

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 return burden and does it well: polling get_job yields the cast list with pictures and 1080p/4k pricing. The approval branch and the free-to-start fact round out the lifecycle. It could be more complete by placing preview_remake_cast and remake_render in the pipeline, but an agent has enough to call this 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 every parameter including the 3-30 second range and idempotency_key semantics is already documented in the schema. The description's parameter-level contribution is mostly restatement ('choose 3-30 seconds of it', 'approval_id... other arguments are ignored'), 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 description opens with a concrete definition of what a Remake is (a clip recreated with new performers copying moves, gestures, camera and timing) and then states the specific action: start one. Three distinct entry points are named (Trend, import_media asset, account clip), which distinguishes this from remake_render and remake_trends without opening any schema.

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

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

It gives explicit routing rules for the inputs: remake_trends for a Trend, import_media asset_id for the person's own clip, clip_id for a video the account made, plus the 3-30 second window. It also tells the agent the next step is polling get_job. It stops short of naming preview_remake_cast or remake_render as the downstream alternatives, so the workflow isn't fully mapped.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavior: each entry carries a preview, and no source footage from the person is required, which shapes whether the agent needs import_media first.

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 clauses with no filler: the catalog contents are front-loaded and the next action plus the 'no own clip' clarification follow immediately. Every phrase earns its place.

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

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

For a read-only catalog tool with no output schema, the description conveys what comes back (trends with previews) and what to do next. The only gap is pagination behavior, which the schema's cursor and limit fields cover but the description never mentions, so an agent may not realize results are paged.

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

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

Schema coverage is 67%, with topic already enum-documented in the schema. The description's category list mirrors the topic enum values, adding a little semantic grounding, but it says nothing about limit or cursor-based paging, leaving those 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?

Names a concrete resource (ready-made remake Trends) and enumerates the categories (dances, talking clips, reveals, transitions, product shots, sport, couple), which lets an agent tell it apart from remake_start and preview_remake_cast. The browsing verb is implicit rather than stated ('Ready-made Trends to remake'), leaning on the title to supply 'Browse', which keeps it just short of a 5.

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

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

Explicitly states the follow-on action ('Pick one and remake_start it'), routing the agent to the correct sibling after browsing. It also removes a likely blocker with 'no clip of the person's own needed.' It stops short of a 5 because it never says when browsing is unnecessary (e.g., if you already know the trend ID or the user supplied footage).

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

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

Goes well beyond annotations: credits are only taken on delivery, the result is saved as a new clip in the library, pricing matches prismposter.com, approval_required blocks execution until the person answers, and policy refusals occur before charge. This is rich behavioral disclosure for a paid, mutation-like operation.

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

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

The core action is front-loaded in the first sentence, and subsequent sentences cover cost, approvals, output location, and refusals. There is minor redundancy between 'saved as a new clip in the library' and 'Everything made is saved to their PrismPoster library', but overall it is well structured and purposeful.

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 major decision points an agent needs for a paid, approval-gated upscale: target sizes, cost timing, approval_required handling, output persistence, and sensitive-content refusals. It does not mention how to retrieve the final job result, presumably via get_job, which is a minor gap for a generation workflow.

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 fully documents target, clip_id, approval_id, and idempotency_key. The description only adds the target sizes and a pointer to quote_job, so it does not materially improve parameter meaning beyond the schema baseline.

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

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

States a specific verb and resource: sharpen a clip to 1080p or 4k, preserving motion and length, saved as a new clip. This clearly distinguishes upscaling from generation siblings like create_video and names quote_job for pricing, so an agent can identify the tool's role immediately.

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

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

Gives explicit conditions: quote_job prices it first and is free, approval_required is returned when human decisions are needed, and under-18/public-figure requests are refused before charge. It doesn't explicitly say 'use this instead of X' for the full sibling set, but the pricing/approval routing is strong contextual guidance.

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