Nano Studio Pro

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

Annotations only say readOnly=false / destructive=false; the description adds substantive behavior: the write counts against storage, metadata is capped at 4 KB and is echoed on every read, and the response's versions field surfaces other sizes of the same picture with an instruction to tell the user. That is context an agent cannot get from the structured fields.

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

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

Dense but front-loaded: the source constraint leads, then each enum mode, then the response note and the storage cost. Every clause carries information, and the 'tell the user' imperative is unambiguous.

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, no-output-schema mutation tool this covers sources, modes, cross-references (reference_asset_ids), metadata limits, storage cost and the shape of the answer's versions field. Only the unexplained 'name' parameter keeps it from being 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 0%, so the description must carry the load, and it does for most parameters: url vs base64 data: URL for 'data', the three 'as' enum modes and their side effects, the 4 KB metadata cap, and project_id's requirement. The 'name' parameter is never mentioned, leaving one of six undocumented in both places.

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

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

States a specific verb and resource ('Adds an image') plus the key scope constraint 'no AI' and the closed set of input sources (url or data). That immediately separates it from generate_image, expand_image and upscale_image 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?

Explains the mutually exclusive source rule ('ONE source: url ... or data ...') and the conditional dependency (as:"timeline" needs project_id), which is real when-to-use guidance. It does not explicitly name the AI siblings as the alternative, so it falls short of a full routing statement.

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

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

Annotations only say it is a non-read-only, non-destructive operation, but the description discloses far more: async execution returning a task_id, dedup behavior (same file completes with the existing clip), storage accounting, backend 1080p editing-copy creation, and the irreversible consequence of keep_original:false ('the clip is 1080p from then on'). This is exactly the behavioral context annotations cannot carry.

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 import action and its input constraint, and almost every clause carries new information (dedup, task polling, editing copy, keep_original). It is dense and semicolon-chained rather than bulleted, making it harder to scan than it needs to be, but there is little pure filler.

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

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

With no output schema and 0% schema coverage on seven parameters plus an async workflow, the description does substantial work: it covers the return contract (task_id → get_task → generation_id), dedup, cost, storage, and the original-retention tradeoff. The unexplained name/prompt/project_id parameters are the 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 0%, so the description must carry the load; it explains density (quick|normal|detailed, 180 s cap, credit cost), metadata (own fields, 4 KB max, returned on reads), keep_original, and the url constraint. However name, prompt, and project_id are never mentioned, leaving three of seven parameters undocumented anywhere.

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

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

Opens with a specific verb+resource: 'Imports a video FILE from a link', and even scopes the accepted input ('a direct .mp4/.mov/.webm url, not a page that plays it'). It is clear this is an import rather than a generation, but no sibling such as generate_video or add_image is named, so the contrast is left implicit.

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 applicability context (direct media URL, any size storage allows) and an explicit negative case ('not a page that plays it'), plus the operational path of polling get_task until complete. It never states when to prefer generate_video or add_image instead, so alternative-routing guidance is absent.

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

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

Annotations already mark destructiveHint=true, but the description adds specific behavioral details: the need for user confirmation and the non-refundable credit policy. This goes beyond the annotation and helps the agent understand consequences.

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

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

A single, efficient sentence that conveys the core action and critical caveats. No wasted words; the warning is front-loaded and impactful.

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 cancellation tool with one parameter and no output schema, the description covers the action, side effects, and user confirmation. It lacks details on return values, but that's acceptable given the simplicity and the annotations.

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

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

The single parameter task_id is self-explanatory, but the description does not explicitly explain its meaning or format. With 0% schema coverage, the description could have added a line like 'task_id is the ID of the running task to cancel,' but the name is clear enough.

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 tool cancels a running task, with a specific verb and resource. It distinguishes from siblings like retry_task or get_task by specifying 'running task', implying it only applies to tasks in progress.

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 usage context: confirm with the user first and warns about non-refundable credits. It doesn't explicitly state when not to use it or mention alternatives, but the guidance is actionable for the agent.

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 provide readOnlyHint=false and destructiveHint=false, but do not disclose the cost implications. The description explicitly warns 'COSTS CREDITS', which is valuable beyond annotations. However, no other behavioral details (e.g., credits amount, processing time) are given, so a middle score is appropriate.

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

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

The description is exceptionally concise, with two sentences that pack essential information: the output, the cost warning, and the source constraint. Every word serves a purpose, and critical constraints are front-loaded.

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

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

Given the 4 parameters with 0% schema coverage and no output schema, the description is somewhat incomplete. It explains the source constraint but not project_id's role or what the output 'clean plate' means practically. The cost warning is helpful but more context on expected behavior is needed for a full picture.

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

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

Schema description coverage is 0%, meaning the schema provides no descriptions. The description mentions that exactly one of generation_id, asset_id, or url must be used, which adds meaning, but it does not clarify the purpose of project_id or the relationship between the three source parameters. This partially compensates for the schema gap but leaves gaps.

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

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

The description clearly states the tool's purpose ('subject cutout') and its output (transparent PNG + clean plate), but it does not explicitly distinguish itself from sibling tools like get_cutout or expand_image, which could be confused for similar operations.

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 provides a key usage guideline: exactly one of generation_id, asset_id, or url must be provided, which is crucial. However, it does not explain when to use cutout versus alternatives like expand_image or restyle, leaving some ambiguity.

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 destructiveHint/readOnlyHint annotations by disclosing that deletion is permanent, that a confirmation step is mandated, that referential integrity causes an error naming the blocking quote or share page, and that force:true is the escalation path. This is the exact behavioral context an agent needs before a destructive call.

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

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

Three tight sentences with the destructive warning front-loaded, followed by the failure mode and the recovery path. Every clause carries actionable information with no filler.

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

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

For a two-parameter destructive tool with no output schema, the description covers the safety precondition, the error condition, and the retry semantics. Nothing an agent needs to invoke 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 description coverage is 0%, so the description must carry parameter meaning; it fully explains the non-obvious `force` parameter by tying it to the failed-deletion scenario and the user-approval precondition. `asset_id` is left unaddressed, but its meaning is self-evident from the name.

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

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

States a specific verb and resource ('Permanently deletes an asset') and the permanence qualifier immediately frames the operation's stakes. The delete verb cleanly separates it from siblings like get_asset and list_assets without needing to name them.

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

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

Gives explicit operational guidance: confirm with the user first, and if the call fails because the asset is referenced, show the listed places and only retry with force:true on user approval. This is a clear conditional workflow, though it does not name an alternative tool for the referenced-asset case (e.g., removing the reference 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?

Beyond the readOnlyHint=false/destructiveHint=false annotations, the description discloses non-obvious behavior: it COSTS CREDITS scaled 'by output resolution,' and it creates a NEW generation rather than editing in place, placed in the source's own project. Credit cost and new-artifact semantics are exactly the traits an agent needs and would not get from structured fields.

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

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

Information is front-loaded with the core operation before cost, output semantics, and options. It is dense with parentheticals but nearly every clause carries actionable content; minor run-on structure keeps it from a 5.

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

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

For a 7-param mutation tool with no output schema, the description covers cost, new-generation placement, and the key parameter interactions. It stops short of clarifying task/async behavior (siblings include get_task/cancel_task) or the returned handle, leaving a small 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?

With 57% schema coverage, the description compensates usefully: it specifies extend defaults to all four, that zoom < 1 means zoom out, the asset_id/generation_id mutual exclusivity ('not both'), and that project_id applies only to asset_id while resolution defaults to the source's. This adds meaning beyond the schema for the undocumented params.

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 mechanism — 'outpaints an existing generation to a bigger canvas / new aspect ratio — the model extends the scene beyond the original edges' — which clearly separates it from generate_image (new content) and upscale_image (resolution, not canvas). An agent can identify the operation 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 explains practical usage contexts: restrict directions with extend, zoom out with zoom < 1, and using an uploaded asset as the base. However, it never names a sibling alternative (upscale_image, generate_image, cutout) or states when NOT to use this tool, so the routing guidance is implicit 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 only declare readOnlyHint=false and destructiveHint=false; the description adds the genuinely non-obvious traits: the call consumes credits, which pricing tool to query, that the image comes back inline plus a JSON payload with generation_id/status/image_url/credits_remaining, the 14-reference cap, and the 2K ceiling on GPT models. These are exactly the behavioral facts 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?

Front-loaded with the action and the cost warning, then structured as return shape → references → model picking. It is dense and nearly every clause earns its place, though the parenthetical pricing-prefix list and the model-selection paragraph overlap somewhat and could be trimmed.

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 generation tool with no output schema, the description supplies the return payload fields, cost behavior, reference limits, resolution constraints and model trade-offs — everything an agent needs to invoke it correctly. Only aspect_ratio behavior remains unaddressed, which is a minor gap.

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

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

At 71% schema coverage, the description adds real meaning the schema lacks: entity_ids is undocumented in the schema and is explained here (@slug or entity_ids attach a saved entity's sheet), reference_asset_ids accepts 'asset or generation ids', and model carries per-model use-case guidance. It does not explain aspect_ratio or the prompt semantics beyond the char limit, so it is strong but not exhaustive.

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 ('Generates an AI image') and immediately distinguishes itself from nearby siblings by naming the model families and their jobs, making it clearly different from generate_video, generate_sheet, expand_image or restyle. An agent knows exactly what this produces 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?

Explicit routing is provided: call get_pricing with the matching generate_* prefix for cost, use list_entities/@slug/entity_ids to attach saved entity sheets, and a detailed when-to-pick-which-model rule set (Nano Banana 2.1 for light/texture/mood, Pro for exact structure, Flare/Sunburst for legible text). This is the strongest form of usage guidance: alternatives plus selection conditions.

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

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

Annotations only say readOnlyHint=false / destructiveHint=false; the description adds the information that actually matters: the call COSTS CREDITS at the planned tier, that dry_run:true and prompt_only:true are free, and that the tool internally constructs the count assertion, keyable ground, absence of lines/labels, and a clean-cutting grid. That is real disclosure of cost, side effects, and internal guarantees that the annotations do not cover.

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

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

Front-loaded with the core action and the credit warning before any detail, and the dense bullet block is justified by 18 parameters. It is on the edge of over-packed — the style-id lists ('photograph, film-still, studio-portrait...') cost words that could be deferred to sheet_options — but nothing is truly 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?

For an 18-param generation tool with no output schema, the description covers the workflow (quote → generate → get_sheet_atlas), the cost model, the mode variants, and the per-job parameter combinations an agent needs to call it correctly. Only low-stakes fields like project_id are left to the schema, which is acceptable.

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

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

Schema coverage is already 89%, but the description adds genuine cross-parameter meaning: which kind pairs with which other params, that art_style must be a sheet_options id and does not apply to sprites, that sequences stack in order, and that @slug in subject or entity_ids attaches a saved entity. Minor gaps remain (project_id, style_ids, reference_ids get no prose), so not a full 5.

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 a precisely scoped artifact: ONE image holding several separately cut-out elements, and enumerates the concrete use cases (animation cycle, sprite sheet, icon set, stickers, props). It also explicitly distinguishes itself from generate_image ('never call generate_image for a sheet'), so an agent can route without opening a schema.

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

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

The 'Pick by job' section gives explicit routing rules tying each job type to a kind plus its companion params (frames + sequences + art_style, sprites + sequences, icons/stickers/props + items). It also names alternatives and prerequisites: quote with dry_run:true first, art_style ids come from sheet_options, saved entities come from list_entities, and get_sheet_atlas is the follow-up for frame rects.

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 give readOnlyHint=false and destructiveHint=false; the description goes far beyond them by disclosing the cost model ('MOST EXPENSIVE: per second, on completion, purchased credits only'), the async pattern and polling target ('poll get_task'), and a free quoting path ('dry_run:true (free), confirm with the user'). This is exactly the operational context an agent needs before spending 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?

The cost warning is front-loaded, followed by a tightly structured per-model routing list, and almost no sentence is wasted. The telegraphic style ('180/240 per second of the clip (3-30s), silent') is dense to the point of being cryptic in places, which costs a little readability but not correctness.

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 22-parameter, multi-model, no-output-schema tool, the description covers pricing, model selection, async polling, quoting, and entity attachment, which is close to complete. The main gap is the return value: it implies a task id via 'poll get_task' but never states what the call returns or how to identify the resulting 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?

With 73% schema coverage the baseline is 3, but the description adds genuine meaning beyond the schema: model-specific constraints such as '3 reference_image_ids (6 with no clip)', duration and resolution behavior per model, the draft/finalize_draft_id workflow, and how entities attach ('@slug or entity_ids'). It leaves a few parameters (name, aspect_ratio, extend_direction) to the schema, which is acceptable.

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 'Makes a video' is thin and nearly restates the title, but the body makes the resource and scope unmistakable: it generates video clips from stills, references, or text across seven named models. It is clearly distinguishable from generate_image and add_video by resource, though the differentiation is implied 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?

Strong routing guidance: each job type ('Still to life', 'Cheapest with sound', 'Copy a dance', 'Edit a clip in words') is mapped to a specific model with credit costs, so an agent can pick a model without guessing. It also prescribes a workflow (quote with dry_run, confirm with the user). What is missing is any when-not-to-use guidance versus sibling tools such as add_video or expand_image.

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

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

Annotations declare readOnlyHint=true, so the read-only nature is already known. The description adds 'Fetches metadata' which is consistent but does not disclose additional behavioral traits such as error handling, pagination, or what happens when the asset_id is invalid. With annotations covering the safety profile, the description meets a baseline but offers no extra insight.

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 a single, concise sentence with no wasted words. It front-loads the action and resource, making it immediately readable. It is an example of efficient specification.

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 only one parameter, the description is still incomplete. It fails to indicate what 'metadata' includes or the structure of the response, which is critical for an agent deciding whether to call this tool. Given the many sibling get_* tools, more detail about the returned fields would be necessary for confident selection.

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

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

The schema provides only the parameter name and type (string) with 0% description coverage. The description merely says 'by id', which adds minimal meaning beyond the schema. It does not specify the expected format (e.g., UUID, integer) or any constraints, leaving the agent to guess. The description should compensate for the missing schema descriptions but does not.

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

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

The description uses a specific verb ('Fetches') and a clear resource ('metadata for a single asset') qualified by 'by id', which distinguishes it from siblings like list_assets (plural) and get_project/get_task (different resources). An agent can immediately understand its purpose and differentiate it from similar 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that list_assets should be used for multiple assets, nor does it clarify when get_meta or get_project might be more appropriate. The agent is left to infer usage from the name alone.

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

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

Annotations provide readOnlyHint=true, and the description aligns with that (no contradiction). The description adds 'generation_id' as the required identifier and notes it's 'Free', which is useful context beyond the schema. However, it does not explain what a 'cutout' is, whether URLs expire, or any rate limits. For a read-only tool, this is adequate but not rich.

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

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

The description is concise and front-loaded with the key information: 'Fresh signed URLs for an existing cutout by generation_id. Free.' Two short sentences, no filler. It efficiently communicates the tool's function and cost.

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

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

Given the simple schema (one required parameter) and readOnlyHint annotation, the description is fairly complete. It tells the agent what it returns (fresh signed URLs) and how to identify the cutout (generation_id). It lacks details like URL expiration or how to obtain a generation_id, but for a straightforward read operation, this is sufficient. The presence of annotations and simple schema lowers the bar.

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 one parameter, generation_id, with no description. Schema description coverage is 0%, so the description must compensate. The description does mention that the cutout is identified by generation_id, adding some context about the parameter's purpose. However, it does not explain the format (e.g., UUID, string) or any constraints. Baseline is 3 due to zero coverage, and the description just meets 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?

The description 'Fresh signed URLs for an existing cutout by generation_id' clearly indicates the tool returns signed URLs for a specific cutout, using a verb (get) and a resource (cutout files). However, the term 'cutout' may not be familiar; it is likely a generated image asset. It distinguishes from siblings like get_asset or get_video by the specific 'cutout' and 'generation_id' concept.

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

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

The description implies usage when you need fresh signed URLs for a cutout, but it does not explicitly state when to use this tool instead of alternatives like get_asset or get_detections. It does not mention prerequisites (e.g., generation_id from a prior generation) or conditions where it should not be used.

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 readOnlyHint=true: the call is free, item ids are stable per scan_id, labels disambiguate repeats ("person (left)"), and an unscanned target returns 404. These are behavioral facts an agent cannot get from the annotations or schema. Return format is described at a high level only, but that is sufficient for a read 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?

Dense and front-loaded: the payload is described first, then usage, then id behavior, then the error case. Every clause carries information, though the parenthetical details make it slightly longer 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 must carry the return-value burden, and it does: it enumerates the fields returned, the 0-1000 normalization, the scene narrative, and the id/label structure. Prerequisites and the 404 case are also covered, so an agent has everything needed to call and interpret it.

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

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

Schema coverage is 100%, so both target_id and target_type are already documented by the schema and the enum is self-describing. The description's mentions of scan_id refer mainly to output item ids rather than input parameter semantics, so it adds little beyond the 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+resource (get the detection engine's view of an image) and enumerates the exact payload: item names, categories, textures, colors, normalized bounding boxes, and a scene narrative. It is clearly distinguishable from siblings like scan_image (which produces the data) and cutout/get_cutout (which transform it).

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

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

Gives explicit use cases ("see" an image's contents, or pick item names for restyle) and names the downstream alternative that consumes the output (restyle remove takes items [{id}]). It also states the prerequisite/fallback: 404 means never scanned, so run scan_image 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 provide readOnlyHint=true, so the description needn't restate that. It goes beyond by specifying the pricing model details (per-second video rows, fixed Veo naming) and that it's free, which adds behavioral context that the annotations don't cover. It doesn't disclose return format, but for a zero-param read-only price lookup, the safety and cost implications are well handled.

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

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

Dense, information-packed description with no filler. It front-loads the core purpose, then lists covered items, then adds the free and alternative-usage notes. Every sentence earns its place, and the structure is easy to scan.

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-param read-only price lookups tool, the description covers all an agent needs: what operations are priced, the naming conventions for video rows, the cost (free), and the alternative for clip-level pricing. No output schema or params to compensate for, so completeness is high.

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, and schema coverage is 100% (nothing to cover). The description's detailed enumeration of the pricing dimensions (model tiers, video row patterns) substitutes for parameter documentation by telling the agent what to look for in the output. This is high value given there's no schema to lean on.

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

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

States a specific verb ('get') and resource ('pricing'), and enumerates exactly what it covers: image tiers per model, restyle, cutouts, scans, and video rows. It clearly distinguishes itself from sibling tools like get_credits (a different concept) by specifying it's the live credit cost of every operation.

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 it's free, and provides a conditional alternative: for a whole clip's price, use generate_video with dry_run. This gives clear when-to-use and when-not-to-use guidance, and names the alternative tool, which is exactly what an agent needs to route correctly.

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 supply readOnlyHint=true; the description adds real context beyond that: it is free, requires ownership of the sheet, and returns an import-ready Aseprite JSON format compatible with Phaser/Pixi/Godot/Unity. It omits anything about size/limits, but for a free read that is minor.

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

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

Two tight sentences that are front-loaded: 'FREE.' plus the payload first, then the usage nudge. Every phrase carries information (cost, ownership, payload contents, format targets, alternative) 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?

With no output schema, the description does the heavy lifting by describing the returned Aseprite JSON in detail, which is strong. However, the unexplained grow/clean parameters and the trimmed-PNG 'pieces' mode leave gaps an agent cannot resolve from structured fields alone.

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

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

Schema coverage is only 25% and the description only clarifies generation_id ('its generation id'), leaving grow and clean entirely undefined in both schema and description. With three of four parameters under-explained, the description does not compensate for the coverage gap.

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

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

States a specific resource (a sheet's frame rects and animation tags) and enumerates the exact payload: per-frame pixel rect, registration, fps, pivot, and one tag per sequence as Aseprite JSON. An agent understands precisely what it returns, though no sibling tool (e.g. sheet_options) is named for 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?

'For a sheet you own (its generation id)' gives the precondition, and 'Ask this instead of measuring gutters in the pixels' tells the agent when to prefer this over manual parsing. No explicit when-not or named alternative tool, so short of a 5.

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

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

Annotations only say readOnlyHint=true; the description adds what the annotations can't: the polling cadence, expected wall-clock durations per model (Kling 3.0 ~2 min, Seedance 2-4, Omni/Motion Control/Veo 3-6), that the call is free, and exactly which result fields appear on completion (video_url + poster_url, image_url, file_url). That is real behavioral context beyond structured data.

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

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

Front-loaded with the core action and polling guidance, then return values, then model timings. It is dense with no filler, but the telegraphic fragments ('Seedance 2-4', 'Free.') cost a little readability.

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

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

There is no output schema, and the description compensates by enumerating the completion payload fields. With polling cadence, per-model latency, and the free-cost note, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema description coverage is 0%, so the description must carry the parameter burden and it largely does: frames is defined with its valid range (4-24), its meaning (a finished clip's contact sheet) and its cost (free). task_id is only implied by 'by id' without a format hint, which is the one small gap.

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

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

Opens with a specific verb+resource: 'Status of a task by id', which is precisely what the tool does and is distinguishable from list_tasks by the 'by id' framing. It stops short of naming the sibling that lists tasks, so it isn't maximally differentiated.

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

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

Gives concrete operational guidance: poll long jobs every ~15-30s, and per-model expected durations so the agent knows how long to wait. It never states when to use this versus list_tasks or cancel_task/retry_task, so the alternative routing is implied 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=true, so safety is covered. The description adds one genuinely useful trait beyond structured data — that each asset carries a permanent_url that never expires — but says nothing about pagination, result size, ordering, or whether category filters behave as expected for a listing call.

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

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

Two tight clauses with no filler; the listing scope is front-loaded and the project_id caveat follows immediately. Nothing could be cut without losing information.

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

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

For a zero-required-parameter list tool with annotations covering safety and no output schema, the description is minimally viable and even discloses one return field (permanent_url). It falls short on how limit/offset/category work, which an agent needs to page or filter correctly.

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

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

Schema description coverage is 0% and three of four parameters (limit, offset, category) are undocumented anywhere. The description explains only project_id's narrowing behavior, so it partially compensates but leaves the pagination and filtering parameters completely opaque.

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

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

States a specific verb and resource ('Lists the user's assets') and clarifies scope by defining assets as uploads plus references, which is a meaningful distinction. It does not contrast itself against siblings like get_asset or list_generations, but the core purpose is unambiguous.

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

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

The only usage signal is 'project_id narrows to one project', which is really parameter semantics rather than when-to-use guidance. There is no statement of when to prefer this over get_asset, list_generations, or search, and no exclusions or 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?

readOnlyHint=true already covers the safety profile, and the description adds beyond that: ref ids map to generate_video reference_image_ids and the operation is 'Free'. It does not mention pagination or return shape, so it clears the lowered annotation bar without being exhaustive.

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

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

Compact and front-loaded: resource types first, then the ref-id and @slug semantics, then cost. No filler, though the '@slug/alone' phrasing is terse enough to be ambiguous.

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

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

For a read-only list tool with full schema coverage and readOnlyHint, the description supplies the missing context (what the ids are for, prompt syntax, cost). Only the list output format is left unspecified, which is a minor gap given 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 both id and kind are already fully documented in the schema, including the skin enum meaning. The description adds the reference_image_ids linkage but does not elaborate on the two parameters themselves, so baseline 3 is appropriate.

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

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

The description enumerates the resource types it covers (characters, props, places) and ties them to generate_video ref ids, so the agent understands this is the reusable-entity lister. It is clear but stops short of an explicit verb like 'list all entities' and does not name a sibling it differs from.

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 '@slug' notes and 'Free' hint give usage context for consuming these entities in prompts, but there is no explicit when-to-use versus alternatives (e.g. list_assets). Usage is implied through the generate_video ref-id linkage rather than stated as guidance.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context beyond annotations: it specifies newest-first ordering, defines favorites:true as 'only the hearted (liked) ones', and promises each result includes an image_url. This gives the agent concrete expectations for output content without contradicting annotations.

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

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

Two compact clauses deliver the core purpose, ordering, filter, and return format with no repetition or filler. The action and resource are front-loaded, and the filter syntax is explained inline, making the description lean and immediately scannable.

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

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

The description covers the main return (image_url) and ordering, which partially compensates for the missing output schema. However, it does not mention pagination semantics (limit/offset), default behavior, error conditions (e.g., unknown project_id), or anything beyond the basic list scenario. For a tool with 4 parameters and no output schema, this is adequate but leaves gaps.

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

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

Schema description coverage is 0%, so the description carries the full burden. It adds meaning only for 'favorites' ('only the hearted (liked) ones'). It does not explain limit, offset, or project_id beyond their bare names, nor how they interact. Given four parameters, this is insufficient compensation for the missing 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?

The description clearly states the action ('Lists'), the resource ('generations in a project'), and adds ordering ('newest first') which distinguishes it from other list tools like list_assets or list_tasks. The combination of verb, resource, and specific behavior leaves no ambiguity about the tool's purpose.

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

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

The description implies usage by naming the resource and scope ('generations in a project'), and explains the favorites filter. However, it does not explicitly contrast with sibling tools (e.g., when to use list_assets instead) or state any exclusion conditions, so an agent must infer the appropriate selection 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?

The readOnlyHint annotation already communicates that this is a safe read operation. The description adds the ordering behavior, but does not disclose pagination behavior, return format, or any other operational details. With annotations present, this is adequate but not rich.

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

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

A single, front-loaded sentence with no filler. Every word adds meaning, and the most important scoping information ('the user's projects') comes first.

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 is sufficient for a simple read-only list operation, but it leaves the pagination parameters undocumented and provides no output expectations. Given the low schema description coverage and missing output schema, more detail would help.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented limit and offset parameters. It does not mention pagination at all, though the parameter names are conventional enough that an agent may infer their meaning.

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

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

States a specific verb ('Lists'), a clear resource ('the user's projects'), and a sorting behavior ('most-recently-updated first'). This clearly distinguishes it from sibling tools like list_assets or list_generations.

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

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

No guidance is given on when to use this tool versus get_project, resolve_project, or other list tools. The intended context is implied by the name and description, but no alternatives or exclusions are mentioned.

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 readOnlyHint annotation already declares this as a safe read operation. The description adds useful context about which task types are included, but it does not disclose behaviors like status filtering, pagination, ordering, or whether all users' tasks are returned. With annotations covering safety, a mid score is appropriate.

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

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

The description is concise and front-loaded with the verb and resource, and the examples are informative without being verbose. It earns its place by clarifying what counts as a background task. No redundant content.

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

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

With no output schema and two undocumented parameters, the description does not explain what the returned task objects look like, how status filtering works, or how limit behaves. It is adequate for a trivial read-only list, but the missing parameter and return-value context leaves gaps for an agent.

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

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

Schema description coverage is 0% and the description is silent about the 'limit' and 'status' parameters. Since there is no parameter documentation in the schema either, the agent receives no explanation of acceptable status values or how limit affects results. The description adds no meaning beyond the parameter names themselves.

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 'Lists' and the resource 'background tasks', and gives concrete examples (generations, uploads, scans, exports). It is distinct enough from siblings like get_task or cancel_task, though it does not explicitly contrast with list_generations or list_assets.

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 provides no guidance on when to use this tool versus alternatives such as list_generations or list_assets. It simply states what it lists, leaving the agent to infer usage context from sibling names.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false. The description adds useful behavior: it is free, matches names case-insensitively, and can create a project if no match exists. No contradictions with annotations.

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

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

Three short sentences with no waste. The core behavior is front-loaded, followed by idempotency/free status and a concrete usage pattern. Every sentence contributes.

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 two-parameter tool with no output schema, the description covers lookup, creation, parameter alternatives, and intended workflow. It does not describe the return shape in detail, but that is a minor gap given the tool's simplicity.

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

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

Schema coverage is 100%, so both name and project_id are documented. The description adds relational meaning: they are alternatives ('Instead of name'), and name matching is exact but case-insensitive.

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 precise behavior: find by exact name (case-insensitive), create if absent, or fetch by project_id. This clearly separates it from siblings like list_projects by specifying unique matching/creation semantics.

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 an explicit usage convention: follow the one-project-per-folder workflow by resolving the folder name and passing the returned project_id onward. It does not explicitly name alternative tools or state when not to use it, but the context is clear.

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

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds the costly, credit-consuming nature ('COSTS CREDITS (generate_* pricing)') and, importantly, that the original is never mutated ('Always creates a NEW generation; the original is untouched'). It also discloses source ambiguity for reference_id (asset OR owned generation), which structured fields 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?

It is a single dense paragraph, but it is front-loaded with the two highest-stakes facts (cost and non-destructiveness) and each clause adds distinct operational detail. The run-on density and packed mode list cost it the top mark.

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

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

For a 15-parameter tool with no output schema, the description covers all five modes, the cost model, non-destructive semantics, and reference/entity sourcing. It omits output shape (acceptable without an output schema) and defaults for resolution/aspect_ratio, but an agent could call it correctly from this text.

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 80%, so the schema already documents most parameters, but the description adds real meaning: it maps actions to required companions, gives merge_bias direction (0=reference, 100=base), and explains that entity_ids/@slug attach a saved entity's sheet. It leaves resolution, aspect_ratio, and blend_level to the schema, so it is strong but not exhaustive.

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 ('Edits an existing image with AI') and then enumerates the distinct modes (plain-text edit, product placement, recolor/remove/add, merge, style transfer), which lets an agent distinguish it from siblings like generate_image, expand_image, and cutout. It also names adjacent tools (get_detections, list_entities, generate_image) so the boundary is explicit.

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

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

Gives per-mode selection rules ('action bring + reference_id' for placement, 'action style + style_intensity' for style transfer) and routes the agent to alternatives where needed ('use get_detections for item names', 'list_entities' for entity sheets). This is explicit when-to-use guidance rather than 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 reveal the operation is mutating and non-destructive, but the description adds no context beyond that, such as whether retrying reuses original inputs, re-queues the task, or may consume credits. The description does not contradict the annotations, but it also provides no behavioral detail.

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 single sentence is concise and front-loaded, but it is also underspecified: it essentially restates the title and leaves meaningful behavioral and parameter guidance out. This is brevity rather than efficient completeness.

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

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

For a task-lifecycle mutation with no output schema, the description does not state what a successful retry returns, what state transitions occur, or whether retry is only valid after failure. It is too thin to fully support correct invocation.

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

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

With 0% schema description coverage, the description needed to explain task_id, but it only implies that the ID identifies the failed task. There is no explicit statement that task_id is the failed task's identifier or any detail about where to obtain it.

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

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

The description names a specific action, 'retries', and a specific resource, 'a failed task'. It is clear enough to distinguish from read-only task operations like get_task/list_tasks and from cancel_task, though it does not explicitly name a sibling.

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

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

There is no guidance on when to retry versus cancel or inspect a task, no mention of prerequisites such as the task needing to be in a failed state, and no discussion of alternatives. The phrase 'failed task' implies a condition but nothing 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 only say readOnlyHint=false and destructiveHint=true; the description goes further by specifying that refs REPLACES the reference set (not appends) while traits MERGES, and that unlink removes links by id. These replace-vs-merge semantics are the highest-risk behaviors here and are disclosed precisely, plus the tool is stated to be free.

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

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

Front-loaded with purpose, then parameter semantics in a tight telegraphic sequence with no filler sentences. The dense clause-stacking ('pictures you own as [{kind: generation|asset, id, role}]') is efficient but costs some readability, keeping it below 5.

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

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

For a 9-parameter, nested-object, create-or-edit tool with no output schema, it covers the dual mode, all mutation semantics, the enum-constrained fields, and closes the loop by explaining where the returned id is consumed (storyboard cast/places, entity_ids, or @slug in a prompt). 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?

With only 67% schema coverage, the description compensates heavily: it explains that description maps to bio.description, that traits merges any other trait, that links' to_type is the target's kind or product, and it enumerates valid refs roles per kind (character face/front/three_quarter/side/back/detail; place wide/angle/detail; prop front/side/back/detail) that the schema leaves as a bare string.

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

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

The description opens with a specific verb+resource pair ('Creates or edits a character, prop, place, skin or look') and immediately scopes the tool with 'and links it to others.' It is clearly distinguishable from siblings like list_entities or delete_asset, and it names the entity kinds matching the schema enum.

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 an explicit branch rule: 'Without entity_id it finds or creates by kind and name; with entity_id it edits that one,' which is exactly the decision an agent needs. It also routes to list_entities for link ids. It lacks an explicit when-not-to-use clause (e.g. vs. generate_sheet or storyboard), so 4 rather than 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 (readOnlyHint=false, destructiveHint=false), the description reveals that the tool costs credits, takes 5-20 seconds, and returns synchronously when done. It also discloses that results are consumed by search and get_detections, giving the agent a clear picture of side effects and resource implications.

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 with zero filler. The core purpose is front-loaded, followed by cost, latency, and a strong 'usually unnecessary' caveat. Every clause adds 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 tool with only two parameters and no output schema, the description covers the essentials: what it does, cost, latency, and when to avoid it. It does not specify what the return value looks like (e.g., a task ID), but given the presence of sibling tools like get_task, this omission is minor.

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

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

Schema coverage is 100%, with target_id and target_type already described. The description merely restates 'generation or asset' without adding new format or usage details, so it does not elevate the parameter understanding 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 clearly states the tool 'runs the detection scan' on a generation or asset, and enumerates the detection types (items, colors, textures, scene). It distinguishes itself from retrieval tools like get_detections by focusing on the action of scanning rather than reading results.

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 explicitly says 'Usually unnecessary' because scans happen automatically, which tells the agent not to use it by default. It also notes that results power search and get_detections, implying those are the downstream consumers, though it stops short of naming when exactly to force a scan (e.g., after a failed scan).

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 readOnlyHint annotation covers safety, and the description adds substantial behavioral context beyond that: results can include matches inside videos with an exact video_moment timestamp, and each image_url is only a 600px preview rather than the full original. This materially changes how an agent should use the returned data.

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 dense but well structured: core capability first, then mode definitions, then scoping/filtering, then special result behaviors, then a caveat with an alternative tool. Every sentence adds operational value, and the length is justified by the tool's 15 parameters and lack of an output schema.

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

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

For a complex search tool with no output schema, the description covers the critical gaps: mode interactions, required versus optional inputs, result shapes like video_moment and regions, preview limitations, and the pointer to list_generations for full-fidelity originals. Remaining details like limit and offset are already present in the schema.

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

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

Schema coverage is already high at 87%, so the description does not need to re-document parameters. It adds value by explaining mode-dependent semantics such as query being required for text mode, similar modes requiring anchors, and include_regions producing bounding-box data, plus the video_moment consequence of certain text results.

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

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

The description opens with a specific verb and resource: detection-aware search across the user's assets and generations. It distinguishes itself from title/prompt-based retrieval and from sibling listing tools by emphasizing what the scanner SAW inside each image, and it breaks out four distinct modes so an agent immediately understands the tool's scope.

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 mode-specific usage rules: text requires a query, color ranks by hex closeness, similar needs an anchor, and browse requires no query and is for exploration. It also instructs when to step outside this tool, telling the agent to re-read the original from list_generations before using a hit in a document.

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

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

With readOnlyHint already flagging a safe read operation, the description adds useful behavioral context: 'FREE' signals cost behavior, and it discloses mode-dependent response content (index vs full frame lists). It does not mention rate limits or auth, but for a read-only menu tool with this annotation, the additional context is sufficient.

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 dense but economical; every sentence adds either domain context or call behavior. The leading 'FREE' and core purpose are front-loaded, and the rest of the content explains invocation modes without filler. The first sentence is a long enumeration, but it remains readable 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?

Given no output schema, the description carries the burden of explaining return values, and it does: no arguments yields the index, while family+type yields full frame lists. It also mentions frame counts per detail level and resolution ceilings, which are the key data points an agent would need. It is complete enough for a read-only menu tool.

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

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

The schema already documents both parameters, so the baseline is 3. The description goes beyond by explaining the no-argument case, the family+type combination, and the relationship to generate_sheet. This adds practical meaning to the parameters rather than just repeating schema names.

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 identifies the resource as the menus/options a sheet is made from: kinds, keyable grounds, art styles, animation sequences, levels, and image models. It also differentiates from generate_sheet by stating 'The ids go straight into generate_sheet.' It lacks an explicit verb like 'returns' or 'lists,' but the behavioral intent is unambiguous from 'No arguments = the index, ids and one-liners.'

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 specifies two calling modes: no arguments returns the index, and family + type returns that type's sequences with full frame lists. This tells the agent exactly when to call with parameters versus empty. It names generate_sheet as the downstream consumer but does not explicitly discuss when not to use this tool versus alternatives.

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

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

Annotations only say readOnlyHint=false / destructiveHint=false; the description goes well beyond by disclosing that make costs purchasable credits, that dry_run is free and lists voices, that credits_charged must be surfaced, that upload is free but consumes storage with a 20 MB and MP3/M4A/OGG/WAV limit, and that record hands the user a page link. Pagination and edit reversibility are not covered, so not a 5.

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

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

It is compact with no filler, but the telegraphic style hurts parseability: the lead fragment 'kind music|sfx|ambience|voice.' is an odd opener and 'Named seconds after landing: get again' is cryptic on first read. Density here buys coverage at the cost of clarity.

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 16-parameter, six-action tool with no output schema and no parameter descriptions, the text does substantial work, but gaps remain: q, limit, and project_id are unexplained, and with no output schema the description never says what search returns or what make produces. An agent can act, but not without ambiguity.

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

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

Schema description coverage is 0% across 16 params, yet the text explains most of them in context: kind as a comma list, hidden's effect, id+name/category/tags/language/hidden for edit, url for upload, prompt/seconds/voice_id for make, dry_run's role. Only q, limit, and project_id are left undefined, which is a solid compensation for a bare 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 enumerates the verbs (search, get, edit, make, upload, record) against the sound-library resource and immediately names the four kinds (music|sfx|ambience|voice), so an agent knows this is the audio asset tool. It lacks a single front-loaded purpose sentence and never explicitly contrasts itself with the image/video siblings, which keeps it below 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?

Per-action conditions are given: search is the default, dry_run:true is the free quoting step before a paid make, and the agent is told to confirm with the user before spending credits. That is real when-to-use guidance, though there are no explicit when-not rules or sibling alternatives.

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

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

Annotations already declare destructiveHint=true, and the description usefully adds credit costs, dry_run quoting, public sharing, permanent deletion with confirm, and free actions. That is meaningful beyond the annotations, though it does not cover permissions or rate limits.

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

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

The content is a single dense block of domain abbreviations and semicolon-separated options; the opening is not front-loaded with purpose. Much of the detail is necessary for a 23-parameter tool, but the structure makes it hard to parse.

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

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

For a complex mega-tool with no output schema, the description covers domain vocabulary and many actions but leaves return values, pagination, and error behavior largely unexplained. It is not complete enough for reliable use without opening the schema.

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

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

Schema coverage is only 39% across 23 parameters, so the description must compensate. It explains many action-specific and mutation parameters in dense prose, but key schema fields like at_s and amount remain thin and the coverage is uneven.

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 cryptic sentence ('A film the owner watches on its page') rather than a direct verb+resource, then defines keyframe/segment/decision and later lists actions. An agent can infer that the tool manages a storyboard project, but the purpose is not stated crisply and 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?

It supplies operational hints such as 'dry_run first' and 'COSTS CREDITS', plus which actions are free, but never says when to choose this tool over siblings like generate_image or save_entity. The action list is a menu, not usage 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 declare readOnlyHint=false and destructiveHint=false; the description adds materially: it costs credits priced like generate_* at the target resolution, it is non-destructive (creates a new generation), and it inherits the source's project. It stops short of describing async/task behavior or failure modes, which for a credit-spending operation would be valuable.

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

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

Front-loaded with the core action, then cost, then side effects, then the asset_id branch. Dense and telegraphic but every clause carries distinct information, and the parentheticals keep it to a compact block.

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 4-param, no-output-schema tool, the description covers what an agent needs: what it produces, that it costs credits, that it does not mutate the source, the mutual exclusion between the two base inputs, and output placement. Only async/task-return behavior is unaddressed.

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

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

With only 50% schema coverage (asset_id and generation_id are undocumented in the schema), the description compensates well: it establishes that asset_id and generation_id are mutually exclusive ('not both'), that project_id applies only to asset_id, and where the result lands in each case. It does not explain expected ID formats or what happens if neither base is supplied.

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-renders an existing generation at a higher resolution') with the concrete effect ('sharper detail'), and clarifies that it produces a NEW generation rather than mutating the source. This distinguishes it from restyle/expand_image/generate_image, which an agent could otherwise confuse with it.

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

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

Usage is implied (call it when you need a higher-resolution version of an existing generation or asset), and the description does clarify that an uploaded asset works as a base. But it never explicitly says when to prefer this over expand_image, restyle, or a fresh generate_image call, so alternative selection is left to inference.

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

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

The readOnlyHint annotation already covers the main safety trait, and the description adds useful context by noting the call is free and listing response contents such as server version and capabilities. However, it does not disclose potential authentication requirements, error conditions, or rate limits, which would be valuable given there is no output schema. The description adds some context but not rich behavioral detail beyond the annotation.

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

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

The description is a single, information-dense sentence that front-loads the primary purpose and appends the cost note at the end. Every word contributes meaning, with no repetition of schema content or filler. This is exemplary conciseness for a simple tool.

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

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

For a parameterless, read-only account-query tool, the description gives a complete high-level inventory of the response: identity, plan, credits including daily cap, storage usage/quota, and server version/capabilities. It does not specify data types or units, but the lack of an output schema makes some ambiguity unavoidable. Overall, an agent knows exactly what information it can obtain from this tool.

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

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

The tool accepts zero parameters and the input schema is an empty object, so there is nothing for the description to explain. Per the zero-parameter baseline, the description needs no additional parameter documentation. There is no gap in this dimension.

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 identifies the tool as an account/status query, enumerating exactly what it returns: identity, plan, credits (balance and daily cap), storage used/quota, and server version/capabilities. It is instantly distinguishable from all sibling tools, none of which provide this account-level information. Despite not using an explicit verb, 'whoami' is a standard convention and the description is unambiguous.

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

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

The description provides clear context: use this tool when you need the current user's identity, plan, credits, storage, or server capabilities. No sibling tool overlaps with this functionality, so there are no alternatives to exclude. The absence of an explicit 'when to use' statement is acceptable because the tool's purpose is self-evident and uniquely scoped.

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