Retro Diffusion Pixel Art MCP

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which effectively communicate the tool's behavioral traits. The description adds the context of using a public API key, which is consistent 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 a single, front-loaded sentence of 10 words. Every word is meaningful, with no extraneous information.

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

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

Given the simple nature of the tool and the comprehensive parameter description in the schema, the description is largely complete. The output schema (not shown) likely provides success/error details. Some context about when authentication is needed could improve completeness, but it is adequate.

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

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

The input schema has 100% descriptive coverage for the single parameter 'api_key', specifying its format and creation URL. The tool description does not add further semantic meaning, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action 'Authenticate' and the resource 'this MCP session' with a RetroDiffusion public API key. It distinguishes the tool from its sibling 'logout' by being the opposite operation.

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

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

The description implies the tool should be used to authenticate a session but does not explicitly state when to use it (e.g., before other tools) or provide guidance on alternatives. The parameter description hints at key creation but no direct usage context.

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

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

Annotations declare non-readonly, non-idempotent, openWorld, non-destructive, so the safety profile is largely covered. The description adds genuine behavioral context beyond that — the response excludes raw base64 payloads, animation failures auto-refund and are worth one identical retry, and reference_images only work where supports_reference_images is true. Auth (rd_api_key) is handled in the schema, not the description, so it is not perfect.

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

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

Purpose is front-loaded correctly, but the body is a sprawling multiple-paragraph block and duplicates schema content — the 'N items = N images, never a sheet/grid' rule is repeated verbatim in both the description and the num_images schema text, and pixelate/animation routing is dense. Sizable but not tight.

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 25-parameter generation tool with an output schema and rich annotations, the description covers routing, style selection, reference-image semantics, batching, and failure/refund behavior. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real disambiguation the schema does not: input_image vs reference_images vs style_reference_images usage, the rule that reference_images guidance re-imagines rather than converts, and that prompt must never contain 'pixel art'. This meaningfully surpasses the structured fields.

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

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

States a specific verb+resource ('Generate images using the public /v2/inferences endpoint') and immediately distinguishes scope from siblings by naming the alternatives for animation (start_inference_job + get_inference_job), variant derivation (image_edit), conversion (rd_pro__pixelate), and directional views (rd_advanced_animation__rotate). An agent can route correctly without opening any schema.

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

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

Explicit when-to-use and when-not-to-use rules abound: prefer RD Pro styles for quality, use start_inference_job for animations, derive variants via image_edit rather than regenerating, use rd_pro__pixelate to convert rather than re-imagine. Alternatives are named conditionally, not merely listed.

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 flag this as a mutating (non-read-only) operation, so the descrioption does not need to restate that. It adds value by explaining that style_reference_images are baked into the custom style and are not the same as per-inference reference images, which is a non-obvious persistence behavior an agent should know before calling.

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, front-loaded, and every sentence earns its keep: it states the endpoint and resource, then highlights the key styling nuance. No fluff or redundant repetition of schema details.

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

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

Given 16 parameters, 100% schema coverage, an output schema, and annotations marking this as a mutating operation, the description provides enough orienting context. It is slightly light on how this relates to update_user_style or deletion, but those are inferable from the create verb and sibling names.

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

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

The schema has 100% parameter coverage, so the baseline is solid. The description supplements this by making the crucial distinction between style-level reference images and per-inference reference images, clarifying that the former are baked in. This adds semantic meaning beyond the schema fields, especially around the reference_image alias warnings.

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 a specific action and resource: it creates a user/custom style via /v2/tyles from the RD Pro template. It also highlights style-level reference semantics, which helps distinguish style creation from ordinary inference. It does not explicitly name a sibling alternative, but the core purpose is unmistakable.

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 concrete usage guidance by directing agents to use style_reference_images and style_reference_caption for style-level references and warning that these differ from per-inference reference_images. This effectively communicates when to use the style-reference parameters during creation. It does not list exclusions or alternative sibling tools, but the guidance is relevant and operational.

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 destructiveHint annotation: the operation is irreversible ('This cannot be undone'), preserves the rig ('The rig stays'), is free, and returns the model. This fully informs the agent about the consequences of calling the tool.

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

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

The description is concise: three short sentences, with the primary action front-loaded, followed by the most important behavioral notes. Every sentence contributes value, and there is no redundant or fluff content.

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

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

The description is sufficient for a destructive tool with full schema documentation and an output schema. It covers the action, scope, irreversibility, cost implication, and return value. It does not cover error cases like deleting a nonexistent animation, but that is not essential for selection and 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?

Schema description coverage is 100%, so the schema itself documents all four parameters. The description does not add additional parameter-level semantics beyond what the schema already provides, 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 states a specific verb ('Delete'), resource ('animation'), target container ('Low-Poly model's version'), and outcome ('return the model'). It clearly distinguishes this from sibling tools like start_lowpoly_animate or export_lowpoly_model.

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 implies when to use it: when one animation needs to be removed. However, it does not explicitly list alternatives or say when not to use it. The note about the rig staying provides helpful context but does not directly route the agent relative to other 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?

The description says 'Delete a user style,' which is a destructive mutation, while the annotations declare readOnlyHint: true. This directly contradicts the operation's semantics, so the score must be 1 per the rubric. The description adds no mitigating context about irreversibility or side effects.

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 short, front-loaded sentences with no filler: the first states the action and endpoint, the second clarifies the accepted id forms. This is appropriately sized for a simple delete operation.

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?

Although an output schema exists and the operation is simple, the readOnlyHint contradiction leaves the behavior ambiguous. The description also does not address ownership/permissions, irreversibility of deletion, or behavior when style_id is not found, so it is not complete enough for a destructive tool carrying conflicting 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 description coverage is 100%, so both style_id and rd_api_key are already documented. The description repeats the fact that style_id can be an internal id or prompt_style/public id, matching the schema description without adding new information. It meets the baseline but does not go beyond it.

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

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

The description opens with a specific verb and resource: 'Delete a user style' and identifies the exact endpoint /v2/styles/{style_id}. This clearly distinguishes the tool from siblings such as create_user_style and update_user_style without being a tautology.

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 intended use is plainly stated: use this when a user style should be removed. It gives clear context, but it does not explicitly name alternatives or exclusions, such as using update_user_style when only a modification is needed.

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

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

Annotations already mark readOnlyHint, idempotentHint, destructiveHint as false. The description adds 'Always free' and 'without running it,' which goes beyond annotations and provides useful cost transparency.

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

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

Two concise sentences that pack key info: purpose, cost, and behavior. Efficient 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?

Given 25 parameters with 100% schema coverage and annotations, the description captures the core function well. The 'Always free' note is valuable. Could mention when to use over run_edit_tool explicitly.

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

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

Schema coverage is 100% with detailed descriptions for each parameter. The description adds 'Always free' but no extra parameter info. 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 'validate an edit-tool request and estimate its cost and duration' and notes 'Always free,' distinguishing it from run_edit_tool.

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

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

Explicitly says this is for validation and estimation without running, implying use before executing. No direct sibling alternative named, but context with run_edit_tool is 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 readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds the concrete mechanism (check_cost=true against the public endpoint), implying no credits are consumed and no job is created, which is useful context beyond the annotations. It stops short of saying whether a cost value or an error is returned when the estimate fails.

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

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

It is short and front-loaded, leading with the action and the endpoint before secondary notes. The second paragraph is somewhat tangential and includes the off-schema parameter reference, but there is no padding or repetition.

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

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

With an output schema present, return values need no explanation, and all 20 parameters are documented in the schema. However, for a cost-estimation tool the description never confirms that the call is free/no-credit (only the title and annotations imply it) and gives no guidance on which sibling estimator to use, leaving coverage 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%, so the 20 parameters are already fully documented and a baseline of 3 applies. The description adds a little routing logic for input_image vs reference_images vs style_reference_images, but mentions style_reference_images, which is not present in this input schema, creating mild confusion rather than extra clarity.

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 generation cost') and names the mechanism ('the public /v2/inferences endpoint with check_cost=true'). It is clear on its own, but never distinguishes itself from the sibling estimate_edit_tool_cost or from create_inference, which an agent may be choosing between.

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

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

There is no statement of when to reach for this tool versus create_inference (the paid generation) or estimate_edit_tool_cost. The three usage hints present ('use input_image for...', 'style_reference_images only on create_user_style/update_user_style') are parameter-level guidance, not tool-selection guidance, and one of them references a parameter that does not appear in this schema.

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

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

Annotations already mark this as read-only and idempotent, and the description reinforces that by stating it does not start the job and is free. It adds valuable behavioral nuance beyond annotations: auto size returns the size that would be picked, and style only affects pricing for generate while other operations use the model's own style.

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

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

Three short sentences, with the core purpose front-loaded and no filler. Each sentence contributes either a primary function, a size edge case, or a style/pricing interaction.

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 estimator with a rich schema, an output schema, and annotations covering safety, the description covers the non-obvious behaviors an agent needs: no execution, no charge, auto-size behavior, and style/operation pricing interaction. Remaining operation and asset_id details are already in the schema.

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

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

The input schema already documents all six parameters at 100% coverage, so the baseline is 3. The description adds non-obvious semantic detail: size=auto causes the estimate to reveal the auto-selected size, and style affects only generate pricing, with Lite styles costing less and other operations ignoring style. This is meaningful added value.

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

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

The description opens with a specific verb and resource: 'Price a Low-Poly job' without starting it, clearly distinguishing this from start_lowpoly_* tools. It also highlights the special auto-size behavior for generate, differentiating the tool's purpose from generic pricing-list endpoints like get_lowpoly_pricing.

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

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

The phrase 'without starting it (free)' gives clear context: use this to estimate cost before committing to a job, not to execute one. It does not explicitly name alternatives or exclusion cases, but the context is enough to route an agent away from the start_lowpoly_* siblings.

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 useful behavioral context beyond annotations: the result is a hosted, free download URL; format depends on target; .glb and .bbmodel include all animations; GIF/sheet/MP4 exports require an animation name. This is meaningful context that helps the agent predict behavior. No contradiction with the idempotent or non-destructive 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 compact, front-loaded with the primary action and output, and every sentence carries useful information. The target format rules and animation caveat are stated efficiently without unnecessary prose.

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 rich input schema, output schema, and annotations, the description is complete enough for correct invocation. It covers the core export purpose, target-specific formats, animation behavior, and the free hosted URL, leaving no critical ambiguity for an agent to call this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all parameters well. The description adds a bit of semantic value by clarifying target-to-format mapping and animation inclusion, but most parameter meaning is already present in the schema, so the additional contribution is limited.

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 a specific action and resource: exporting a Low-Poly model and returning a hosted download URL. It also distinguishes by output format (e.g., .glb, .bbmodel, resource pack), though it does not explicitly name an alternative sibling like get_lowpoly_model.

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

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

The description implies when to use the tool: when you need an exported Low-Poly model for a specific engine or tool. It also gives practical targeting guidance (e.g., Blender gets .glb, Blockbench gets .bbmodel) and notes animation requirements, but it does not explicitly explain when to choose this over sibling tools or when not to use it.

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

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

Annotations indicate read-only, non-destructive behavior, which the description confirms by stating it 'repairs existing art—it does not generate a new image.' The description adds details beyond annotations: rate limits (10 req/min), image size limits (16 MP), response size (850KB), and URL input benefits. No contradictions. Could mention synchronous/asynchronous behavior, but overall strong.

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 paragraph of 7 sentences, starting with the core purpose. It is informative without extraneous details. Could be slightly more structured (e.g., bullet points for limits) but is efficient 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?

For a tool with 7 parameters, complete schema coverage, annotations, and an output schema, the description covers purpose, engines, input options, and important limits. It does not explain the output format, but that is reasonable given the output schema exists. Minor gaps: no mention of error handling, but overall comprehensive.

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 description's added value over the schema is minimal. It repeats that width/height are for neural engine and that input_image and image_url are mutually exclusive. This is helpful but does not provide new meaning beyond what is already in the structured fields. 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 identifies the tool's action—recovering the native pixel grid from various degraded pixel art—and distinguishes the two engines (standard and neural). It is specific and differs from sibling tools, which cover authentication, inference, style management, etc. No ambiguity.

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

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

The description explains when to use each engine and how to provide input (URL vs base64), including the rate limit. While it doesn't explicitly list alternatives or exclusions, the sibling tools are very different, making usage context clear. Missing explicit 'when not to use' keeps it from a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds only that the endpoint is 'public', which is a mild behavioral trait. It does not describe rate limits, response behavior, or auth interactions beyond that, but the annotations carry most of the safety profile.

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

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

One short sentence contains the action, the resource, and the endpoint. There is zero filler, and the most important distinguishing detail (the exact endpoint) is included without extra 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?

The tool is simple: one optional parameter, no required inputs, an output schema exists, and annotations cover the safety profile. The description's mention of the public endpoint combined with the schema and annotations is sufficient for an agent to call 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%, and the rd_api_key parameter is already fully described in the schema as optional and overriding session/header auth. The description adds no parameter-level information, so the baseline score 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 names a specific verb ('Get') and resource ('credits/balance') and pins it to the exact endpoint '/v2/inferences/credits'. This is unambiguous and, by naming the endpoint, effectively distinguishes it from other tools without needing to list 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 does not state when to use this tool versus alternatives or when not to use it. The word 'public' hints that it may not need authentication, but there is no explicit usage context or exclusion. An agent is left to infer that this is simply the balance-checking 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 and idempotentHint. Description adds valuable context about output_urls and omission of base64 payloads, enhancing transparency.

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

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

Two sentences, front-loaded with purpose, no fluff. Every sentence adds value.

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

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

Given output schema exists, description covers statuses and output details adequately. No gaps for this simple tool.

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

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

Schema coverage is 100%, and description adds helpful context for task_id (links to start_inference_job). Slight added value beyond 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?

Description clearly states it checks async job status, using specific verb and resource. Distinguishes from sibling tools like start_inference_job and list_inference_jobs.

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 links to start_inference_job and mentions statuses, but could more explicitly differentiate from list_inference_jobs for batch queries.

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

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

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces this with 'This lookup is read-only.' It adds valuable context beyond annotations: the tool returns signed output URLs and warns against unnecessary paid calls, which is a meaningful economic/behavioral nuance. No 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 three short, purposeful paragraphs: purpose, usage, and warning. Every sentence earns its place, with no filler. The front-loaded purpose makes it immediately clear what the tool does.

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 lookup tool with an output schema and strong annotations. The description covers the synchronous generation context, how to obtain the request_id, and the read-only nature. There are no significant gaps 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 coverage is 100% (both request_id and rd_api_key are documented). The description adds contextual meaning by linking request_id to create_inference's return value, clarifying the parameter's origin. This goes beyond the schema description, justifying a score above the baseline 3.

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: 'Retrieve retained outputs for a synchronous generation.' It uses a specific verb ('retrieve') and resource ('retained outputs'), and distinguishes itself from siblings like get_inference_job and create_inference by focusing on output retrieval via request_id.

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: use the request_id from create_inference to recover/refresh signed URLs. It also cautions against repeating a paid create_inference call, which is a clear anti-pattern. It doesn't explicitly contrast with alternative tools like get_inference_job, but the guidance is strong.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond these annotations: it lists observable status transitions alert the success payload contents (model, versions, render URLs, animations) and the expected polling latency. This meaningfully informs agent behavior.

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

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

The description is compact and front-loaded: the first sentence states the core purpose, the second describes success outputs, and the third gives polling instructions. Every sentence contributes distinct information with no redundancy or filler.

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

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

Given the tool's simplicity, the output schema, and rich annotations, the description covers the essential operational details: statuses, success contents, and polling frequency. The only minor gap is not clarifying how this relates to start_lowpoly_generate or how it differs from get_inference_job, but this is not critical 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?

Schema description coverage is 100%, so the input schema already documents task_id and rd_api_key adequately. The description does not add parameter-level details, but with full schema coverage 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 tool returns the status of a Low-Poly job and enumerates the possible states: pending, running, succeeded, or failed. It also says what is returned on success, which distinguishes it from sibling tools like get_inference_job or get_lowpoly_model. The verb and resource are specific and 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 explicitly gives polling guidance: 'Poll every 10-20 seconds; jobs take minutes.' This tells an agent when and how often to call the tool. It does not explicitly name alternative tools or conditions for when not to use it, but the polling context is clear and actionable.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds value beyond those annotations by indicating that the response includes status, version artifacts such as render URLs and animations, and any running job, which helps the agent anticipate the tool's output.

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 compact line with no filler and front-loads the resource before listing the salient response categories. It could be improved by using a complete sentence with a verb, but it is efficient.

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

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

For a simple read-only fetch with an output schema and fully documented parameters, the core invocation details are covered enough. The main gap is the lack of routing guidance versus get_lowpoly_job, though the schema's asset_id description partially compensates by referencing the generating job.

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%; both asset_id and rd_api_key are documented in the input schema. The description itself adds no parameter meaning, so the 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 identifies the resource (Low-Poly model) and the returned content categories: status, versions with render URLs and animations, and any running job. It does not use an explicit verb like 'retrieves' or 'returns,' but combined with the title it is clear enough to distinguish from lowpoly job-specific 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 no guidance on when to use this tool versus get_lowpoly_job, list_lowpoly_models, or start_lowpoly_generate. An agent must infer selection criteria from sibling names and the schema's asset_id provenance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the useful 'Free' cost signal but does not go further to explain whether authentication is needed or how the endpoint behaves; there is 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 extremely short and front-loads the important pricing categories before the 'Free' note; there is no filler. It is structured as fragments rather than a full sentence with an explicit verb, which slightly weakens clarity but keeps it 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 simple read-only endpoint with one optional parameter and an output schema, the key contents are listed. However, the description omits any statement of what operation the tool performs or when to choose it over the nearby estimate_lowpoly_cost and get_lowpoly_model endpoints, leaving part of the selection context to inference.

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

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

The single optional rd_api_key parameter is fully documented in the schema (100% coverage), so the description does not need to explain it. The description adds no parameter-level detail, but the baseline of 3 is appropriate because the schema carries the full burden.

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 identifies a concrete resource — Low-Poly pricing — and enumerates the specific contents (sizes, per-operation prices for generate/revise/animate, styles, limits, export targets), so an agent can tell this is the pricing/metadata endpoint. It lacks an explicit verb such as 'retrieves' or 'returns,' and it does not directly differentiate from sibling estimation tools like estimate_lowpoly_cost, stopping short of a 5.

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

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

No guidance is given on when to call this tool versus estimate_lowpoly_cost, get_balance, or the low-poly job/model getters. The only usage hint is 'Free,' which says the call itself has no cost but does not state when this endpoint is the right choice or when an alternative should be used.

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

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

Annotations already indicate read-only and idempotent behavior, and the description adds the no-auth detail and the health-check scope. No contradiction with annotations; the additional context around intended use complements 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?

One sentence conveys purpose, endpoint, auth status, and usage context with zero waste. Front-loaded with the action and resource before the context.

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 parameters and an output schema present, the description covers the essential call-time context (auth, health-check purpose). Could mention what status values are returned, but the output schema likely covers that.

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

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

The tool has zero parameters, and schema coverage is 100% (trivially). The description doesn't need to document parameters; the no-auth note and health-check context provide all needed semantics.

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

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

Description states a specific verb ('Check'), resource ('RetroDiffusion subsystem health'), path ('/v2/status'), and no-auth requirement. It clearly distinguishes this health-check tool from sibling inference/job/balance 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?

Provides usage context ('before bulk generation runs') without naming alternatives. No explicit when-not-to-use, but the context is enough for an agent to select it appropriately.

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

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

Annotations already indicate readOnly, openWorld, idempotent, non-destructive. The description adds behavioral context about what the tool explains (style expectations), going beyond annotations to clarify its role as a consultation tool.

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

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

Two sentences: first states purpose, second gives usage guidance. No superfluous words; every sentence earns its place. Front-loaded with the essential 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?

Given the presence of output schema and comprehensive annotations, the description provides all necessary context: it explains the tool's purpose and when to use it, fitting the complexity of a style usage query.

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 has 100% coverage with descriptions for both parameters. The description does not repeat param details but adds meaningful context about how the tool's output informs the usage of those parameters in create_inference, thus enhancing semantic understanding.

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

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

The description clearly states 'Explain how to use a public prompt_style', using a specific verb and resource. It distinguishes from sibling tools like 'create_inference' and 'list_available_styles' by focusing on usage explanation.

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?

Directly advises 'Use this before create_inference if you are unsure...' and lists specific scenarios (input_image, reference_images, style_reference_images). Provides explicit when-to-use guidance and implies alternative by referencing create_inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior. The description adds the endpoint path and the uniqueness/public qualifiers, but provides no further behavioral context such as authentication behavior, ordering, or open-world implications.

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

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

A single front-loaded sentence conveys the core purpose with no filler. Every word contributes meaning, and the most important information appears immediately.

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, has full parameter documentation, a complete output schema, and annotations covering safety and idempotency. The description covers what is returned and where, though it does not help an agent disambiguate between this and sibling list tools.

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

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

Schema description coverage is 100%: the only parameter, rd_api_key, is fully documented in the input schema. The description adds no parameter-level detail, so 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 uses a specific verb 'Return' and identifies the resource as 'unique public model identifiers available in /v2/styles/selector'. This clearly distinguishes it from sibling tools like list_available_styles and list_edit_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 gives no guidance on when to use this tool versus alternative list tools, and does not mention any exclusion criteria or contexts where a sibling would be more appropriate. Usage must be inferred entirely from the tool's name and endpoint.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so no safety contradiction exists. The description adds useful behavioral context by naming the exact endpoint and the metadata fields returned, which goes beyond the annotations. It does not go into details like pagination or response envelope, but the output schema likely covers that.

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 no filler. The primary action and endpoint are front-loaded, followed immediately by the practical purpose and example metadata fields. 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?

The tool has no required parameters, a complete input schema, an output schema, and annotations that clearly establish it as a safe read-only operation. The description adds endpoint and purpose context, making the tool fully understandable for an agent without any apparent missing information.

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 explains tab, model, and rd_api_key with their filtering values and defaults. The description adds overall purpose but does not enrich the meaning of individual parameters beyond what the schema provides. Therefore, the 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 uses a specific verb and resource: 'List publicly available styles from /v2/styles/selector.' It also clearly states the tool's purpose: discovering valid prompt_style values and style metadata such as require_input_image and supports_reference_images. This clearly differentiates it from sibling tools like list_available_models or style-management tools.

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

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

The description gives clear usage context: 'Use this to discover valid prompt_style values plus style metadata.' This implies the right time to call it when an agent needs style options before creating or running an inference. It does not explicitly mention alternatives or exclusions, such as not using it for user-defined styles, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds the endpoint and the fact that it lists only enabled tools with their fields, costs, and limits, which is useful but not extensive. 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?

Two sentences, both purposeful. The first sentence states the core action and endpoint, and the second adds useful context about why edit tools matter. There is no wasted text or repetition of schema details.

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

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

For a simple, read-only listing tool with a single optional parameter, an output schema, and strong annotations, the description is complete enough. It names the endpoint, the data returned, and the domain context, leaving no significant gaps for an agent to call 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?

The only parameter, rd_api_key, has full schema description coverage. The description does not need to explain the parameter, and the schema already provides its type, default, and purpose. 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 uses specific language: 'List the enabled canvas edit tools from /v2/edit/tools with their fields, costs, and limits.' This clearly identifies the verb, resource, endpoint, and what is returned, distinguishing it from sibling tools like run_edit_tool and estimate_edit_tool_cost.

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 helpful context by positioning edit tools as the recommended post-processing approach, but it does not explicitly state when to use this listing tool versus alternatives such as run_edit_tool or estimate_edit_tool_cost. Usage context is 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?

Beyond the annotations, it discloses non-obvious durability behavior: a job may be accepted even if the response was lost, and listing it here is the safe way to recover it without re-submitting. This adds real value beyond readOnly/idempotent hints and has 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?

Two concise, purpose-driven sentences followed by a useful recovery note. Every sentence contributes: the first defines the operation, the second explains why an agent might need this tool, and the sibling pointer adds actional guidance.

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 operation with an output schema and complete annotations, the description covers purpose, ordering, recovery behavior, and the next-step sibling. Nothing needed 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?

Input schema coverage is 100%, with clear descriptions for limit, status, and rd_api_key. The description itself adds little parameter-specific meaning besides confirming the list is reverse-chronological, so 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 clearly states a specific verb and resource: 'List your most recent async jobs, newest first', and includes the exact endpoint. It also distinguishes itself from the sibling get_inference_job by positioning it as the polling tool to use after this listing.

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 an explicit recovery path: when a submission response is lost before task_id arrives, use this tool instead of re-submitting to avoid double charges. It also names get_inference_job as the next step, but doesn't explicitly state when not to use this tool for single-job lookups.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds the account scoping and 'newest first' ordering, but does not disclose pagination behavior, result limits, or auth details beyond what the schema already states.

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 short sentence with no filler, and the key facts are front-loaded. It is appropriately concise for a simple list operation, though it sacrifices usage and alternative context.

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 two optional parameters, full schema coverage, and an output schema, the description supplies the essential invocation context: resource scope and ordering. It is less complete in differentiating sibling tools, but the tool name and context signals partly cover 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?

Schema description coverage is 100%, and both parameters (limit and rd_api_key) are fully documented in the input schema. The description's 'newest first' reinforces the limit semantics but adds no new parameter-level meaning.

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

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

The description names the resource ('the account's Low-Poly models') and an ordering guarantee ('newest first'), so the core action is clear. It does not explicitly contrast with sibling tools like get_lowpoly_model or list_available_models, though 'account's' gives some scope differentiation.

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

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

There is no guidance on when to use this tool versus list_available_models, get_lowpoly_model, or get_lowpoly_job. The only usage context is implicit in the phrase 'account's Low-Poly models,' with no exclusions, prerequisites, or alternative routing provided.

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

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

The description adds valuable context beyond annotations: it specifies the exact behavior of clearing the API key per session, confirming idempotency and non-destructiveness. No contradictions.

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?

Single sentence, no waste, front-loaded with the action and resource.

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

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

For a zero-parameter tool with an output schema, the description is complete and leaves no ambiguity about its function.

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?

No parameters exist; baseline 4 is appropriate. The description covers the tool's purpose sufficiently.

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 ('clear') and the specific resource ('authenticated RetroDiffusion API key' for this MCP session). It effectively distinguishes from sibling 'authenticate'.

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 ending an authenticated session but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.

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

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

Annotations establish that this is a non-read-only, non-destructive mutation. The description adds meaningful behavioral context: results are saved as a new version, the model is returned, the recolor persists across later revisions and animations, and one tool carries a per-use cost. No annotation 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?

Three sentences, all information-dense: action/result/return in the first, cost in the second, persistence in the third. The description is front-loaded and has no filler.

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

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

With 9 parameters, full schema coverage, and an output schema present, the description need not enumerate fields. It supplies the missing operational context—cost, new-version semantics, and persistence—so an agent has what it needs to call the tool correctly. It could be slightly more explicit about parameter interactions, but the schema covers the mechanics.

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 value by mapping the tool parameter to cost implications (free vs $0.01) and by emphasizing the persistence behavior that affects how version/asset parameters should be understood. It does not add syntax or format details, but the schema already covers those.

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 the exact operation ('Recolor a Low-Poly model's textures'), the output ('save the result as a new version'), and the return value ('returns the model'). This clearly distinguishes it from sibling generation, revision, animation, and export tools.

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

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

It conveys the use context—recoloring textures with image color tools—and gives practical selection guidance through the cost breakdown (free vs $0.01 for Color Style Transfer). It does not explicitly name alternative tools or exclusion criteria, so it stops short of a full when-to-use/not-to-use guide.

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 useful operational behavior beyond the annotations: per-tool pricing, the endpoint pattern, and the base64_images return format. Annotations already cover read-only/idempotent/destructive hints, so the description isn't burdened with those, and there is no 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?

Every sentence earns its place: endpoint, tool list with costs, free estimation caveat, and output format. It is compact, scannable, and 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 26-parameter tool with 100% schema coverage and an output schema, the description does not need to enumerate parameters. It covers the critical workflow (estimate before paid calls), cost, and output representation, making the definition complete enough for safe invocation.

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

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

With 100% schema coverage, the schema already documents most parameters, but the description adds cost categories attached to specific tool_id values, which helps an agent select the right tool parameter. It also notes that the edited image returns in base64, which is relevant to handling the output but not a schema parameter.

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 action and resource—'Run a canvas edit tool on an image via /v2/edit/tools/{tool_id}'—and enumerates the valid tool IDs, making the tool's job unmistakable and separating it from cost-estimation and listing siblings. The name alone is generic, but the description removes ambiguity.

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

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

It gives an explicit workflow rule: call estimate_edit_tool_cost first for any paid tool, and flags which tools are free versus paid. It does not explicitly say 'use list_edit_tools instead when you only need metadata' or list exclusions, but the pricing guidance is concrete and actionable.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=true, destructiveHint=false, so the safety profile is covered; the description adds genuine behavioral context on async execution, the returned task_id, and the polling cadence. It stops short of warning that repeated calls create duplicate jobs (relevant given idempotentHint=false) or addressing auth/cost, so it earns a 4 rather than 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?

Two tight sentences with no waste; the endpoint and return value are front-loaded ahead of the recommendation. It is slightly under-explained for a 25-parameter tool, but nothing is filler.

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

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

An output schema exists so return values need no explanation, and the description still supplies the key workflow fact (task_id plus polling interval). For a 25-param async tool with 4 required params, this covers what an agent needs to invoke it correctly, though it could note that the job continues server-side after the call returns.

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% across all 25 parameters, so the schema already carries the full parameter burden, including style limits, seed reuse, and animation frame counts. The description adds no per-parameter guidance of its own, making the baseline 3 correct.

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

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

States a specific verb, resource, and mechanism: 'Start a generation as an async job (POST /v2/inferences with async=true) and return a task_id.' This clearly separates it from the sibling create_inference (synchronous generation) without needing to open either schema.

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

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

Explicitly names the cases that select this tool (advanced animations rd_advanced_animation__*, other animation styles, batches), explains why (they run for tens of seconds and can outlive a synchronous MCP call), and gives the follow-up procedure ('poll the returned task_id with get_inference_job roughly every 2-5 seconds'). Nothing is left to inference.

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

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

The description adds meaningful behavioral context beyond annotations: it is paid and priced by size, the first animation is free, animations do not create a new version, and the caller should poll the job. This goes well beyond the readOnly/idempotent/destructive flags and helps the agent set expectations.

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 compact sentences, each carrying distinct value: the core operation, pricing/free-first behavior, and polling instruction. Content is front-loaded and there is no filler.

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

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

For a paid, asynchronous animation mutation, the description covers the key operational facts: pricing model, version behavior, and how to track the job. Required parameters are documented in the schema and an output schema exists, so return shape does not need to be in the description.

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 seven parameters. The description adds no substantial parameter-level detail beyond the schema; the mention of passing an animation name to change it mirrors what the animation parameter description already says.

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

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

The description states a specific verb and resource: 'Add an animation to a Low-Poly model version, or change an existing one.' It further distinguishes the operation by noting animations attach to the version and do not create a new version, which separates it from sibling operations like generation or revision.

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

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

It clearly frames when to use this tool: to add or change an animation, and says to poll get_lowpoly_job afterward. It does not explicitly enumerate alternatives or exclusion criteria, but the context of what counts as an animation operation 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=false, destructiveHint=false), the description reveals the async behavior ('Returns task_id and asset_id immediately'), the refund policy ('Failed jobs are refunded automatically'), and the constraint on restarting jobs. It also explains that input_palette colors persist into revisions and animations. These are critical behavioral traits that the annotations do not capture.

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

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

The description is a single dense paragraph that is front-loaded with the main purpose. It packs a lot of information but is reasonably organized: it starts with the core action, then explains key parameters, then the return and follow-up workflow, then the refund/restart caveat. It could benefit from line breaks or bullet points for clarity, but every sentence adds value and there is no fluff.

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

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

For a complex tool with 9 optional parameters and no required inputs, the description covers the full workflow: what to provide, what is returned, how to poll, what to do next, and failure handling. It also mentions the cost implication ('paid') and the pricing nuance for size in the schema. The agent has enough information to invoke the tool correctly and know the expected outcome, including the asynchronous nature.

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

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

The schema already covers all parameters with 100% description coverage, so the baseline is 3. The description adds meaningful semantics for reference_models ('puts your existing models (by asset_id) into it exactly') and input_palette ('the model uses only its colors, and revisions and animations keep them'), which go beyond the schema's terse descriptions. It does not add semantics for mode, size, style, or idempotency_key, but the schema descriptions are already detailed.

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: 'Start building a low-poly 3D model with pixel-art textures from a prompt and/or reference images.' It names the resource (low-poly 3D model), the verb (start building), and the input types. It also distinguishes itself from sibling tools by naming export_lowpoly_model, start_lowpoly_revise, and start_lowpoly_animate as subsequent steps, preventing confusion with them.

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

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

The description provides explicit workflow guidance: it says to poll get_lowpoly_job(task_id) until success, then use export_lowpoly_model, start_lowpoly_revise, or start_lowpoly_animate for follow-ups. It also warns 'never restart a running job' and clarifies that reference_models places existing models exactly, which implies this tool is for building new models or incorporating existing ones. This gives clear when-to-use and when-not-to-use context.

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

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

The description adds meaningful behavioral context beyond the annotations: the version is updated in place, animations whose bones the new rig still has are kept, the operation is paid and priced by size, and users should poll get_lowpoly_job. This is exactly the kind of consequence disclosure an agent needs and is consistent with 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 sentences deliver the core purpose, cost, mutation behavior, animation preservation, and next-step polling instruction. There is no filler, and the most important decision-relevant 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 an async, paid, mutating job, the description covers selection criteria, pricing model, in-place behavior, animation consequences, and the follow-up polling call. With a full input schema and an output schema present, no essential guidance 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%, with each parameter already clearly explained in the input schema. The description does not add parameter-specific detail beyond what the schema provides, so the 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 opens with 'Rebuild the skeleton of a rigged Low-Poly model version', using a specific verb and resource. Examples like 'move a pivot or add bones' clarify intent, and the mention of unrigged versions distinguishes it from related start_lowpoly_* 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 clearly states when to use the tool (re-rigging a rigged version) and gives an exclusion: versions without a rig are rigged for free by their first animation instead. It does not explicitly name alternative sibling tools, so it stops just short of full alternative routing.

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

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

Annotations only mark readOnlyHint false and destructiveHint false; the description adds genuinely useful behavioral context: the operation is paid and priced by model size, it creates a new version rather than overwriting, it is asynchronous (poll get_lowpoly_job), and only one job per model is allowed at a time. It does not cover error/failure conditions, but the added disclosures are substantial.

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 four short sentences with no filler. Cost, core action, output behavior, and concurrency constraint are all front-loaded, and every sentence adds information the agent needs.

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

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

For an async, paid, side-effectful operation, the description covers the critical non-obvious facts: polling, per-model concurrency, and version creation. The output schema and complete parameter schema are present, so return values and parameters are handled. The main gap is explicit routing among the many start_lowpoly_* siblings.

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 carries the parameter documentation burden and the baseline is 3. The description adds little param-specific meaning beyond context like 'one job per model,' which touches asset_id indirectly. It does not need to compensate for schema gaps because there are none.

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: 'Change an existing Low-Poly model,' which clearly sets this apart from creation tools like start_lowpoly_generate. The outcome 'saved as a new version' further pins down its purpose as a revision operation, not an animation, split, or rerig.

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

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

The phrase 'existing Low-Poly model' and 'saved as a new version' imply the revision use case, and 'Poll get_lowpoly_job(task_id)' gives the correct follow-up. However, it does not explicitly say when to use this over sibling tools like recolor_lowpoly_model, start_lowpoly_rerig, or start_lowpoly_generate, nor does it state exclusions.

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

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

Beyond the annotations, the description discloses that each piece becomes a new model and history item, faces the front, retains its own textures/rig/animations, and leaves the original unchanged. It also reveals that the operation is paid and priced by size, and directs the agent to get_lowpoly_job for completion. No contradiction with annotations.

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

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

Three sentences, front-loaded with the core action and pricing, then piece behavior and polling instructions. Every sentence adds information and there is no 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 an asynchronous start_job tool, the description covers the essential post-call behavior (poll get_lowpoly_job and inspect its pieces), cost, preservation of model attributes, and non-destructive behavior. The presence of an output schema means return values do not need to be explained in the description.

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 does not add parameter-level detail beyond what the schema already provides; the cost and output context apply to the operation as a whole rather than 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?

Description states a specific verb ('Break') and resource ('Low-Poly model into separate models'), with a concrete desk-scene example. It clearly differentiates from sibling tools like start_lowpoly_generate, start_lowpoly_animate, and start_lowpoly_revise by describing a split operation.

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

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

The description establishes when to use the tool: to break an existing low-poly model into separate pieces. It also tells the agent to poll get_lowpoly_job afterward. However, it does not explicitly name alternatives or state when not to use this tool, though context makes the intended use fairly 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?

The description adds one meaningful behavioral detail: style-level references are 'baked into the custom style' and are distinct from per-inference reference_images. It does not disclose whether unspecified fields are preserved or reset, what side effects updating a style has, or any auth-related behavior. The annotations are also internally inconsistent because destructiveHint appears twice with conflicting values.

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 sentences with no filler. The core operation is front-loaded, and the important caveat about style-level references is stated clearly and compactly.

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 18 parameters, an output schema, and several mutual-exclusion constraints, the description is somewhat thin. It covers the endpoint and the reference distinction, and the schema compensates for parameter-level details, but it omits update semantics such as whether omitted fields are preserved and does not guide the agent on when to update versus create or delete a style.

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 documents parameter meanings, defaults, and constraints such as min_width being required together with min_height. The description adds only the style-level versus per-inference reference distinction, which is useful but only partially extends beyond the schema text.

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 'Update a public RD Pro user style using /v2/styles/{style_id}', which names a specific verb, resource, and endpoint. This clearly identifies the operation as an update rather than a read or list operation, though it does not explicitly contrast with create_user_style or delete_user_style.

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 useful guidance for choosing style_reference_images/style_reference_caption over per-inference reference_images, which helps with parameter selection. However, it does not explain when to prefer update_user_style over create_user_style or delete_user_style, nor does it mention preconditions or when not to use this tool.

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