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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation by using the word 'check', but it does not disclose what the response contains, whether any side effects exist, or whether authentication or rate limits apply. This is minimal behavioral 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?

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, making it appropriately concise for the tool's simplicity.

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, read-only tool, the description is largely complete: the agent knows what the tool does and that it requires no arguments. However, since there is no output schema, the absence of any statement about the return format (e.g., a number or object) leaves a minor gap. Overall, it is sufficient for a trivial tool.

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

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

The input schema has zero parameters and 100% schema coverage, so the description does not need to explain parameter semantics. The baseline for 0-parameter tools is 4, and the description adds nothing false or misleading.

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 'Check remaining API credits' states a specific verb ('check') and a specific resource ('remaining API credits'). It is immediately distinct from all sibling tools, which are generation, transformation, or estimation tools, so an agent can identify its purpose without ambiguity.

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

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

The description gives no usage context, prerequisites, or alternatives. It does not say when to use this tool instead of estimate_cost or get_model_info, so the agent is left to infer the appropriate timing from the name alone.

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

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

With no annotations provided, the description carries the full behavioral burden. It only mentions that file paths are automatically processed without displaying the base64 string; it does not disclose whether inputs are modified, how results are returned, or what side effects or limitations exist.

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

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

The description is compact and front-loaded with the core action and operations, followed by accepted input formats. It avoids wordiness, though 'and more' is slightly vague and could be replaced with the remaining operations.

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 schema covers all parameters in detail, which mitigates the lack of an output schema and annotations. Still, for a tool with 5 operations and 8 parameters, the description does not explain return behavior, operation-specific nuances, or when to use this tool over siblings, leaving meaningful gaps.

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

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

Schema description coverage is 100%, so the schema already explains all 8 parameters. The description adds little beyond restating the image input handling that is already documented in the schema, 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 ('Enhance') and resource ('images') and lists several concrete capabilities such as upscaling, restoration, and background removal. It is clear about the tool's purpose, though it does not explicitly contrast itself with sibling tools like transform_image.

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 says the tool accepts file paths, URLs, or base64, but gives no guidance on when to use enhance_image versus transform_image or other sibling tools. There are no exclusions, prerequisites, or alternative selection criteria.

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?

Without annotations, the description carries the burden of explaining behavior. 'Estimate' conveys that this tool does not execute generation, which is useful. However, it does not explicitly state that no credits are consumed or that this is a read-only operation.

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

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

A single, front-loaded sentence that states the tool's core purpose with no filler or redundancy. It is compact and immediately understandable.

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 six optional parameters, no required parameters, and no output schema, the description is too sparse. It does not explain how model, category, and list_all relate, what a request with no parameters returns, or what the response structure looks like.

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 six parameters. The description adds no parameter-level detail, which 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 uses a specific verb ('Estimate') with a clear resource ('credit cost and time for image/video generation operations'). This clearly distinguishes it from sibling generation tools like generate_image and from balance tools like check_credits.

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

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

There is no guidance on when to use this tool versus alternatives such as check_credits, list_models, or get_model_info. No exclusions, prerequisites, or decision criteria are 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core function and does not mention output behavior, default display mode, model-specific caveats, resource usage, or how results are returned to the agent.

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

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

The description is a single, front-loaded sentence with no filler or redundancy. It efficiently conveys the purpose without duplicating schema information, which is appropriate given the rich input schema.

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

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

The schema covers the parameters thoroughly, and some parameter descriptions (e.g., display_mode, save_location) indirectly address output handling. However, with no annotations and no output schema, the description alone does not provide enough behavioral or workflow context for such a complex generative tool with 14 parameters.

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

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

Schema description coverage is 100%, so all 14 parameters are already documented with meaningful descriptions and ranges. The description itself adds no parameter-level detail beyond echoing that text is converted to speech, 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 uses a specific verb ('generate'), specific resource ('speech audio from text'), and names the method ('TTS models'). This makes it clearly distinguishable from siblings like generate_image, generate_video, and especially generate_music.

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 purpose implies when the tool should be used (text-to-speech), and the sibling list includes generate_music as a contrast. However, there is no explicit statement about when to use this tool over alternatives or exclusions, leaving usage routing 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses base64/MIME output, but omits that display_mode defaults to "display" and would show the image rather than return base64, making the only behavioral claim conditional/inaccurate; it also says nothing about credit/cost 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?

Two short sentences, front-loaded with the action and then the output format. There is no fluff; even though the second sentence is imprecise about display_mode, it is structurally 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?

Given 10 parameters, 11 sibling tools, and no annotations or output schema, the description is too thin for an agent to reliably select and invoke it. It lacks routing guidance, output mode semantics, and cost/credit context.

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

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

Schema description coverage is 100% with detailed descriptions for all 10 parameters, so the descriptive burden is already met. The tool description adds no extra parameter meaning beyond tying generation to text prompts and models.

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: "Generate images from text prompts", which clearly identifies the tool's core action and separates it from generate_video/generate_audio and from transform/enhance tools. The addition of "various AI models" and return format further clarifies scope.

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

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

The phrase "from text prompts" implies the text-to-image use case, but there is no explicit when-to-use vs alternatives or any exclusions. With siblings like transform_image, enhance_image, and generate_video, the agent must infer routing from the resource noun alone.

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

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

Annotations are absent, so the description carries the full disclosure burden, yet it only restates the core action. It discloses nothing about non-determinism (despite the seed parameter), cost or credit consumption (estimate_cost exists as a sibling), latency, or how generated audio is returned. There is no contradiction, but almost no behavioral context beyond the tool's purpose.

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 definition is a single nine-word sentence with zero filler, front-loading the verb and resource. It is efficient, though the brevity reflects under-specification rather than rich compression of information.

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

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

For an 8-parameter generation tool with no annotations and no output schema, this is thin. The description says nothing about output format, the display/save/both behavior of display_mode, model selection, or cost implications, so an agent must infer critical invocation details from the schema alone. A few sentences covering output behavior and model guidance would be needed for completeness.

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 of 3 applies even though the description adds no parameter detail. The only marginal contribution is mapping 'text descriptions' to the prompt parameter; semantics for model, duration, display_mode, and save_location are entirely delegated to the schema.

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

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

The description states a specific verb and resource — 'generate music' from 'text descriptions' — making the tool's core function unmistakable. It does not, however, distinguish itself from the sibling generate_audio, leaving real ambiguity about whether music or general audio generation is intended.

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 when-to-use guidance is provided whatsoever. The description never mentions alternatives, exclusions, or selection conditions, and given the overlapping sibling generate_audio, the boundary between 'music' and 'audio' is left entirely to the agent's inference. This is simply absent guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic operation and does not mention generation time, cost implications, output format, default model behavior, save behavior, or other execution characteristics.

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

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

The description is a single concise sentence with no redundant wording. It front-loads the primary purpose and covers the two main generation modes in an efficient manner.

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

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

Given the tool has 9 parameters, no output schema, and no annotations, the description is too minimal to fully prepare an agent for invocation. It leaves important context unaddressed, such as what the tool returns, how long generation takes, and what side effects occur.

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

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

Schema description coverage is 100%, so the parameters are already well-documented. The description adds a conceptual link by mentioning text prompts and static images, which maps to the 'prompt' and 'image' parameters, but does not provide deeper semantic meaning beyond the schema.

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

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

The description clearly states the tool's function: generating videos from text prompts or animating static images. This distinguishes it from siblings like generate_image, generate_audio, and enhance_image, which target different media or operations.

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

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

The description provides clear context for when to use the tool: for video generation or image animation. It does not explicitly mention exclusions or alternatives, but the core use case is unambiguous given the sibling tool names.

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

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

There are no annotations, so the description carries the burden of conveying behavior. 'Get' and 'detailed information' clearly indicate a read-only lookup, but the description does not disclose what specific details are returned or how errors for invalid model_id values are handled.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the operation and the object of the operation efficiently.

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

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

For a one-parameter tool, the core call contract is clear. Still, with no output schema and no richer description, the agent cannot know what 'detailed information' includes or how errors/unknown model IDs are handled, so completeness is only adequate.

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

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

Schema coverage is 100%: model_id is already documented as 'Model ID'. The description adds only that the model is 'specific', so it provides minimal extra semantic value beyond the schema, placing it at baseline.

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

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

The description states a clear verb and resource: it retrieves detailed information for one model. 'Specific model' hints at a contrast with the sibling list_models, but it does not explicitly name that alternative.

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 phrasing 'specific model' and the required model_id imply this is the tool to call when the agent already has a model identifier, rather than when listing available models. However, it never explicitly says when to use this tool over list_models or any other sibling.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It fails to state that it is a read-only operation, what 'available' means (e.g., accessible to the user), or whether the result is a list of model identifiers or full metadata. Minimal behavioral context.

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

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

The description is a single, concise sentence with no filler. It is front-loaded with the verb and resource, and length is appropriate for a simple list 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?

For a simple one-parameter list tool, the description is adequate but does not clarify the nature of the returned list (e.g., model names vs full details) or point to get_model_info for specifics. Given the lack of an output schema and the presence of a sibling that provides details, a bit more guidance would improve completeness.

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 describes the category parameter as 'Filter by category' with an enum, so schema description coverage is 100%. The description's 'by category' adds no semantic value beyond what the schema provides. 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 states a clear action ('List') on a specific resource ('available AI models') with a scope ('by category'). It is distinguishable from siblings like generate_image or get_model_info, though it does not explicitly name the alternative for detailed info.

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

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

No guidance is given on when to use this tool versus siblings. It does not mention that get_model_info provides per-model details, nor when category filtering is appropriate. The description implies usage but offers no explicit decision criteria.

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

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

With no annotations, the description carries the behavioral burden. It discloses key behavior: it returns a short ID, not a base64 payload, to avoid display slowdowns. It does not detail file-system side effects or error behavior, but the disclosed return behavior is concrete and useful.

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 front-loaded with the most important information: recommendation, what it does, and the key behavioral benefit. The alternative tool is named early, and no sentence is wasted on filler.

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

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

For a simple two-parameter tool with no output schema, the description covers the essential facts: what it takes, what it returns, and when to use it. It does not enumerate accepted image formats or define what 'prepare' entails beyond the ID return, but the core calling context is clear.

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 file_path and max_size_kb clearly. The description adds little parameter meaning beyond the schema, though it does imply max_size_kb's purpose via the point about avoiding display slowdowns. 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 clear verb ('prepare') and resource ('a local image file'), and states its purpose: returning a short ID instead of the full base64 string for use with other tools. It also explicitly distinguishes itself from read_local_image, making sibling differentiation immediate.

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

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

The description gives a direct recommendation ('Always use this instead of read_local_image') and specifies the applicable context ('for image transformation tasks'). This tells an agent exactly when to choose this tool over a closely related sibling.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It warns that the output can be 'very large and slow to display', which is a meaningful performance trait. It does not explicitly state that the operation is read-only, but 'read_local_image' and 'Read a local image file' strongly imply no 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?

Two sentences with no filler. The purpose is stated first, followed by the warning and the alternative recommendation, which is well-structured and 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 two-parameter read tool without an output schema, the description covers the core behavior, the performance caveat, and the alternative. It does not cover error cases or supported file formats, but those are not essential given the schema and the straightforward nature of the operation. Slightly more context about when to use data_uri vs base64 could improve it, but it is largely complete.

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

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

Schema description coverage is 100%, with both file_path and return_format clearly described in the input schema. The description adds the base64 conversion context, but this mostly overlaps with the schema's default value. Since the schema already handles parameter meaning, a 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 action ('Read a local image file') and the transformation ('convert it to base64'), making the tool's function immediately clear. It also distinguishes itself from the sibling prepare_image by warning about the large output and recommending the alternative.

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 names the alternative tool (prepare_image) and gives the condition for choosing it ('for better performance'). This tells an agent when not to use this tool and what to use instead, which is exactly what this dimension requires.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses one genuinely useful behavior: file paths are auto-processed without dumping the base64 string into the conversation. But it does not disclose cost implications of an AI generation call, whether the original image is preserved, latency expectations, or whether upstream preparation (e.g., prepare_image) is needed.

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 with no filler. The core purpose is front-loaded in the first sentence, and the second sentence carries a concrete, actionable behavioral detail. Every clause earns its place.

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

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

For a 9-parameter, 2-required tool with no annotations and no output schema, the description covers input handling but leaves gaps: no guidance on how transform_image relates to the prepare_image workflow among siblings, no cost expectations, and no output-behavior detail beyond what the schema's display_mode enum already provides. 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%, establishing the baseline of 3 even with no param info in the description. The description reinforces the image parameter's accepted formats (path/URL/base64) and adds the 'without displaying the base64 string' behavioral nuance, but adds nothing about prompt, strength, model, or control_type beyond what the schema already documents.

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 ('Transform'), resource ('existing images'), and mechanism ('using AI with various control methods'). This clearly distinguishes it from generate_image (creates new images), enhance_image (implies improvement rather than arbitrary transformation), and prepare_image/read_local_image (image I/O utilities). An agent can tell which tool to reach for without inspecting the schema.

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

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

Usage context is implied — use this when an existing image needs modification rather than generation — and the input-format note gives practical guidance on what it accepts. However, no explicit when/when-not conditions or alternatives are named, and the closest sibling (enhance_image) is never referenced, leaving the selection decision between transform and enhance to inference.

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