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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states that it blends images and returns a Task ID, implying asynchronous generation. It does not disclose side effects, resource consumption, authentication needs, or other behavioral traits, leaving significant gaps.

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

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

The description is concise with a clear structure: purpose, usage list, example, and return type. It is front-loaded with the main action. Some redundancy exists (e.g., repeating 'blend' and 'combine'), but overall it's well-organized and 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 presence of an output schema and comprehensive parameter documentation, the description covers the tool's purpose, usage scenarios, and return value. It could be more complete by mentioning limitations like image size or format, but it sufficiently sets expectations for a blending 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%, providing full parameter descriptions. The tool description adds an example but does not provide additional semantics beyond the schema. With high schema coverage, the baseline of 3 is appropriate for not adding extra 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 clearly states the tool blends multiple images (2-5) using Midjourney, which is a specific verb+resource. It distinguishes from siblings like midjourney_imagine (text-to-image) by focusing on image blending, though it doesn't explicitly name alternative tools.

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

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

The description provides explicit 'Use this when' bullet points covering merging, composite creation, and style blending. It gives clear context but does not mention when not to use or suggest alternative tools among the siblings, which would improve 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 provided, so description bears full burden. It discloses the tool analyzes an image and returns descriptions with style tags. No side effects are mentioned, but the read-only nature is implied. Could explicitly state non-destructive 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?

Description is well-structured with a summary, bullet-point usage, and output note. Every sentence adds value, no unnecessary repetition.

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

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

For a simple tool with one parameter and an output schema, the description covers purpose, usage, and return format completely. No 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 coverage is 100% with a clear description for image_url (must be direct URL). The tool description adds no additional parameter guidance, so baseline 3 is appropriate.

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

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

The description clearly states the tool provides AI-generated descriptions of an image, returning 4 alternative text prompts. This distinguishes it from sibling tools like midjourney_imagine (generation) and midjourney_transform (editing).

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 lists specific use cases (e.g., reverse-engineering style, inspiration) but does not explicitly state when not to use or compare to alternatives. Still provides clear context for appropriate usage.

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 must carry behavioral disclosure. It explains important behavior like mask semantics (white regenerates, black preserves) and that the tool returns task ID plus image information. However, it does not disclose side effects, async behavior, failure modes, or any requirements beyond the schema.

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

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

The description is well-organized with a short summary, bulleted use cases, mask guidance, and return info. It is not overly verbose and front-loads the core purpose. The four 'Use this when' bullets are slightly overlapping but still earn their place by clarifying intended scenarios.

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 7 parameters, an output schema, and 100% schema coverage, the description provides enough operational context: what it does, when to use it, how masks work, and what is returned. It does not discuss async/callback modes, but those are fully documented in the schema, so the description does not need to repeat them.

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%, giving a baseline of 3. The description adds value by explicitly stating black mask areas are preserved, which complements the schema's white-region semantics, and by clarifying 'optionally using a mask' in the main description. This adds meaning beyond the structured 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 verb ('Edit'), the resource ('an existing image'), and the method (via text prompt, optionally with mask). It distinguishes the tool from image generation siblings like midjourney_imagine, though it does not explicitly name a sibling to differentiate from.

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 'Use this when' section provides clear contextual scenarios: modifying existing images, adding/changing elements, applying style changes, and region-specific edits. It does not explicitly list exclusions or when to prefer a sibling tool like midjourney_transform, but the usage 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?

With no annotations provided, the description carries the behavioral transparency burden. It discloses that this is an extension operation based on a prompt and that it returns a Task ID plus extended video information. However, it does not describe the asynchronous workflow, whether a new video is created while the original remains unchanged, or any rate/cost implications. It provides moderate transparency but leaves important behavioral details to the schema or the agent's inference.

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

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

The description is well-structured with a clear opening statement, a concise 'Use this when' section, and a returns section. It is front-loaded with the core purpose and avoids excessive detail. Minor redundancy exists between 'make a video longer' and 'add more content to a short clip', but overall it is efficient and scannable.

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 moderately complex tool with 8 parameters, the description covers purpose, usage scenarios, and return value. The output schema and parameter schemas handle details like callback_url and async behavior. The description does not explain the full async task lifecycle, but mentioning Task ID and having get_task/get_tasks_batch as siblings makes the context reasonably complete for an agent.

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 explains all parameters clearly, including video_id, prompt, video_index, resolution, and callback_url. The description adds only general context about continuing a video based on a prompt description, which maps loosely to parameters but does not add meaningful meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the specific action ('extend an existing Midjourney video'), the resource (existing video), and the outcome (make it longer by adding frames). It also distinguishes this from generating a new video by emphasizing continuation of a previously generated result, so an agent can separate it from siblings like midjourney_generate_video.

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

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

The description provides an explicit 'Use this when' list covering the main use cases: making a video longer, continuing story/motion, and adding content to a short clip. It does not explicitly state when not to use it or name alternative tools, but the context is clear enough to guide selection away from generation-focused 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?

There are no annotations, so the description carries the burden of behavioral disclosure. It discloses the key image-to-video-only requirement, the optional ending-frame feature, that four video variations are generated, and that the response includes task ID and video information with URLs. It does not clarify async-versus-sync return behavior, but the main behavioral constraints are well covered.

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

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

The description is well-structured: it front-loads the core purpose and constraint, then gives short use-case bullets and a returns section. It is appropriately sized, though a couple of phrases like 'You need AI-generated video content' and 'using Midjourney' are slightly redundant.

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 8 parameters, the rich schema descriptions, and the presence of an output schema, the description covers the essential context: what the tool does, when to use it, the need for a reference image, optional ending-frame control, and the return shape. The main gap is not routing the agent to midjourney_extend_video for extending existing videos or clarifying async behavior, but the schema and output schema mitigate most of 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?

Schema description coverage is 100%, so the baseline is 3 and the schema already explains all eight parameters. The description adds context around image_url being required and end_image_url giving more control, but these mostly echo the rich schema descriptions. It does not add meaningful detail about mode, resolution, loop, async, or callback beyond what the schema provides.

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

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

The description clearly states the specific operation: 'Generate a video from a reference image using Midjourney.' It also emphasizes the image-to-video-only constraint, which distinguishes it from text-to-video or image-generation tools. It does not explicitly name a sibling alternative like midjourney_extend_video, so it falls just 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?

The 'Use this when' section provides concrete triggers: animating a still image, creating short video clips from a reference image, and needing AI-generated video content. This gives clear context for when to select the tool, but it does not mention when not to use it or point to an alternative such as midjourney_extend_video for existing videos.

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 fully discloses behavior: it returns a guide with prompt structure, parameters, and examples. It is a read-only operation with no side effects, and the return content is clearly stated.

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

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

The description is three concise sentences: purpose, benefit, and return content. It is well-structured with no unnecessary fluff, making it efficient for an agent to parse.

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

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

Given no parameters and an output schema, the description covers the tool's purpose and return content completely. It leaves no gaps in understanding what the tool does and what it provides.

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 no parameters, and the schema coverage is trivially 100%. The description adds no parameter information, but since none exist, the baseline score of 4 for zero parameters 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 'Get guidance on writing effective prompts for Midjourney,' which identifies the tool's purpose with a specific verb and resource. It distinguishes from sibling tools like 'midjourney_imagine' by focusing on guidance rather than generation.

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

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

The description explains what the guide does and implies usage before writing prompts, saying 'Following this guide helps Midjourney understand your creative vision.' However, it does not explicitly mention when not to use it or provide alternatives, though this is minimally necessary for a guide 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?

With no annotations provided, the description carries the full burden. It explains what a seed is and its role in reproducibility, and states the return value. It could mention that the operation is read-only and requires prior generation, but overall it's transparent.

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 with six well-structured sentences. Use cases are presented in a bullet-like format without redundancy, and every sentence contributes meaningfully.

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 (one required parameter, no nested objects, output schema present), the description fully covers the needed context: purpose, usage scenarios, parameter meaning, and return value. No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying 'image_id' as the field from a previous imagine result, which helps the agent understand the specific parameter context beyond the schema alone.

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 verb ('Get') and resource ('seed value of a previously generated Midjourney image'), making the tool's purpose unambiguous. It distinguishes from sibling tools like midjourney_imagine which generates images.

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 use cases (reproduce generation, use with --seed, create variations) but does not specify when not to use or mention alternative tools for similar tasks. It gives clear context for appropriate usage.

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 bears the full burden. It states the tool queries and retrieves but does not disclose any potential side effects, rate limits, or idempotency. For a query tool, this is adequate but lacks depth on constraints or error 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 extremely concise: a single sentence for purpose, a bulleted list of usage scenarios, and a returns summary. Every sentence adds value with no redundancy.

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

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

Given the presence of an output schema and full parameter descriptions, the description covers purpose, usage, and key return fields (URLs, dimensions, actions). It lacks mention of idempotency or multiplicity but is complete for a simple query 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 description coverage is 100%, with both parameters (task_id, trace_id) already well-described in the schema. The tool description adds no new meaning beyond summarizing their purpose. 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 it queries the status and result of a Midjourney generation task. It specifies retrieving image/video URLs and metadata, and distinguishes this from siblings like midjourney_imagine (creation) and midjourney_get_tasks_batch (batch query).

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?

Four explicit 'Use this when' scenarios are provided (check completion, retrieve URLs, get full details, async results). It does not mention when not to use it or direct alternatives, but the context is clear.

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

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

No annotations are provided, so the description carries full burden. It explains the query behavior, mentions pagination, and max batch size in schema, but does not disclose rate limits, authentication needs, or behavior for invalid IDs. Adequate but not exhaustive.

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 very concise, with a clear header and bullet-pointed usage scenarios. Every sentence adds value, no fluff or repetition.

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

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

Given the tool's complexity (4 parameters, 0 required, high schema coverage, and output schema), the description covers purpose, usage, return value ('Status and result information'), and pagination. No significant gaps remain.

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 parameters are well-documented. The description adds value by explaining when to omit task_ids/trace_ids for pagination, and the schema includes max batch recommendation. This goes beyond 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 it queries multiple Midjourney tasks at once, specifying action (query), resource (tasks), and batching. It distinguishes itself from the sibling tool midjourney_get_task by emphasizing efficiency and batch capability.

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 lists four use cases with bullet points, guiding when to use this tool (multiple pending checks, batch status, pagination). It implies alternatives (single task queries use midjourney_get_task) without explicitly naming it, but the context is clear.

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

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

With no annotations provided, the description carries the disclosure burden. It usefully reveals the 2x2 grid output and the return payload including Task ID, URLs, dimensions, and available actions. However, it does not mention billing/credit consumption, expected latency, or asynchronous execution behavior, which are material for an image-generation 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 well-organized into purpose, usage criteria, alternative routing, and return information. Every sentence adds value, and the structure is front-loaded with the primary action before usage 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 complex 14-parameter tool with an output schema, the description covers the core invocation path, output format, and sibling routing. Version-specific and async/callback details are already documented in the input schema, so the description does not need to repeat them.

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 14 parameters including defaults, version notes, and examples. The description adds no new parameter-level semantics beyond emphasizing that the prompt is the core input, which is acceptable because the schema already handles this thoroughly.

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 and resource: 'Generate AI images from a text prompt using Midjourney.' It clearly positions this as the primary creation tool and distinguishes it from midjourney_transform by noting that transformations like upscaling or variations belong elsewhere.

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 explicit 'Use this when' criteria such as creating new images from a text description, visualizing a creative vision, or needing AI-generated artwork. It also names the alternative midjourney_transform for transformation tasks, giving an agent direct routing 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. It clearly states it returns a categorized list of actions and tools, which is a read-only operation. No hidden behaviors or side effects are implied.

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 sentences, front-loaded with the primary purpose, then additional context. Every sentence adds value without redundancy.

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

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

Given the tool has no parameters, an output schema exists, and it is a simple listing tool, the description fully covers what the tool does and what it returns. No additional information is needed.

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, so there is nothing to explain. The description adds value by describing the output format (categorized list) and its purpose as a reference guide.

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 explicitly states that the tool lists all available Midjourney API actions and corresponding tools, and serves as a reference guide. This clearly distinguishes it from sibling tools which are action-specific (e.g., midjourney_imagine, midjourney_transform).

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

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

The description indicates it is helpful for understanding the full capabilities, implying use for discovery and reference. It does not explicitly state when not to use it or compare to alternatives, but context makes it clear this is the overview 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?

No annotations are provided, so the description must convey behavior. It states it returns detailed list and usage guidance, implying a read-only operation. However, it does not explicitly confirm no side effects or mention authentication, leaving some ambiguity.

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

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

Three sentences, each providing essential information: purpose, context as reference guide, and content of return. No unnecessary words, 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?

Given no parameters and an output schema, the description is complete. It explains what the tool does and what the return entails, sufficient for an AI 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?

With zero parameters, baseline is 4. The description adds value by explaining the output includes 'Detailed list of all transformation actions and when to use them,' which goes beyond the empty 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 'List all available transformation actions for Midjourney images,' specifying 'transformation' to distinguish from sibling tools like midjourney_list_actions. The title reinforces this, making the purpose unambiguous.

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

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

The description says it's a 'Reference guide for transform actions used with midjourney_transform tool,' implying it should be used before calling midjourney_transform. However, it does not explicitly state when to use or not use this tool compared to alternatives like midjourney_list_actions.

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 must fully disclose behavior. It describes the process (analyzes tokens, produces candidates) but lacks details on side effects, permissions, rate limits, or whether the tool is read-only. The description is informative but not comprehensive.

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

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

The description is well-structured with a brief main sentence, a clarifying paragraph, a bulleted use-case list, and a return statement. Every sentence adds value, and the most critical information is front-loaded.

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

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

Given the tool's simplicity (one parameter, clear output) and the presence of an output schema, the description covers all essential aspects: what it does, when to use it, and what it returns. No gaps are apparent.

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

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

Schema description coverage is 100%, so the parameter is already well-documented. The description adds some context about the analyzer and token weighting, but this does not significantly increase understanding beyond the schema's own description. 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 clearly states the verb 'shorten and analyze' and the resource 'Midjourney prompt'. It distinguishes itself from siblings like midjourney_imagine or midjourney_describe by focusing on prompt optimization, and it explicitly lists the output (up to 5 shortened candidates).

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

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

The description includes a 'Use this when:' section with three specific scenarios (long prompt, identifying impactful words, simplifying complex prompts). However, it does not mention when not to use the tool or explicitly name alternative siblings, which would strengthen the 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 full burden. It describes actions and their effects, but lacks details on side effects, rate limits, or prerequisites like image_id validity. Adequate but not exhaustive.

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

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

The description is well-structured: a brief purpose statement, bullet points for usage, a workflow example, and return info. No unnecessary words; efficiently conveys needed 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 tool's complexity (5 parameters, many actions) and existence of an output schema, the description covers main usage scenarios and workflow. Could improve by noting error handling or prerequisites.

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

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

Schema coverage is 100%, and the description adds context: image_id is tied to a previous generation, prompt/mask are used with variation_region, and the workflow example explains action sequence. Adds 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?

The description clearly states the tool transforms existing Midjourney images with operations like upscaling, variations, zoom, and pan. It distinguishes itself from generation tools but does not explicitly differentiate from midjourney_edit or midjourney_blend.

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 'Use this when' section lists specific scenarios (upscale, variation, zoom, pan, reroll), and a workflow example is provided. However, it does not explicitly state when not to use this tool or mention alternatives like blend or edit.

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 bears full responsibility. It discloses that translation is optimized for image generation and returns English text ready as a prompt. This is adequate for a straightforward translation tool, though it does not mention any rate limits or error handling.

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 paragraphs plus a return line, breaking down purpose, usage, and output. Every sentence is meaningful, and there is no wasted text.

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 (single parameter, output schema exists), the description covers purpose, when to use, and what it returns. It is fully complete for an agent to decide when to invoke this tool.

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

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

The schema description coverage is 100%, giving a baseline of 3. The description adds minimal extra value beyond the schema, only rephrasing that the content is Chinese text for translation. The schema already describes the parameter adequately.

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 that the tool translates Chinese text to English specifically for Midjourney prompts, with a specific verb 'Translate' and resource 'Chinese text to English'. It distinguishes itself from siblings which are all other Midjourney tool categories (e.g., imagine, blend) that serve different purposes.

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 a clear list of when to use the tool (Chinese description needing translation, converting Chinese prompts, needing English for better results). While no explicit when-not or alternatives are given, the context of Midjourney tools makes it clear that this is for translation only, not other tasks.

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 full burden. It explains the tool uses a reference image and modifies based on prompt, mentions the --iw parameter, and states it returns a Task ID and image info. Missing: behavior on invalid URLs, rate limits, or cost differences. Still good overall.

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 with clear sections: main action, usage scenarios, tips. Every sentence adds value. No redundant or verbose phrasing.

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 3 parameters, no nested objects, and an output schema (implied), the description is sufficient. It covers usage, returns, and tips. Could elaborate on output fields, but output schema exists to fill 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 coverage is 100%, but the description adds value beyond schema by explaining how to use --iw for control and providing example prompts. This contextualizes the prompt parameter more richly than the schema description alone.

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

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

The description clearly states it generates images using a reference image as inspiration. The verb 'generate' and the resource 'reference image' are specific, and it contrasts with sibling tools like 'midjourney_imagine' which does not use a reference.

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 lists explicit use cases ('when you want to reimagine, change style, add/change elements'). However, it does not explicitly state when NOT to use this tool (e.g., for generation without reference). This is a minor gap.

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