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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that rows belong to other accounts, prompts are hidden, NSFW rows are excluded unless includeNsfw is set, every row carries nsfwFlagged for safeguards, and it costs nothing. This is rich behavioral context that significantly aids the agent.

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

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

Four sentences, each adding essential value: purpose, use case, ownership, and NSFW behavior. It is front-loaded with the core purpose and includes no fluff, maintaining high information density.

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

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

For a read-only browse tool with three simple parameters, the description is complete. It covers what the tool does, its use case, key behavioral details (ownership, prompts hidden, NSFW handling), and an alternative action, making it fully self-contained without an output schema.

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

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

The schema already covers all parameters (100% coverage), but the description adds meaningful semantics: it explains that NSFW rows are excluded by default and that includeNsfw enables them, and that each row includes nsfwFlagged for safeguards. This goes beyond the schema's bare parameter 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 starts with a specific verb+resource+scope: 'Page through the 2DAI public feed — what creators across the platform have published, newest first.' It clearly distinguishes from siblings like list_creations by noting rows belong to OTHER accounts and are suitable for inspiration and trend scans, with a pointer to organise_creation for liking.

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 states the use case ('Useful for inspiration and trend scans') and mentions an alternative for acting on rows ('you can like them with organise_creation'). It also clarifies NSFW filtering behavior, guiding when to set includeNsfw. This provides clear context for when to use the tool.

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

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

The description provides significant behavioral disclosures beyond the annotations: the charge is refunded, the queue slot is freed, the operation only succeeds before processing starts, and if the job has already started it returns an explanation with the current status instead. It also clarifies that calling it costs nothing. These add value beyond the readOnlyHint/idempotentHint/destructiveHint flags.

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 sentences, front-loaded with the primary action and outcome. Every clause adds essential information: the waiting state, the refund, the slot release, the timing limitation, and the failure behavior. No wasted words or irrelevant details.

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

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

For a one-parameter tool with no output schema, the description fully covers the operation's behavior in both success and failure cases. It explains the side effects (refund, slot free), the limiting precondition (must be waiting), and the failure response (returns explanation with current status). No gaps are apparent.

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 description already covers queueId at 100%, stating it comes from a previous generate_* call, which sets a solid baseline. The tool description adds meaning by specifying that the queueId must refer to a generation still WAITING in the queue, and that other states will yield an explanation. This clarifies the parameter's expected provenance and preconditions beyond the schema.

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

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

The description clearly states the action (cancel), the resource (a generation in the queue), and the specific state condition (WAITING). It distinguishes this from sibling tools like check_generation (which checks status) and the generate_* tools (which create queued jobs). The title reinforces the 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 explicitly states when to use the tool (only before processing starts, while the job is waiting) and when not to (once a worker has picked it up, it cannot be aborted). It does not name an alternative tool, but this is acceptable because no sibling offers cancellation after processing. The refund/cost context also guides usage decisions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description adds value by clarifying that it is a polling operation that reports running status and returns the completed creation once available. It also discloses that it costs nothing, going beyond the structured metadata. No contradiction with annotations.

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

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

The description is three sentences, each adding essential information: what the tool does, the trigger condition, the behavior, and the cost. It is front-loaded with the main action ('Look up a generation by its queueId') and contains no filler. Extremely efficient.

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

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

For a simple one-parameter read-only lookup, the description covers the purpose, when to use it, what it reports, what it returns, and the cost. The lack of an output schema is acceptable because the behavior is straightforward. It could mention edge cases like invalid queueId, but overall it is sufficiently 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?

The schema describes queueId simply as 'The queueId from a previous generate_* call.' The tool description enriches this by explaining that the queueId is the one returned when a generate_* call outlived its wait budget, providing important context for why the agent would have this ID. With 100% schema coverage, the baseline is 3, but this extra semantic detail justifies a 4.

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

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

The description clearly states it looks up a generation by queueId and specifies the exact source of that ID (from a generate_* call that outlived its wait budget). It also explains what it reports (running status) and what it returns (finished creation), making its purpose distinct from sibling generate and cancel tools.

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

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

It explicitly indicates when to use this tool: when a generate_* call times out and you need to check the result. It also notes that it costs nothing, which is an implicit reason to prefer it over other operations. It does not explicitly name alternative tools or exclusions, but the context is clear enough for an 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?

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses critical behaviors: full-res writes to disk with automatic extension, preview is downscaled and safe for context window, and path safety constraint with TWODAI_ALLOW_ANY_PATH override. It also clarifies that the tool never injects full bytes into the context, which is important for the agent. No annotation contradiction exists.

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 three sentences, each packed with distinct, necessary information: purpose, mode behavior, and path constraint. It is front-loaded and concise without unnecessary elaboration. Every sentence earns its place, making it highly efficient for an AI agent 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?

Given that there is no output schema, the description adequately explains the return values for both modes (path or inline preview). It also covers the environment variable override and the dual-ID input context. While it does not detail error cases, it provides enough operational context for the agent to invoke the tool correctly, making it complete for the tool's complexity.

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

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

The schema provides 100% coverage for all three parameters, so the baseline is 3. The description adds extra meaning by explaining the semantics of savePath (full-resolution, extension appended, returns path) and the behavior when savePath is absent (preview image). This goes beyond the schema's bare field descriptions, though it does not add new details for cdnId or creationId 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 begins with a specific verb+resource ('Fetch a creation's media') and then immediately contrasts two clear modes: saving full-resolution to disk with savePath vs. returning a downscaled preview inline. This makes the tool's purpose unambiguous and distinguishes it from siblings like list_creations or browse_feed, which handle discovery rather than media retrieval.

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

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

The description gives clear context on when to use each mode (savePath for full-res file, no savePath for inline preview), which serves as usage guidance. It does not explicitly name alternative tools or state when not to use the tool, but the conditional usage is clear enough that the agent can decide correctly. There are no exclusions or conflicting 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?

The description adds valuable behavioral context beyond the annotations: it explicitly warns 'This SPENDS the account's credit' and explains the async return behavior ('Returns the finished creation when it lands within the wait budget, otherwise a queueId to poll with check_generation'). This is exactly the kind of non-obvious behavior an agent needs to know. No contradiction with annotations.

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

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

Three sentences, each with a clear purpose: what it does, credit/return behavior, and default behavior. No redundancy or filler. Front-loaded with the core action.

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

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

The description covers the critical operational aspects: credit consumption, synchronous vs. queued return, and default style/quality. Given the 7-parameter schema already documents individual parameters, this is sufficient. It loses one point for not mentioning alternative generation tools (like generate_with_refs) which would help an agent choose among siblings, but within its own scope it is complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description only restates the style and quality defaults that already exist in the schema ('Style and quality default to "auto"'), adding no new parameter semantics. It does not enrich understanding of prompt, wait, allowNSFW, or aspectRatio beyond their 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 tool's function: 'Generate an image on the 2DAI account from a text prompt.' It identifies a specific verb, resource, and scope. However, it does not explicitly differentiate from sibling tools like generate_with_refs or generate_video, so it stops short of a full 5.

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

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

There is no guidance on when to use this tool versus alternatives. The description does not mention exclusions or recommend generate_with_refs for reference-based generation, generate_similar for variations, etc. It only describes the action, leaving the agent to infer usage context.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the operation spends account credit, deduplicates rapid identical calls within ~5s, and refuses non-derivable types. This adds valuable behavioral context for an agent assessing side effects and costs.

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 three sentences, each serving a distinct purpose: mechanism, cost, and dedup/refusals. It front-loads the primary action and avoids filler or repetition, making it highly efficient.

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 adequately covers the tool's behavior (re-derivation, credit cost, dedup, refusals) without an output schema. It does not explicitly describe the return value (e.g., generation ID or queueId), but the wait parameter hints at queue behavior, so the gap 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?

The input schema already provides full descriptions for creationId and wait, with 100% coverage. The description adds no new parameter-level semantics beyond restating that parameters are re-derived, so it neither improves nor harms understanding.

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 function: 'Re-run an existing creation' with the server re-deriving all original parameters. It specifies the resource (an existing creation) and the verb (re-run/fresh generation), distinguishing it from generation tools that create new items.

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

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

The description gives clear when-to-use context ('natural make more like this one verb') and explicit exclusions ('Raw uploads and wallpaper-resize outputs... refused'). It does not name alternative sibling tools, but the guidance is sufficient for an agent to decide when this tool is appropriate.

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

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

The description adds significant behavioral details beyond the annotations: it explicitly says 'SPENDS the account's credit — video costs several times an image,' and explains the asynchronous nature ('Takes ~1-3 minutes, so it usually returns a queueId...'). These details are not present in the annotations (readOnlyHint, openWorldHint, etc.) and are crucial for the agent to manage cost and expectations. No contradiction with annotations.

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

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

The description is concise—three or four short sentences—with the purpose stated first. Each sentence adds value: purpose, cost, async behavior, and duration options. It is front-loaded, allowing the agent to quickly grasp the core function and key operational caveats. There is no redundant or filler 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?

Given the tool's complexity (8 params, no output schema), the description covers essential operational context: it mentions credit cost, asynchronous queueId retrieval, and duration variants with tier-gating. It does not describe the return object structure in detail, but it mentions queueId, which is sufficient for the agent to know what to expect. The schema handles parameter details, so the description is complete enough for this context.

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 input schema provides descriptions for all 8 parameters (100% coverage), so the baseline is 3. The description itself only repeats duration information ('Durations: 5, 6.5 or 7.5 seconds (7.5 is tier-gated)') which is already in the schema. It does not add any extra semantic meaning about parameters like prompt, style, or quality, so it meets the baseline but does not exceed 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 clearly states the tool's purpose: 'Animate an existing still creation into a short clip.' This specifies a verb (animate), a resource (still creation), and the output type (short clip), effectively distinguishing it from sibling tools like generate_image or generate_similar. The title 'Generate a video from a still' reinforces the purpose without ambiguity.

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 have an existing still creation and want to animate it into a video. It also advises that the operation takes 1-3 minutes and typically returns a queueId to collect with check_generation, which guides follow-up behavior. However, it does not explicitly mention alternatives or state when NOT to use this tool in favor of other generation tools, so it falls short of a 5.

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

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

The description discloses critical behavioral traits beyond the annotations: it spends the account's credit, the price varies by dimension, quality is fixed at Ultra, unknown dimension values are rejected, and the wait/queue behavior is explained. This goes beyond the simple hints and gives the agent a clear picture of side effects and return behavior.

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

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

The description is compact and front-loaded with the main purpose. Each sentence adds value: purpose, cost, dimensions, optional steering, and return behavior. No fluff or repetition.

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

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

For a tool with 6 parameters, no output schema, and 21 siblings, this description is sufficiently complete. It explains what the tool does, how the output is returned (finished creation or queueId), the pricing model, and the available dimensions. An agent can confidently invoke this tool without further clarification.

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?

While the schema has 100% coverage for parameter descriptions, the description adds meaningful semantic context: it links dimension to price, explains that refs and prompt steer the newly painted areas, and clarifies the wait budget behavior for the wait parameter. This enriches the parameter understanding beyond the schema.

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

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

The description clearly states the tool's function: expanding an existing creation into a wallpaper format. It uses a specific verb ('expand') and resource ('creation'), and differentiates itself from sibling tools like generate_image or generate_with_refs by focusing on wallpaper expansion with preserved content and outward painting.

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 when to use this tool (for expanding an existing creation into a wallpaper) and provides context about pricing, fixed quality, and available dimensions. It does not explicitly exclude alternatives, but the scenario is clear enough for an agent to decide. It could have explicitly contrasted with generate_similar or generate_with_refs, but the core usage is well conveyed.

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

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

The description discloses a critical behavioral trait not fully captured by annotations: 'This SPENDS the account's credit.' It also explains the synchronous/asynchronous return behavior ('within the wait budget, else a queueId for check_generation'), which is useful operational context beyond the readOnlyHint=false 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 dense paragraph but each sentence contributes unique information: main purpose, credit cost, sub-tool breakdown, reference source, and return behavior. It is front-loaded with the headline action and remains readable for a tool with this complexity.

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

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

For a complex tool with 8 parameters and no output schema, the description explains the return contract, credit cost, sub-tool semantics, and reference id sourcing. It does not spell out every parameter nuance, but the schema already covers those; the description fills the behavioral gaps that matter for 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?

Even though the schema describes all 8 parameters, the description adds valuable relational semantics: it explains how refCreationIds count varies by sub-tool (1-6 for face/character, 1-3 for style, 4 for smart-edit) and that prompt is optional for style-transfer but required for smart-edit. This goes beyond the static schema definitions.

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

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

The first sentence immediately states the core action: 'Generate an image conditioned on existing creations.' It then enumerates four distinct sub-modes (face-ref, character-ref, style-transfer, smart-edit) with precise behavior for each, making it unmistakable what this tool does and how it differs from its siblings.

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

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

The description gives clear guidance on when to use each sub-tool: face identity, character consistency, style extraction, and smart editing. It also tells users where reference ids come from ('earlier generations, upload_image or list_creations') and clarifies prompt requirements per mode. It does not explicitly say 'use this instead of generate_image' or list when-not-to-use, but the context is strong.

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 safe read nature is covered. The description adds context about what information the tool reveals (available credit, tier, key label, scopes, spend cap) and the recommended timing, which helps set expectations. It does not contradict the annotations and adds meaningful usage context.

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

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

The description is two sentences, concisely front-loaded with the action and output details, followed by a practical usage instruction. Every sentence serves a purpose, with no redundant or filler 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?

Given the simplicity of the tool (no parameters, no output schema), the description is fully complete. It enumerates the exact output fields, explains why the tool matters, and specifies when to call it. The sibling tools are not relevant because the purpose is clearly unique.

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

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

The tool has zero parameters, so the schema is complete by definition. The description adds no parameter-specific details, but none are needed. Baseline for 0 params is 4, and the description's list of outputs helps the agent understand what 'account' entails, though that is output semantics rather than parameter semantics.

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

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

The description uses a specific verb 'Show' and names the resource 'connected 2DAI account', listing the specific data fields (credit, tier, key label, scopes, spend cap). This clearly distinguishes it from sibling tools like get_wallet_status or get_token_price, which focus on wallet/price rather than account and API key details.

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 states when to use the tool: 'Call this before proposing generations to check there is enough credit and the right scopes.' This provides clear context and rationale, though it does not mention alternatives or when not to use it, which would make it a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the description adds value by detailing the required finance scope and the specific return states (none, active, expiring-soon). It also clarifies that this tool is not for managing locks, which is useful context beyond the annotations. No contradiction exists.

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 three sentences, front-loaded with the primary purpose, then adding scope requirements and a management note. Every sentence contributes necessary information without redundancy or filler, making it highly concise and well-structured.

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

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

This simple tool has no output schema and no parameters, so the description must cover the return information itself. It does this by listing the possible statuses and the time threshold, plus the scope prerequisite. Given the low complexity, the description is complete and leaves no important 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?

With zero parameters, the schema provides complete coverage, and the baseline for 0 params is 4. The description appropriately omits parameter details since there are none, and it does not need to compensate for any schema 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 provides a read-only view of the account's staking lock, enumerating possible states (none, active, expiring-soon) with a specific threshold (under 24 hours). This specific verb+resource combination distinguishes it from sibling tools like get_wallet_status, which target different aspects of account state.

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

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

The description implies the tool is for checking lock status and explicitly states that locks are managed in the dashboard, not here, providing an exclusion. However, it does not explicitly mention alternative tools or provide a when-to-use vs. when-not-to-use comparison, so it stops short of a 5.

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

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

The description discloses that data comes from a server-side cache, that cache age is reported, and that stale caches refresh in the background. It also notes the output structure (first line summary, JSON detail) and that the call 'costs nothing.' This goes well beyond the annotations (readOnlyHint, openWorldHint) and gives agents practical expectations for side effects and latency.

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 core purpose and then enumerates the data dimensions, cache behavior, and output format. It is efficient, but the long comma-heavy structure could be split into two or three sentences for easier parsing without losing 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?

Given the tool's breadth (multiple metrics, time windows, cache, output summary), the description covers what the response contains (summary line + JSON detail), the cache refresh behavior, and the cost implication. With no output schema, this is sufficient for an agent to understand what it will receive and how to 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?

The only parameter, 'days', is fully described in the schema with its range and default. The tool description restates the 30/90-day window but adds no new semantic detail. With 100% schema coverage, the schema carries the meaning, so a baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as a consolidated read of account activity, enumerating specific metrics (creation counts, streak, storage use, generation volume, spend, most-used references, styles, keywords) and the optional time window. This distinguishes it from sibling tools like get_account or list_creations, which focus on individual data types.

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

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

The phrase 'One consolidated read' implies this is the go-to for a broad overview, and the description explains what data is included. However, it does not explicitly state when to use this tool instead of, or in combination with, alternatives such as get_wallet_status or list_creations, nor does it mention exclusions.

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

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

The description adds key behavioral details beyond the readOnlyHint annotation: the quote is served from a cache, never triggers a live refresh, and staleness is included. It also notes the cost is zero. This provides a clear safety and reliability profile.

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

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

The description is three concise sentences, front-loading the core purpose. Each sentence adds a distinct detail (scope, caching, cost), without redundancy.

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

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

For a simple parameterless read-only tool, the description fully covers the essential context: what it returns, how fresh it is, the access scope, and cost. No output schema is present, but the description compensates by explaining the staleness indicator.

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

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

The tool has zero parameters, so schema coverage is total. The description doesn't need to explain parameters; it instead explains the output's nature. This meets the baseline for a parameterless tool.

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

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

The description clearly identifies the tool as returning the cached $2DAI/USD quote. It specifies the resource ($2DAI price) and the nature (cached quote), distinguishing it from other tools in the sibling list that handle accounts, creations, or wallet 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?

It states the scope requirement ('ordinary read scope'), implies it's for indicative quotes due to cache, and clarifies that no finance scope is needed. However, it doesn't explicitly say when not to use it or name an alternative, but as the only price tool, the context is sufficient.

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 annotation, the description discloses a critical auth requirement (opt-in finance scope), pagination behavior for transactions, ordering (newest first), and the window-based nature of other kinds. This adds substantial context not available from annotations alone.

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

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

The description is two dense sentences, front-loaded with the core purpose and then expanding with kind-specific details. Every clause adds information, with no filler or redundancy.

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

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

Despite no output schema, the description explains what each kind returns (transactions list, balance chart points, credit chart points, sources breakdown), covers pagination and windows, and mentions the required scope. It is complete enough for an agent to invoke correctly.

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

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

Schema coverage is 100% and parameter descriptions already explain each field. The description adds meaningful semantics by elaborating on each kind's return content and clarifying that the 'limit' parameter has different interpretations depending on kind. This goes beyond the schema but the baseline is already high.

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

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

The description clearly states it is read-only money history for the account, and enumerates the four kinds (transactions, balance, credit, sources) with explicit meanings. This distinguishes it from related siblings like get_wallet_status and get_token_price by focusing on historical data rather than current state.

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

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

The description gives clear context on what the tool does and the different data kinds, implying when to use it. It does not explicitly name alternatives or state when not to use it, but the scope is well-defined and the auth requirement is mentioned, giving the agent enough to select it appropriately.

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

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

Annotations already declare readOnlyHint=true, and the description adds significant beyond-annotation context: it requires the 'finance' scope, explains how the effective tier is computed, and explicitly reassures that no tool on the server can move money. This adds operational and safety details not available in annotations alone.

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

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

The description is two sentences, front-loaded with the core purpose, and every phrase adds value (balance, credit, tier signals, operation flags, scope requirement, safety note). It is dense but not verbose, effectively using structure to convey a complete picture.

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

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

For a zero-parameter, no-output-schema tool, the description is exceptionally complete: it states what data is returned, how tier is derived, what flags are included, and the required scope. No critical information is missing for an agent to correctly invoke 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 has zero parameters, so the baseline is 4. The description compensates by detailing what data is returned and the prerequisites, fully covering the no-parameter case without needing parameter-level explanations.

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 provides a 'Read-only wallet snapshot' and enumerates its contents (DAI balance, USD credit, effective tier with derivation signals, in-flight operation flags). This distinguishes it from siblings like get_wallet_history (historical view) and get_token_price (price lookup). Thus it meets the bar for specific verb+resource+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?

The description clearly frames the tool as a read-only status snapshot, implying current-state usage rather than historical queries, which is left to get_wallet_history. It also mentions the opt-in 'finance' scope prerequisite, providing context for when the tool can be used, though it does not explicitly name alternative tools or exclusion 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?

Though readOnlyHint is present, the description adds substantial behavioral context beyond the annotation: pagination via nextBeforeDate, mode mutual exclusivity, random selection behavior, row-level fields (nsfwFlagged, nsfwRate, viewUrl), and the note that it 'costs nothing.' 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?

The description is dense but every sentence earns its place. It uses semicolons to group related constraints and covers modes, cross-cutting filters, pagination, and output row hints without redundancy. Appropriate for a tool with 13 parameters.

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 listing tool with no output schema, the description thoroughly covers filter modes, mutual exclusivity, cross-cutting filters, pagination, and row-level fields. It provides enough information for correct invocation without needing additional documentation.

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?

All 13 parameters are already documented in the schema, but the description adds significant semantic value: folderId 'root' for ungrouped, usedRef meaning 'built from', search prefix behavior with '*', smart collection aliases, and pagination cursor semantics. This goes far beyond what the schema alone 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 uses a specific verb ('Page through') and resource ('the account's creations'), with additional detail about newest-first ordering and a random mode. It clearly distinguishes this tool from siblings like browse_feed by scoping to the account's own creations.

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

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

The description gives clear usage context: it lists account creations and explains the mutually exclusive filter modes and cross-cutting filters. However, it does not explicitly name sibling tools as alternatives or state when NOT to use this tool, so it falls just short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read. The description adds useful behavioral context: it states 'Page through' (pagination) and 'Costs nothing' (no billing impact), which goes beyond the annotations. The absence of rate limits/auth notes is acceptable given the annotation coverage.

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 concise sentences, front-loaded with the primary action. Every sentence adds value: the first explains the function, the second explains downstream usage and cost. No filler or repetition.

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

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

For a simple list tool with no output schema, the description covers purpose, usage, cost, and pagination. It names relevant sibling tools for downstream operations, providing context. It could mention the return format or sort options, but those are already in the schema, so the description is sufficient for an agent to select and invoke the tool correctly.

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

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

Schema coverage is 100% with detailed descriptions for all three parameters (sort, limit, beforeDate), so the baseline is 3. The description adds no extra parameter semantics; 'Page through' implies pagination but the schema already explains beforeDate. The description doesn't introduce new information about parameter usage.

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 pages through the account's folders/collections, using a specific verb and resource. It distinguishes itself from siblings by explaining how the folderId is used with list_creations and organise_creation, which are likely to be confused with this tool.

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

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

The description explicitly states when to use the tool's output: use folderId with list_creations to see folder contents or with organise_creation to move items. It also notes the operation 'costs nothing', implying it is a safe/free operation for listing purposes. This is clear guidance on how to use the tool and its relationship to 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?

The description goes well beyond the annotations by disclosing critical behavioral details: 'never a permanent delete', creations detach to drive root or go to trash with trashContents=true, delete-group only detaches folders, and null semantics for set-poster and move-to-group. This adds significant value without contradicting the readOnlyHint/destructiveHint annotations.

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

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

The description is a dense single paragraph packed with essential information for all 10 actions. Every sentence earns its place, but the structure relies heavily on semicolons and could benefit from bullet points to improve scanability. It is appropriately sized for the complexity, though not maximally clean.

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

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

For an 8-parameter, 10-action tool with no output schema, the description covers all actions, permissions, and edge cases (trash vs detach, null handling). However, it does not mention what the tool returns (e.g., success object, folder details), which would help given the lack of an output schema.

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

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

Schema coverage is 100%, but the description layers action-dependent semantics on top: groupId usage varies by action, title is required only for specific actions, and null behavior for posterCreationId/groupId is clarified. This enriches the bare schema descriptions with contextual interaction rules.

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 'Folder CRUD plus sidebar organisation on the account's cloud drive,' which clearly states the tool's scope. It then enumerates all 10 actions (create, rename, delete, set-favorite, set-poster, move-to-group, group actions), making its purpose unmistakable and distinguishing it from siblings like list_folders.

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 context on when to use the tool by listing its actions and noting permission requirements ('needs the "manage" scope; "list-groups" only needs "read"'). However, it does not explicitly compare to alternative tools or state when NOT to use it, though the scope is clear enough for a dispatcher-style tool.

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

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

Beyond the annotations (mutating, destructive), the description adds critical nuance: trash is reversible, restore undoes trash, delete is permanent and requires prior trashing, batch operations are reversible, and like/unlike are idempotent setters. It also discloses the 'manage' scope requirement, which 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?

The description is a single dense paragraph but well-organized by action type. Every sentence carries necessary behavioral details, though a list format could improve skimmability. 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?

Given the tool has 8 actions, 4 parameters, and no output schema, this description is exceptionally complete. It covers prerequisites, reversibility, idempotency, batch limits, and the critical rule that delete only works on trashed creations. An agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so each parameter already has a clear definition. The description mostly echoes the schema (e.g., folderId supports 'root', creationId applies to all non-batch actions). No significant additional parameter meaning is provided, meriting the baseline score.

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: 'Organise creations on the cloud drive' and lists all actions (move, trash, restore, delete, like/unlike, batch-trash/batch-restore). The title also enumerates these actions, making it distinct from sibling tools like manage_folder.

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?

Action-specific guidance is provided: move requires folderId or 'root', delete only works on already-trashed creations and only after explicit user request, and batch actions handle up to 100 ids. It does not compare against alternative tools, but the per-action conditions are explicit and actionable.

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, idempotentHint=true, openWorldHint=true), the description discloses the required scope ('needs the publish scope'), the public feed implication, and refusal conditions for certain creation types. This adds significant behavioral context without contradicting any annotations.

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

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

The description is three sentences, front-loaded with the primary function, and every sentence contributes useful information. There is no redundancy or filler.

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

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

For a simple two-parameter tool with no output schema, the description covers the essential context: scope requirement, behavior, and usage constraints. It lacks explicit mention of success/error response formats, but given the simplicity and annotations, it is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the effect of the 'publish' action and the conditions for unpublish, making the action parameter's semantics clearer. However, it does not add details about creationId format 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 opens with 'Flip ONE creation's public visibility', a specific verb and resource that clearly indicates a toggle action. It further clarifies the exact effect by stating 'Publishing puts it on the 2DAI public feed', which distinguishes this from other creation management 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 explicit usage guidance: 'Publish only when the user explicitly asked' sets a clear condition for publishing, and 'Unpublish always works on a public row' clarifies when unpublish is appropriate. It also notes platform refusals for raw uploads and NSFW-flagged creations, offering practical constraints.

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

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

The description discloses significant behavioral traits beyond annotations: moderation pass, NSFW rejection, 10 MB max, supported formats, and path restrictions. It also notes the free nature. Annotations only mark side effects and open-world, so this adds substantial value.

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

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

The description is three sentences, front-loaded with the core purpose, followed by constraints. Every sentence provides useful information, no fluff.

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 7 parameters and no output schema, the description covers the main use case, constraints, and acceptance criteria. It does not explain the alpha edit params, but the schema already describes those. Overall adequate.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds file-level constraints not in the schema (max size, formats) and clarifies the two input modes (path vs. base64). This supplements the schema without redundancy.

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 ('Upload a local image... to the 2DAI cloud drive') and its purpose ('so it can be used as a reference for generation'), with a specific verb and resource. This distinguishes it from sibling generation 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?

Describes when to use the tool (to upload images for reference in generation) and provides implicit constraints (e.g., path restrictions, moderation). It does not explicitly name alternatives or exclusions, but the context is sufficiently clear.

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