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

Beyond the annotations (readOnlyHint=false, idempotentHint=false, etc.), the description discloses critical behavioral traits: synchronous execution, 30s gateway cutoff, 504 timeout behavior where the request still completes and bills, automatic refunds for failed requests, and unsupported OpenAI parameters. This adds significant value and gives the agent a realistic model of the tool's side effects and failure modes.

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

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

The description is front-loaded with purpose and the most critical behavioral caveat (synchronous, 30s limit). The Args section does repeat some schema constraints (types, ranges), but each repetition often carries added context (e.g., 'keep modest' for max_tokens). It is somewhat long but every section serves a purpose; still, a slightly tighter version could omit the redundant parameter constraints.

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 8 parameters, no output schema, and non-trivial runtime behavior, this description is thorough. It covers invocation, billing, error recovery, unsupported parameters, and practical usage constraints. The agent has enough context to select the tool, set parameters sensibly, and handle timeouts without needing additional lookup.

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 extra meaning beyond the schema: it notes that max_tokens includes reasoning tokens, that server default reasoning_effort is 'none (fastest)', and explicitly lists unsupported OpenAI parameters (tools, stop, etc.). This enriches parameter understanding beyond raw 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 description clearly states the tool's function: 'Chat with an XBrush-hosted LLM (OpenAI-compatible chat completions)'. It uses a specific verb and resource, and the focus on chat completions distinguishes it from the many image/video/audio generation siblings. The 'SYNCHRONOUS' note further differentiates it from request-based 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 strong contextual guidance: it explicitly states this is synchronous with no polling needed, warns about the ~30s gateway limit, and advises on reasoning_effort and max_tokens. It also directs users to xbrush_list_models for model selection and mentions using xbrush_list_requests/get_request for timeout recovery. It does not explicitly name alternative chat tools because none exist among siblings, so exclusion guidance is less critical.

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

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

Annotations already declare read-only, idempotent, and non-destructive hints, and the description adds no further behavioral context. It does not describe what 'health status' means or what the response will look like, but for a simple health check, the transparency is minimal yet not misleading.

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, front-loaded sentence with no redundant words. It precisely conveys the tool's purpose without wasting any space.

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

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

For a very simple tool with no parameters and no output schema, the description is mostly complete, but it does not elaborate on what 'health status' includes or how the response is structured. Given the minimal complexity, this is a minor gap.

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

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

The tool has zero parameters, and the schema is empty with 100% coverage. The baseline for zero parameters is 4, and the description does not need to add parameter information. It correctly avoids inventing 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 clearly states the tool checks the XBrush API server health status, using a specific verb and resource. It uniquely identifies the tool among siblings, as no other sibling is concerned with health checks.

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

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

The description implies usage by naming the action, but it does not explicitly state when to use it or mention any alternatives or exclusions. Since there are no sibling tools for health checks, the lack of explicit alternatives is not penalized heavily, but some guidance is absent.

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

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

The description discloses async behavior, the nature of the result (flagged verdict, overall score, processed copy with masked unsafe regions), and the requirement to poll with the returned request_id. These go beyond the annotations and give a clear picture of the tool's behavior without contradiction.

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 tightly written, front-loaded with the purpose, and each sentence provides essential information (purpose, output, async note, args). No wasted words, 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?

The description covers purpose, parameters, async behavior, expected output, and polling mechanism. With no output schema, it adequately explains return values, making it complete for an agent to select and invoke the tool effectively.

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 input schema is empty, the description fully documents the two parameters (image_url, video_url) with types and the requirement to provide exactly one. This adds crucial meaning where the schema is silent, earning full credit.

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 'Run NSFW moderation on an image or video' with a specific verb and resource, and it distinguishes the tool from siblings by being the only moderation tool. It also explicitly describes the output, making its purpose unambiguous.

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

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

The description provides explicit usage context: it notes the asynchronous submission and instructs to poll with `xbrush_get_request`. It also includes the constraint to provide exactly one of image_url or video_url, which is clear guidance on how to invoke 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 enriches beyond annotations by detailing upload strategies (auto/direct/presign), size thresholds (<10MB), endpoints (/v1/files/upload, presigned S3), and supported formats. This provides deep behavioral insight, especially since annotations only indicate basic safety hints.

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 well-structured with a clear opening purpose, usage note, supported formats list, and parameter details. Every sentence serves a purpose, and it is concise without unnecessary 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?

Despite no output schema, the description states that the tool returns a URL and how to use it. It covers parameter semantics, format support, internal strategy details, and usage context, making the tool fully understandable without needing to inspect schema or annotations.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful detail for the strategy parameter by explaining the behavior and trade-offs of each enum value (e.g., 'auto: small files go via direct upload, larger via presigned S3'). This goes beyond the schema's enum list.

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 uploads a local file to XBrush CDN and returns a URL, with specific verb and resource. It also explains the purpose of the returned URL in other XBrush tools, distinguishing it from sibling tools that generate or process media.

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 indicates when to use the tool ('Upload a local file ... Use the returned CDN URL as image_url or video_url in other XBrush tools'), providing clear context. It does not explicitly mention alternatives or when not to use it, but the context is sufficient for an upload utility.

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 non-destructive behavior, so the bar is lower. The description adds the async-operation context, which is useful, but it doesn't disclose behaviors like response format, error handling for unknown request IDs, or whether it polls or returns immediately. This goes slightly beyond annotations but not by much.

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 brief and front-loaded with the purpose, followed by a clear usage note. The 'Args:' section is redundant with the schema, but it doesn't bloat the description. Overall, it is concise and easy to scan.

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

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

With no output schema, the description should clarify what 'status and result' means in terms of return value. It doesn't describe the structure or possible states (e.g., pending, completed, error), which is a gap for an async polling tool. However, the tool is simple and the annotations cover safety, so the description is minimally adequate but not 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%, with the parameter already described as 'Request ID (starts with 'req', 24 characters)'. The description repeats this requirement ('starts with 'req'') without adding new meaning. Baseline 3 is appropriate since the schema handles parameter documentation.

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 ('Get') and resource ('status and result of an XBrush API request'), making the tool's function clear. It also distinguishes it from sibling tools by noting it checks async operations like image edit and video generate, which differentiates it from list_requests or 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?

The description explicitly states to use this tool to check the result of async operations, providing clear context. It doesn't explicitly mention alternatives like list_requests, but the use case is well-defined and implies 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?

Beyond the annotations, the description discloses the async submission and polling mechanism: 'Submits async — poll the returned request_id with xbrush_get_request.' It also reveals model-specific behavior such as resolution-based models ignoring width/height and raising errors, the custom aspect_ratio exception, and the exact image_urls ordering passed to the model. 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 front-loaded with the core purpose and uses a clear Args list plus notes. It is long, but the tool has 13 parameters and many conditional behaviors; nearly every sentence carries useful information. Minor redundancy with the input schema prevents a perfect score.

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, 13-parameter tool with no output schema, the description is remarkably complete: it covers async behavior, model categories, parameter semantics, model-specific constraints, reference-image ordering, and return value (request_id). An agent could correctly invoke this tool without 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?

Even though schema coverage is 100%, the description adds substantial meaning: it partitions models into inpaint/outpaint categories, explains that mask white=edit and black=preserve, clarifies when width/height are used or ignored, defines the 'custom' aspect-ratio behavior with exact pixel constraints, and scopes quality to gpt-image-2-edit only. This goes far beyond the schema's property 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 opens with a specific verb+resource statement: 'Edit an image with text instructions.' It immediately distinguishes inpainting vs outpainting, and explicitly notes there is no separate outpaint tool, clearly differentiating from image generation, upscaling, and background-removal 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 explicit when-to-use guidance: 'For inpainting use an edit model; for outpainting (extending the canvas) use an outpaint model — there is no separate outpaint tool.' It also directs users to xbrush_list_models(category='image') for model selection and explains multi-reference usage, covering both alternatives and prerequisites.

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

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

The description discloses the asynchronous submission behavior, the need to poll the returned request_id, and detailed model-specific behaviors including error conditions ('passing them returns an error') and the exact-size exception for aspect_ratio:'custom'. Annotations provide only basic hints (readOnlyHint=false, etc.), so this context is valuable beyond what annotations offer.

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

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

The description is front-loaded with a clear one-line purpose, followed by an async note and a structured argument list. It is long but every section covers distinct parameter semantics or model-specific interactions; the bullet list improves scannability. Minor redundancy with schema descriptions keeps it from being maximally concise.

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 all arguments, model families, default behavior, error conditions, and the follow-up polling mechanism via xbrush_get_request. It also provides concrete examples for the most complex parameter (aspect_ratio), making it exceptionally complete for correct invocation.

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

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

Although the schema covers 100% of parameters, the description adds meaningful semantics by grouping models into megapixel-based vs resolution-based, clarifying which parameters apply to which model types, and explaining the special 'custom' aspect_ratio behavior with a concrete example. This substantially aids correct parameter selection 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 opens with 'Generate images from a text prompt using XBrush AI models,' clearly identifying the operation and resource. However, it does not explicitly differentiate from siblings like xbrush_image_edit or xbrush_image_upscale, relying on the tool name and phrase 'from a text prompt' for implicit distinction.

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 (text-to-image generation, async flow with xbrush_get_request) and points to xbrush_list_models for model selection, but it never states when to prefer this tool over alternatives or when not to use it. Usage is implied rather than explicitly guided.

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 the async behavior and the need to poll with xbrush_get_request, adding context beyond the annotations. It does not mention side effects or permissions, but the annotations already indicate non-read-only and non-destructive characteristics.

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 remarkably concise, with three short sentences covering purpose, async behavior, and parameter. Every sentence earns its place and the structure is front-loaded with the primary 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?

For a single-parameter tool with no output schema, the description effectively communicates how to invoke it and what to do with the result (poll with request_id). It could be more complete with an example or edge-case note, but it is sufficient for correct invocation.

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

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

The schema already fully describes the only parameter (image_url) with a URI format and clear description. The description repeats this information without adding new meaning, so it meets the baseline for high schema coverage.

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 'Remove the background from an image' with a specific verb and resource, distinctly separating it from siblings like xbrush_image_upscale or xbrush_image_edit.

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

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

It provides clear context by noting the async submission and polling requirement, which is essential for correct usage. It does not explicitly mention when not to use it or alternatives, but the context is unambiguous.

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

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

The description reveals the tool's asynchronous nature and the need to poll for the result, information not present in the annotations. This is key behavioral context beyond the readOnly/destructive hints, though it could mention failure or polling specifics.

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 short, high-signal sentences: purpose, async note, and args. No filler or redundancy; all content 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 simple async tool, the description covers the essential usage loop: call, receive request_id, poll. It lacks response structure or error details, but that is handled by xbrush_get_request. The description is sufficiently complete given the tool's simplicity and sibling relations.

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 fully describes both parameters with constraints and defaults. The description's Arg list repeats this information without adding new meaning, so it neither improves nor harms 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 opens with 'Upscale an image to higher resolution,' a clear verb+resource+outcome statement. It also notes async submission, which distinguishes it from synchronous sibling tools like xbrush_image_generate and xbrush_image_edit.

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 workflow guidance ('Submits async — poll the returned request_id with xbrush_get_request'), implying how to use the tool. However, it does not name alternative tools or state when not to use this tool, leaving the usage context partially implied.

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

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

Annotations already declare read-only, idempotent, non-destructive, and open-world behavior. The description adds useful context about the content: models include pricing, video i2v duration constraints, and the watermark exception. This goes beyond the structured 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 well-structured with a clear opening statement, a compact enumeration of model categories, specific notes about video constraint fields and watermark behavior, and a brief arg summary. It is slightly redundant with the schema in the Args section but remains appropriately sized.

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?

Without an output schema, the description compensates by mentioning pricing info, model categories, video duration constraints, and the watermark exclusion. It gives enough context for the agent to understand what will be returned. Minor gap: it doesn't specify exact response structure or pagination, but that's acceptable for a simple list 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 input schema already provides a full description of the category parameter, including the valid enum values and the meaning of omission. The description's Args section merely repeats the schema's coverage, adding no new semantic value. Baseline 3 is appropriate since schema coverage is 100%.

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 lists available XBrush AI models with pricing info, using a specific verb and resource. It distinguishes itself from sibling tools like list_voices and the various generation tools by focusing on model metadata rather than execution.

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 includes explicit guidance: it notes that watermark models have no dedicated list and should be called directly, providing a when-not usage. It also implies the tool is for discovering models before invoking generation/chat calls, and the category filter offers a way to narrow results.

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

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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds behavioral context beyond these annotations: it emphasizes 'recent' (implying temporal ordering) and includes pagination via a cursor, which are useful behavioral traits. It does not detail rate limits or response format, but that is partially mitigated by 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?

The description is concise and front-loaded with the primary purpose, followed by a clear args list. It contains no redundant or verbose phrases, and every sentence serves a purpose.

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

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

For a simple list tool with optional parameters and strong annotations, the description is fully adequate. It explains the returned content (status and results), pagination via cursor, and the default/range for limit. No output schema exists, but the description covers the essential details needed to invoke the tool successfully.

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

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

Schema description coverage is 100%, so the schema already fully documents both parameters. The description's parameter section merely repeats the schema's descriptions (limit and cursor) without adding extra meaning, such as how the cursor is obtained or what happens if the limit is exceeded.

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 lists recent XBrush API requests with status and results. The verb 'list' and resource 'requests' are specific, and it distinguishes itself from sibling xbrush_get_request by focusing on a collection of recent requests.

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

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

The description implies usage for listing recent requests but does not explicitly mention when to use this tool instead of alternatives like xbrush_get_request or how to handle pagination pitfalls. There is no explicit exclusion or comparison with sibling tools, so guidance is only implied.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful context: the returned voice_id feeds into xbrush_tts_generate, and omitting model uses the default provider. 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 short and front-loaded with the primary purpose. The Args block is somewhat redundant with the schema but keeps information inline for quick reading. Overall it is appropriately sized and well organized.

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 is simple with one optional parameter and no output schema. The description covers the main usage pattern and integration with xbrush_tts_generate. It does not detail the return format, but that is not critical given the tool's low complexity.

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

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

Schema description coverage is 100%, so the model parameter is already well documented with examples and a reference to xbrush_list_models. The description's Args section mostly repeats the schema and adds no new semantic meaning beyond restating optional behavior.

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

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

The description clearly states the tool lists voices for text-to-speech, optionally filtered by model/provider. It differentiates from sibling tools by explicitly mentioning TTS and linking to xbrush_tts_generate. The verb 'list' and resource 'voices' are specific.

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 tells the agent when to use the tool (to select a voice_id for xbrush_tts_generate) and how to optionally filter by model. It does not explicitly mention exclusions or when to prefer alternatives like xbrush_list_models, but the context is clear.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, and the description adds critical non-obvious behavioral context: the operation is asynchronous, typically takes tens of seconds to minutes, and must be polled. 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 concise and well-structured: a clear first line, a short async guidance note, and a neat Args list. It is slightly redundant with the schema, but it remains scannable and front-loaded.

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

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

With no output schema, the description should specify what the initial call returns (e.g., a request ID) to enable polling. It only says 'Poll with xbrush_get_request' without stating the response shape, which is a notable gap. All parameters and the async flow are otherwise covered.

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 5 parameters with complete descriptions, so the Args block in the description largely restates what the schema already provides. The description adds no new semantic detail beyond the schema's existing examples and bounds.

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 'Generate' and resource 'music' with model examples (lyria2, lyria3, lyria3-pro). This clearly distinguishes it from sibling tools like xbrush_sound_effect_generate, xbrush_image_generate, and xbrush_video_generate.

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 communicates the async workflow and points to xbrush_get_request for polling. It does not explicitly rule out alternatives (e.g., when to use sound effects vs music), but the scope is evident from the purpose line.

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 the async submission behavior and the need to poll for results, which annotations don't convey. It also clarifies the surprising constraint that video_url is required even for text-driven models. It doesn't mention rate limits or side effects, but given the annotations (readOnlyHint=false, destructiveHint=false), the behavioral disclosure is sufficient.

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

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

The description is well-organized: a one-sentence purpose, followed by key distinctions, async workflow, and a compact Args list. It is front-loaded with the most critical info and every sentence contributes useful guidance without padding.

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

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

For a 4-parameter async generation tool with no output schema, the description covers the essential operational context: model selection guidance, required video_url constraint, async polling flow, and duration limits. It is complete enough for an agent to invoke and follow up 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 the schema itself includes detailed descriptions for all parameters. The description's Args section largely mirrors the schema, adding only the emphasis that video_url is required for all models. Since the schema already carries the semantic load, the description adds marginal value, warranting 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 opens with a specific verb+resource: 'Generate foley / ambient sound effects for a given video.' This clearly states what the tool does and distinguishes it from sibling tools like image generation, TTS, or music generation. It further clarifies model subtypes (video-driven vs text-driven), making the purpose unambiguous.

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

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

Usage guidance is explicit: it explains that video_url is required for every model, describes when to use text-driven vs video-driven models, and instructs the caller to poll xbrush_get_request with the returned request_id. This gives clear when-to-use and next-step context, going beyond simple 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?

The description discloses a key behavioral trait—'Submits async—poll the returned request_id with xbrush_get_request'—which adds value beyond the annotations. It also notes model-specific requirements. However, it doesn't detail what happens on failure or whether partial output exists, though the annotations already cover readOnly/destructive/idempotent hints. 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, well-structured, and front-loaded with the core purpose. It uses a short intro followed by clearly labeled argument bullets. Every sentence adds useful information without redundancy or filler, making it easy to scan.

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

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

The description provides complete context for a tool with no output schema: it names all parameters, explains conditional requirements, and tells the agent how to follow up (xbrush_get_request). The async nature and model-specific voice_id needs are covered. No output schema exists, so the tool adequately guides the agent through the full invocation flow.

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 description largely repeats the same parameter details already present in the input schema (e.g., voice_id requirements, default speed range, model examples). It consolidates the information readable but does not add significant new meaning beyond the structured schema definitions. Baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Generate speech audio from text using an XBrush TTS model.' This is a specific verb+resource combination that also distinguishes this text-to-speech tool from sibling tools like image, video, music, and sound effect generation. The model family details reinforce the tool's unique 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?

Usage guidance is explicit: it distinguishes when a voice_id is required (Minimax models) versus not (ElevenLabs), directs users to xbrush_list_voices for obtaining a voice, and explains the asynchronous workflow with 'poll the returned request_id with xbrush_get_request.' This provides clear when-to-use and prerequisite context beyond mere tool naming.

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 context beyond the annotations: it discloses the asynchronous nature and the polling mechanism, which is critical for the agent. It also states the effect ('generating additional seconds of motion'), consistent with readOnlyHint=false. The description complements 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?

The description is concise and well-structured: a one-sentence purpose, a one-sentence async note, and a compact argument list. Every sentence earns its place, with no redundancy or 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?

The description is complete for a tool with three required parameters and no output schema. It explains the async workflow and explicitly directs the agent to xbrush_get_request for polling, which is essential. The model-selection hint and duration range cover the key usage details. Given the moderate complexity, nothing critical is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description repeats the parameter details but adds marginal value with example model names and a direct pointer to xbrush_list_models. Since the schema already documents ranges and formats, the description does not significantly enhance 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: 'Extend an existing video by generating additional seconds of motion.' This uses a specific verb ('extend') and resource ('existing video'), and the scope is well-defined. It naturally distinguishes from siblings like xbrush_video_generate, xbrush_video_upscale, and xbrush_video_retake.

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 by noting that the tool 'Submits async — poll the returned request_id with xbrush_get_request,' which tells the agent what to do after invocation. It also gives model selection guidance via 'See xbrush_list_models(category='video'), featureType 'extend'.' However, it does not explicitly contrast with alternatives like video_generate or video_upscale, so it lacks explicit when-not-to-use guidance.

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

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

Annotations already indicate a write operation, but the description adds substantial behavioral detail: async execution, typical 2-10 minute wait, server-validated per-model constraints, ignored parameters for unsupported models, and the translation behavior for non-English text. This goes well beyond 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?

The description is front-loaded with the core purpose and async behavior before the Args block. It is long but justified by 12 parameters and complex reference-image semantics; every sentence contributes, though there is some redundancy with the schema descriptions.

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 and the absence of an output schema, the description covers all necessary invocation context: return of request_id, polling workflow, model selection, prompt/idea requirements, reference-image numbering, and model-specific parameter validation. It is sufficiently complete for an agent to select and call the tool correctly.

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

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

Input schema coverage is 100%, and the description reinforces semantics with clarifying examples like the @ImageN numbering rule and the [last_frame, reference_image] -> @Image2 case. It also explains model-specific duration and resolution ranges. It does not quite reach 5 because much of the parameter text mirrors the schema's own 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 opens with a specific verb+resource: 'Generate a video from a start image, a text prompt, and/or reference images (reference-to-video).' It clearly defines the tool's scope and differentiates it from siblings like video_upscale, video_extend, and video_retake by emphasizing generation from inputs rather than post-processing.

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?

Provides clear context for when to use this tool: async submission, polling with xbrush_get_request, model selection via xbrush_list_models, and the distinction between prompt (English) and idea (non-English). It stops short of explicitly naming alternative tools or excluding them, so it misses 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 crucial behavioral traits not captured by the generic annotations: 'Submits async — lip-sync generation can take 30s to several minutes' and directs users to poll with xbrush_get_request. It also surfaces model-specific input requirements and resolution cost implications, adding real operational 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 introductory paragraph is tightly written and front-loads the core purpose and async behavior. However, the following Args block repeats the input schema's property descriptions almost verbatim for all eight parameters, making the overall description longer than necessary despite being well-organized.

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 eight parameters, multiple input alternatives, and asynchronous behavior, the description covers a great deal: input modes, speech sources, polling, cost tiers, and model-specific caveats. It stops short of stating explicit mutual-exclusion rules (e.g., 'exactly one of video_url/image_url required') and omits any output/return format, though the lack of an output schema lowers that burden.

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

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

Schema description coverage is 100%, and the schema already describes each parameter in detail, including the video/image OR constraint and model groupings. The Args section in the description largely duplicates these schema descriptions, contributing little new parameter-level meaning beyond the minor note that required inputs are model-specific.

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 'Sync a face to speech' and immediately distinguishes the two input modes: face video (pixverse-lipsync, infinite-talk) vs. still portrait (fabric-1.0/-fast). It also names speech sources (audio_url or built-in TTS), making the tool's scope unmistakable and distinct from siblings like xbrush_video_generate or xbrush_tts_generate.

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 guidance by explaining the video vs. photo branches, the audio vs. TTS branches, and the model-specific input requirements. It also advises polling with xbrush_get_request. However, it does not explicitly mention alternative sibling tools or state when not to use this tool, so it lacks full exclusion guidance.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the mutation is expected. The description adds valuable behavioral context by stating 'Submits async — poll the returned request_id with xbrush_get_request,' which is essential for the agent to know the tool is non-blocking and how to retrieve the result.

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

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

The description is concise and well-structured: a one-sentence purpose, a brief async note, and a clean Args list. Every sentence earns its place, and the most important operational detail (async + request_id) 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?

Given there is no output schema, the description does enough by mentioning the returned request_id and how to poll. It covers all three parameters and the async behavior. It could add what the final output will look like, but the pointer to xbrush_get_request sufficiently bridges that 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 has 100% description coverage, so the description adds little beyond what the schema already states. It does provide a concrete model example (ltx-2.3-retake) and points to xbrush_list_models, but this is also present in the schema. There is no significant extra meaning added.

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: 'Regenerate (retake) a video up to a given timestamp, producing a new variation.' It specifies the resource (video) and the operation (retake), and the timestamp constraint distinguishes it from related video tools like generate, extend, or upscale.

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 for use: you retake a video up to a given timestamp, and it explicitly notes the async workflow with xbrush_get_request. It also points to xbrush_list_models for selecting the right model, but it does not explicitly list exclusions or tell when not to use this tool versus alternatives.

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

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

The description reveals a key behavioral trait: 'Submits async — poll the returned request_id with xbrush_get_request.' This goes beyond the annotations (which only indicate non-read-only, non-destructive, open-world) by explaining the asynchronous workflow and how to retrieve results. This is meaningful behavioral context not present in the schema or 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 extremely concise: one purpose sentence, one async note, and a compact Args list. Every sentence is informative, no filler, and front-loaded with the main purpose. This is an ideal length and structure for agent consumption.

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

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

The description covers the main workflow (submit async, poll with xbrush_get_request) and all required parameters are explained. It doesn't mention limitations like supported video formats or file size constraints, but for a simple 3-parameter tool with annotations and a complete schema, it provides enough context for an agent 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 the baseline is 3. The description repeats the parameter details (e.g., 'scale (int, required): Upscale multiplier (2 or 4)') but adds no new semantics beyond what the schema already provides. It doesn't clarify format requirements or edge cases that the schema doesn't cover.

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 'Upscale a video to higher resolution' with a specific verb and resource. It clearly distinguishes this tool from siblings like xbrush_image_upscale and video generation tools by focusing on video upscaling, and the async mention further clarifies its specific role.

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

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

The description gives a clear usage context: 'Upscale a video to higher resolution' and instructs to 'poll the returned request_id with xbrush_get_request', which is actionable. However, it doesn't explicitly state when not to use this tool versus alternatives like xbrush_video_generate, though the resource (video vs image) and action (upscale vs generate) make it implicit.

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

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

Annotations already indicate a non-read, non-destructive operation. The description adds valuable transparency by specifying the async submission behavior, that the watermark content is server-fixed, and that the response yields a request_id for polling. It does not detail side effects (e.g., whether the original is modified) but covers the key operational traits.

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

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

The description is concise and well-structured: a single purpose statement, two clarifying constraints, and a clean parameter list. Every sentence adds value 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 tool with two parameters, the description covers the async workflow, the request_id polling mechanism, and the param requirement. It does not explicitly describe the result format, but given the async pattern and the presence of a polling tool, this is sufficient for an agent to invoke and follow up.

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 is empty, so the description is the sole source of parameter information. It clearly defines image_url and video_url with types, optionality, and the critical constraint that exactly one is required. This fully compensates for the schema gap.

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

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

The description clearly states the specific operation: 'Apply the XBrush watermark to a target image or video.' This uses a strong verb ('apply') and explicit resources (image/video), making it distinct from sibling tools like generate, upscale, or remove_bg.

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?

Provides usage context by explaining the async workflow ('poll the returned request_id with xbrush_get_request') and the limitation that the watermark is fixed with no customization, implicitly guiding against use for custom watermark needs. However, it does not explicitly contrast with alternatives or state when to prefer this tool over others.

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