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

Annotations already indicate this is a mutating, non-destructive, idempotent operation. The description adds useful behavioral context beyond those hints: it only applies to in-flight generations and its purpose is to stop credit consumption. No contradiction with annotations is present.

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

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

Two short sentences deliver the core action immediately and then provide the key use case. There is no redundant or filler content, and the most critical information is front-loaded.

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

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

This is a simple one-parameter tool with no output schema and complete schema documentation. The description, combined with the annotations, gives an agent everything needed to invoke it correctly and understand its effect.

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 has 100% coverage for the single parameter generation_id, with a clear description. The tool description does not add extra meaning beyond the schema, but the schema itself is sufficient, 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 states a specific verb ('Cancel'), a specific resource ('an in-flight generation'), and clarifies the scope ('in-flight') so it is distinct from deleting a completed or stored generation. This clearly differentiates it from sibling tools like dare_delete_generation.

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

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

The description explicitly says when to use it: when a job was started by mistake and to stop credit consumption. It does not explicitly state when not to use it or mention alternatives like delete_generation, but the 'in-flight' qualifier provides a clear context boundary.

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 destructiveHint=true and readOnlyHint=false, and the description adds meaningful behavior beyond that: deletion also removes the output, is irreversible, requires confirmation, and has financial consequences ('Does not refund credits'). This strongly helps the agent understand the full impact of the operation.

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

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

The description is compact and front-loaded: it states the action and resource first, then delivers critical cautions. Every sentence earns its place 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?

For a one-parameter, no-output-schema tool, this description is complete. It covers what is deleted, the destructive nature, the need for confirmation, and the credit policy, leaving no critical operational gap.

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

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

Schema description coverage is 100%, and the only parameter generation_id is already described as 'Generation id to delete.' The tool description adds no additional parameter meaning, which is acceptable because the schema fully covers 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 uses a specific verb ('delete') and identifies the exact resource ('a generation and its output from the Dare library'). It clearly distinguishes this from siblings like get, list, and cancel by emphasizing permanence.

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 usage context: deletion is destructive, irreversible, requires user confirmation, and does not refund credits. It does not explicitly name alternatives such as dare_cancel_generation, but the safety guidance is strong enough for an agent to know when not to invoke it casually.

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 meaningful behavioral detail beyond the annotations: deletion is 'permanent,' 'destructive and irreversible,' and requires user confirmation. It also clarifies the important side-effect that 'generations that already used it are unaffected,' which is not visible in the annotations.

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

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

Three short sentences deliver the purpose, risk warning, and side-effect clarification without unnecessary detail. The most important information is front-loaded.

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

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

For a single-parameter deletion tool, the description covers the action, the destructive nature, the need for confirmation, and the impact on existing generations. The annotations handle safety signals, and no output schema is needed for this simple operation.

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

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

The schema already fully documents upload_id with 100% coverage, including its source from dare_upload_media or dare_list_uploads. The description does not add additional parameter-level meaning, so the baseline of 3 is appropriate.

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

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

The description clearly states the action: 'Permanently delete an uploaded reference asset from the Dare library.' This distinguishes it from siblings like dare_delete_generation and makes the resource and operation 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?

The description establishes clear context for when to use the tool: when an uploaded reference asset needs to be deleted. It also provides an important prerequisite ('confirm with the user first'), though it does not explicitly name alternatives 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?

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond these: it performs no network request and spends no credits, and operates purely with local arithmetic. This gives the agent confidence about side effects and cost implications that annotations alone do not fully 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?

The description is three tight sentences with no filler. The first sentence states the core purpose, the second discloses key behavioral traits, and the third gives concrete usage scenarios. It is front-loaded and every sentence earns its place.

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

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

For a 10-parameter tool with no output schema, the description covers the essential selection and invocation context: what the tool does, that it is offline and free, and when to use it. The main omission is the exact return format, but the tool's purpose is simple enough that the output is largely inferable, and the schema covers all parameter semantics.

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

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

Schema description coverage is 100%, so the input schema already fully documents all 10 parameters. The description adds only high-level hints like 'compare quality tiers' and 'size a batch,' which map to quality and count but do not explain parameter behavior. This meets the baseline but does not exceed 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 states a specific verb and resource: 'Estimate the credit cost of a generation before running it.' It also clarifies the scope with 'Purely local arithmetic: no network request, no credits spent,' which distinguishes it from generation and balance tools. The purpose is unmistakable and well differentiated from siblings like dare_generate_video and dare_get_credit_balance.

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 when to use the tool: 'Use this to check affordability, compare quality tiers, or size a batch.' It clearly establishes that this is a pre-generation cost check. However, it does not explicitly name alternatives or state when not to use it, though the behavior makes this largely implicit.

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

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

The description goes beyond annotations by warning 'SPENDS CREDITS', which is critical behavioral information not captured in the schema or annotations. However, it does not explain the return value, asynchronous behavior, or side effects beyond credit consumption, leaving some transparency gaps.

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: it states the core action, the key cost warning, and the main use case in three short sentences. Every sentence adds value and there is no redundant filler.

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

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

The description is adequate for a straightforward generation tool, especially with a fully documented schema, but it lacks information about the expected output/result object and how to retrieve the generated image. Given the absence of an output schema, this is a meaningful gap.

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

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

The input schema already documents all 9 parameters with descriptions, and the description adds little parameter-level detail beyond listing model names. It provides useful context about the reference-frame use case but does not materially enhance parameter 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 identifies the operation ('Generate a still image on Dare'), specifies available models, and differentiates from the sibling dare_generate_video by explicitly mentioning still images and reference frames for video. This makes the tool's purpose unambiguous and distinct.

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 by stating that the tool is useful for producing a reference frame to feed into dare_generate_video, which implies a primary use case. It does not explicitly list exclusions or name alternative image tools, but the sibling list and model enum help disambiguate.

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?

Discloses the credit spend with a concrete cost estimate, the async nature of rendering, typical 5–15 minute latency, and immediate generation-id return behavior. This adds meaningful behavioral context beyond the annotations, which only mark the operation as non-read-only and non-idempotent.

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

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

Four dense, front-loaded sentences cover the core action, cost, latency/async behavior, and reference workflow with no filler. Every sentence earns its place.

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

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

For a complex, credit-spending async tool with no output schema, it covers return behavior, cost, latency, polling, and media references. The remaining parameter details are already supplied by the rich, fully described input 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 11 parameters at 100%, so the baseline is 3. The description adds useful guidance on wait_seconds (prefer 0 and poll) and reference_storage_keys workflow, and clarifies the default model. This earns a 4 but not 5 because most per-parameter semantics remain in the schema.

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

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

States the exact operation: 'Generate a video from a text prompt on Dare', with a concrete default model (Seedance 2.5). This clearly separates it from dare_generate_image and dare_get_generation.

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

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

Explicitly instructs to call dare_estimate_cost first, poll with dare_get_generation instead of blocking, and upload references with dare_upload_media before invoking. It also tells when to set wait_seconds, giving clear workflow guidance relative to sibling tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description adds context about auth scope ('signed-in account') and temporal freshness ('current'). This goes beyond the annotations without contradicting them.

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

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

Two short sentences with zero wasted words. The core action is front-loaded, followed by a safety qualifier and a practical usage tip, making the definition easy to parse.

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

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

The tool has a single optional parameter, rich annotations, and a concise description that covers what it does, when to use it, and its safety profile. There is no output schema, but the response_format parameter covers output structure, so nothing necessary for correct invocation is missing.

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

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

Schema description coverage is 100%; the response_format parameter is fully documented in the schema with its enum and a clear description. The tool description adds no additional parameter information, so the baseline of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Fetch the signed-in Dare account's current credit balance.' It clearly identifies the operation and the target, and the tool is easily distinguished from siblings like dare_estimate_cost or dare_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?

The description explicitly says when to use it: 'Use before a large batch to confirm there is enough headroom.' It provides clear context for invocation, though it does not name alternatives or exclusions, which are not really needed given the tool's unique purpose.

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

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

Annotations already carry readOnlyHint, idempotentHint, and destructiveHint=false, and the description's 'Read-only' line is consistent with them. It adds meaningful context beyond annotations: the long-running nature of video jobs, the blocking semantics of wait_seconds, and the notion of terminal statuses. It does not disclose edge behavior when wait_seconds expires while a job is still pending, which keeps it from a 5.

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

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

Three sentences (~70 words) with zero filler: the opening sentence states function and return contents, the second declares read-only, and the final sentence covers when and how to poll. The most decision-relevant information (statuses, return contents, polling loop) is front-loaded.

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

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

With no output schema to explain return values, the description directly covers the return surface (status, credits, URL). Combined with the annotations' safety profile and the fully documented schema, an agent can determine whether to call, how long to wait, and how to interpret results. Minor gaps — behavior on unknown ids and on wait_seconds timeout — keep it short of a 5.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well, giving a baseline of 3. The description earns an extra point by adding client-specific sizing guidance for wait_seconds (45 for desktop apps, 300+ for Claude Code) and grounding generation_id's provenance in the dare_generate_* tools.

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

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

The description names a specific verb ('Fetch'), a specific resource ('one generation by id'), and enumerates exactly what is returned (status, credits charged, output asset URL). The 'one... by id' framing unambiguously distinguishes it from the sibling dare_list_generations without any inference.

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 anchors when to use this tool: 'Poll this after dare_generate_video,' with a concrete latency expectation (5–15 minutes) and a clear polling loop ('call again until status is terminal'). However, it never states when-not to use it or names an alternative tool for listing or other scenarios, so it falls just short of the explicit exclusion bar.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description's 'Read-only' is consistent with these. The description adds valuable behavioral context beyond the annotations: the list is newest-first and uses cursor pagination, and it includes both generations and uploads in the same listing. That goes beyond what annotations alone 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?

The description is two sentences with zero filler. It front-loads the action and scope, then immediately gives the practical use case. Every clause earns its place: ordering, pagination, read-only nature, and what to use it for.

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 three optional, well-described parameters and no output schema, the description conveys the key context: what is listed, ordering, pagination, and a concrete use case. It doesn't explicitly state the return envelope (e.g., that results include a next_cursor), but the schema's cursor parameter implies it, 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 covers all three parameters (limit, cursor, response_format) with clear descriptions, so the baseline is 3. The description mentions pagination and the general use case but adds no new parameter-level detail 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 states a specific verb ('List') and resource ('items in the Dare library — generations and uploads'), and adds important scope details: newest-first ordering and cursor pagination. Mentioning both generations and uploads distinguishes it from sibling tools like dare_list_models or dare_list_uploads, so an agent can tell them apart.

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 one clear use case ('find an earlier video's id or an upload's storage key'), which implies when the tool is useful. However, it never explicitly says when to prefer this over dare_list_uploads or dare_get_generation, nor when not to use it. The routing guidance is implied rather than stated.

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

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

Although annotations already declare readOnlyHint and idempotentHint, the description adds the important behavior that the tool 'makes no network request and spends no credits.' This goes beyond the annotations and gives the agent confidence about side-effect-free invocation.

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: first states what the tool lists, second says when to call it, third clarifies side effects. Information is front-loaded and each sentence earns its place with no 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 read-only list tool with fully documented parameters and safety annotations, the description is complete. It conveys the output contents, provides usage context, and discloses cost/network behavior; no output schema exists, but the description covers what an agent needs to know.

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

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

Schema description coverage is 100%, and both parameters already have clear enum constraints and descriptions. The tool description adds no parameter-specific meaning, but it does not need to because the schema fully documents kind and response_format.

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

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

The description states a specific verb ('List') and resource ('video and image models available on Dare'), plus the key attributes returned: durations, aspect ratios, quality tiers, and reference limits. This clearly distinguishes it from sibling tools like dare_estimate_cost or dare_generate_video.

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

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

It explicitly says to call this before generating so parameters are valid for the chosen model, and points to dare_estimate_cost for prices. This gives an agent concrete when-to-use guidance and names the relevant alternative tool.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds useful context beyond those: projects are scoped to the account and are intended for filing generations under a project id. It is consistent with the annotations and adds 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 a single, tight sentence that leads with the action and resource, then states the purpose and read-only nature. No wasted words.

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 zero required parameters, a complete schema, and strong annotations, the description provides everything an agent needs: what it lists, the account scope, the purpose, and the safe read-only behavior.

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%; the only parameter, response_format, has a full description, enum, and default in the schema. The description adds no parameter-level detail, but none is needed because the schema is complete.

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

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

The description uses a specific verb and resource: 'List the account's Dare projects'. It also states the intended use ('for filing generations under a project id'), which clearly distinguishes it from sibling list tools like dare_list_models, dare_list_generations, and dare_list_uploads.

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: use this tool when you need a project id to file generations. It does not explicitly name alternatives or state when not to use it, but the resource and purpose make the appropriate use case evident.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces the read-only nature. It also adds the 'cursor-paginated' behavior, which is not present in the annotations and is valuable for an agent to understand pagination semantics.

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 that front-loads the action and object, then covers the two most important behavioral traits (read-only and cursor-paginated). There is no wasted wording or redundant restating of the title.

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

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

For a simple optional-parameter list tool with rich annotations, the description provides the essential context: what is listed, that it is read-only, and how pagination behaves. It doesn't spell out the exact response format, but the response_format parameter and the mention of storage keys give enough guidance for calling the tool correctly.

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

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

Schema description coverage is 100%, so the parameters (limit, cursor, response_format) are already well-documented in the input schema. The description does not add parameter-specific meaning, which is acceptable given the high coverage; the baseline of 3 applies.

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

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

The description opens with a specific verb ('List') and resource ('previously uploaded reference media'), and adds the key output detail ('with their storage keys'). The scope is clear and it is easily distinguishable from sibling tools like dare_list_generations, dare_list_models, and dare_list_projects merely by the resource type.

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 usage context: call this when you need to see previously uploaded reference media. However, it does not explicitly state when to choose this over alternatives or name any exclusions, so the guidance is only implied rather than directly stated.

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

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

Annotations already convey the mutation profile (readOnlyHint=false, not idempotent, not destructive). The description adds meaningful non-schema context: 'Spends no credits' and 'returns its storage key.' It does not detail persistence or failure behavior, but the annotation coverage lowers the burden, and what is disclosed is relevant.

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

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

Two tight sentences front-load the purpose, then cover accepted inputs and cost. There is no filler or duplication of schema details that are already present.

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

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

With no output schema, the description correctly explains the return value (storage key) and its downstream use. The main gap is that although it says 'a local file path, a public URL, or base64 bytes,' it does not explicitly state that at least one of these is required, which is important given the schema lists zero required parameters.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents all six parameters. The description adds a useful summary of the three source options (file_path, url, base64) but does not significantly extend the schema's meaning for individual parameters.

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

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

The description uses a specific verb and resource ('Upload an image, video or audio file to Dare'), states the concrete output ('return its storage key'), and connects the tool to its downstream consumers ('dare_generate_video or dare_generate_image'). This clearly distinguishes it from sibling tools like list/delete uploads.

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 explains the intended context: uploading reference media to be used in generation tools. It also names the accepted input forms. It does not explicitly mention when not to use it or alternatives, but among the siblings there is no competing upload tool, so the guidance is sufficient.

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