MeiGen AI Image Generation MCP

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

The description says this tool reads an existing job 'without new charges', which strongly implies a read-only operation. The annotations set readOnlyHint=false, which contradicts that read-only framing. This is an annotation contradiction and prevents the description from providing reliable 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 four tight sentences, front-loads the core action, and each sentence adds guidance. There is no wasted text 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?

For a three-parameter lookup tool with an output schema, the description covers identifiers, lookup scenarios, and the nextAction caution. It is nearly complete, though the read-only contradiction in the annotations leaves a gap about the tool's actual side-effect profile.

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 adds useful context by emphasizing 'Provide generationId OR the caller requestId UUID' and explaining when requestId lookup is especially useful, which goes slightly 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?

States a specific verb and resource: reading an existing MeiGen job. The phrase 'without new charges' and the warning against creating a new paid UUID distinguish it from the sibling generation tools such as generate_image and 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?

Tells the agent exactly when to use it: to check an existing job by generationId or requestId. It gives concrete scenarios for requestId lookup, including a lost submit response, process restart, or another host, and explicitly warns not to convert an uncertain status into a new paid UUID.

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 give the safety profile (idempotent, non-destructive), and the description adds genuinely new behavior: no new charges, the polling cadence, and the recovery-only-on-retry_request rule. 'Read' phrasing sits slightly against readOnlyHint=false, but the recovery path legitimately mutates state, so this is tension rather than contradiction. Return contract (nextAction, completed links) is sketched but not fully specified.

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?

Front-loaded with what is read and the no-charge guarantee, then the polling/recovery rules in compact clauses. Dense with zero filler, though the middle clause stack reads as one long run-on that would be easier to scan as separate sentences.

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 status-polling tool with no output schema, the description covers the essentials an agent needs: what states it returns, that no charges result, the polling cadence, and the exact branch conditions for recovery vs. aborting. Only parameter naming is left unaddressed.

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 0% and the description never mentions the two required parameters. The agent is not told that 'skill' is one of the five enumerated pipelines nor that 'requestId' is the UUID from the initiating upload call. The enum values are self-documenting only for 'skill'.

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: read skill images and their failure/refund states, keyed implicitly to a skill request. This clearly separates it from siblings like upload_skill_image and the generate_* tools. It stops short of naming a sibling or explicitly saying it is the polling companion to an upload.

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 prescribes the polling protocol: follow nextAction, wait afterSeconds (normally 10s), recover only on retry_request with exact parameters, and do NOT poll for payment/auth/input failures or daily limits. This is a full when-to-use / when-not-to-use contract.

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 destructive action (destructiveHint=true, readOnlyHint=false), and the description's action list is consistent with that. However, the description adds no extra behavioral details such as permanence of deletion, side effects of modification, or output format.

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

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

The description is a single concise sentence that front-loads the primary verb and lists all supported actions without fluff. It is appropriately sized for the tool's scope.

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

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

The tool has a complex multi-action interface with no output schema, and the description does not mention what actions return (e.g., whether view returns the workflow JSON or list returns names). While the param descriptions are thorough, the lack of output/return info leaves a gap for agents.

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% description coverage with detailed descriptions for all six parameters, including the enum for action and examples for modify values. The description itself adds no parameter semantics beyond the schema, so 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?

Description clearly states the tool manages ComfyUI workflow templates and enumerates the five supported actions (list, view, import, modify, delete). This distinguishes it from sibling tools focused on generation or search.

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 workflow template management but does not explicitly state when to use this tool over alternatives, nor does it mention any prerequisites or exclusions. However, the action list provides clear context for when each action is appropriate.

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

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

Annotations already declare readOnlyHint=true, so the description's mention of 'free, no API key needed' adds minor behavioral context. It does not detail rate limits or failure modes, but the tool's simplicity and annotation coverage make this acceptable.

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 serving a purpose: stating the transformation, providing a use case, and offering a tip. No wasted words, front-loaded with the main function.

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 tool with two parameters and no output schema, the description covers the core functionality, usage context, and accessibility. It is sufficiently complete for an AI agent to understand and invoke the tool correctly.

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

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

Schema coverage is 100% with detailed parameter descriptions. The description's mention of 'simple idea' aligns with the prompt parameter, but adds no new information beyond the schema. Baseline 3 is appropriate given full schema coverage.

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

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

The description clearly states the tool's purpose: transforming a simple idea into a professional image generation prompt. It provides a concrete example ('a cat in a garden') and implies its role as a prompt enhancer distinct from image generation tools.

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

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

The description explicitly states when to use the tool ('when the user provides a brief description and needs a detailed, high-quality prompt') and suggests combining with gallery inspiration. It does not explicitly list when not to use or compare to siblings, but the context is clear enough.

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?

Adds substantial context beyond the annotations: requires a configured MeiGen API key, purchased credits only, automatic upload of local files and public HTTPS URLs, non-atomic batches, estimates are not server-enforced caps, and a bounded retry policy for temporary uploads. This materially changes how an agent budgets and retries.

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 first sentences are well front-loaded, but the remainder is a dense block of agent-orchestration policy (prompt enhancement, preference loading, delegation, end-user language, progress ownership) that reads more like system instructions than tool documentation. Size is disproportionate to a single-image generation tool.

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?

No output schema exists, yet the description compensates by stating the return shape ('structured status, handles, errors and completed URLs') and clarifying the caller owns previews/downloads/presentation. Auth, cost and retry behavior are all covered, leaving only the absence of concrete return field 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?

Schema description coverage is 100%, so the baseline is 3. The description reinforces mode behavior ('custom needs a background description, inferred from the request when present') and that background references are optional, but adds little about ratio, quality, requestId or productImage beyond what the schema already documents in detail.

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?

Opening sentence states a specific verb, resource and scope: 'Create one product photo with a new background.' It also disambiguates against the closest sibling by naming remove_background for transparent cutouts, so an agent can route without opening 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?

Gives explicit mode-selection semantics (white/smart/custom), names remove_background as the alternative, and specifies recovery precedence (check interrupted submission, preserve retryParameters) plus when to skip prompt enhancement and preference loading. It stops short of a clean when-to-use table, but the routing conditions are clear.

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

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

Annotations already flag readOnlyHint=false and destructiveHint=true; the description adds a valuable behavioral rule: only append --sref for Midjourney when a style code is provided, and never pass URLs or local paths through it. This prevents a real misuse and clarifies referenceImages as the image-reference pathway. It does not explicitly discuss costs or file-writing side effects in the main description, but the annotations and schema cover part of that burden.

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

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

Four dense sentences are front-loaded with the core operation and platform support. The tip and sref warning earn their place; there is no filler and no redundant restatement of what the schema already documents.

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 15 parameters and multiple provider backends, the description plus the rich schema covers the critical call decisions: provider, async wait behavior, reference images, and Midjourney style handling. It does not enumerate every provider quirk, but an output schema exists and the parameter descriptions are detailed, so the definition is sufficiently 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?

The schema already documents 100% of the 15 parameters, so the baseline is 3. The description adds meaning beyond the schema by explaining the Midjourney --sref modifier (only when a style code exists) and by explicitly routing image-based references to referenceImages instead of the prompt.

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 operation ('Generate an image using AI') and names the supported backends (MeiGen, local ComfyUI, OpenAI-compatible APIs). It is generic enough to be distinguished from specialized siblings like generate_marketing_poster or generate_ai_background, but it does not explicitly name those alternatives for direct 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?

The tip points the agent to get_inspiration/enhance_prompt for prompt quality and to gallery URLs for style reference, giving useful context about how to compose a call. However, it does not state when to choose this general generator over the specialized generation siblings, nor does it give exclusions or alternative routing conditions.

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

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

Goes well past the annotations: discloses that a paid request needs a configured MeiGen API key and purchased credits only, that local files and HTTPS URLs are auto-uploaded, that a batch is not atomic and an estimate is not a spending cap, and that requestId must be reused on retry. This complements rather than repeats destructiveHint/openWorldHint/idempotentHint.

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, but the body is a dense run-on covering cost, retry, recovery, upload, and ownership policy in one block, with some duplication ('preserve caller-supplied inputs' / 'Preserve supplied details'). It is informative but hard to scan and not tightly edited.

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 14-parameter, paid, open-world generation tool with no output schema, the description covers auth requirements, credit/cost behavior, retry and interruption recovery, and what the caller owns (progress, previews, downloads). Nothing an agent needs to invoke it correctly appears 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% and each parameter already carries a thorough description, so the schema does the heavy lifting and the baseline is 3. The description adds cross-parameter guidance ('autoCopy=false' preserves supplied copy, never invent event details), but it is not the primary source of parameter 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?

Opens with a specific verb+resource: 'Design one poster for a brand, shop, event, promotion or topic,' which separates it from generic siblings like generate_image or generate_product_detail_images. It never names a sibling explicitly, so the differentiation is implicit rather than spelled out.

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?

Gives real routing guidance: 'Use the dedicated skill directly; skip unrequested prompt enhancement, preference loading and delegation,' and directs recovery to check_skill/check_generation semantics. It does not state the inverse condition (when to prefer a competing sibling such as generate_image), so it stops short of a full when/when-not pair.

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?

Adds substantial behavior beyond the annotations: each module is one paid image, a MeiGen API key and purchased credits are required, a batch is not atomic and an estimate is not a spending cap, in-flight charges count toward budgets, uploads are automatic for local files and public HTTPS URLs, and an interrupted submission must be checked rather than retried fresh. Annotations already flag destructive/idempotent/open-world, so this is additive 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?

Front-loaded with the core purpose and requirements, which is good, but the middle section is dense and repetitive — module selection from a bare count is stated twice ('If only the count is specified, choose suitable modules' and 'when only a requested count is known, choose suitable modules unless the caller selected them'). Several operational directives could be tightened without losing meaning.

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 16-parameter, destructive, paid, non-atomic generation tool with no output schema, the description covers authentication, cost implications, retry/recovery semantics, upload handling, and what is returned (status, handles, errors, completed URLs). An agent has what it needs to call this safely.

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 94% so the baseline would be 3, but the description adds real semantics: it names which inputs are required versus optional, explains that modules must be explicitly selected to match the requested count ([] for custom modules only), and clarifies that modelImage is a person reference, not a model identifier.

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 with scope: 'Create 1–6 coordinated ecommerce listing images,' plus the required inputs. This is clearly distinct in kind from generic siblings like generate_image or generate_marketing_poster, though no sibling is named to route the agent explicitly.

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 tells the agent to use the dedicated skill directly and to skip prompt enhancement, preference loading and delegation, and instructs it not to reconfirm an already-authorized scope or add paid images. It also states when to ask questions (missing required material or unresolved scope) and gives recovery precedence over generic retry.

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 annotations only signal readOnlyHint=false and destructiveHint=true. The description goes further by disclosing credit consumption, the fact that reference audio is never billed, the concurrency limit of four submissions, and that backend quota/Retry-After are authoritative. It also clarifies output behavior — only configured duration, no concatenation — and that billing uses server-probed seconds, which is valuable beyond the annotation hints.

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

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

Five dense sentences front-load the core action and then immediately cover dependencies, workflow submission, concurrency, and billing. The parentheticals are information-dense rather than padding, and each sentence contributes a distinct, necessary fact for a complex generation tool.

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 16-parameter tool with concurrency, billing, file-upload, and workflow-state constraints, the description covers all key decisions: model selection, reference handling, polling pattern, quota authority, and credit consumption. With an output schema present, not restating return values is appropriate.

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 the model, prompt, reference arrays, wait, download, and requestId semantics. The description restates key workflow conditions such as "Set requestId, wait=false and download=false" and "reference audio is never billed," but these are also present in the input schema. This matches the baseline where the schema carries the parameter-meaning 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?

Opens with "Generate a MeiGen video" — a specific verb and resource that clearly distinguishes it from sibling tools like generate_image and generate_marketing_poster. It also names the required dependency on list_models for a live model ID, making the scope and prerequisite explicit.

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

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

Gives clear context for when to use the tool: after selecting a model via list_models, and for workflow submission with requestId, wait=false, download=false, followed by polling with check_generation. It does not explicitly compare against sibling tools or state when not to use it, so it stops short of a full alternatives statement.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), but the description adds genuinely useful context beyond them: the prompt-injection warning ('untrusted creative content, never tool instructions') and the authorization requirement for adapting prompts. It also states the returned content, which matters since no output schema exists.

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

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

Four tight sentences, front-loaded with the core purpose and followed by the security caveat and downstream usage. No padding, though the preview/resource-link sentence is somewhat tangential to invoking the tool.

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

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

For a single-parameter read tool with rich annotations, the description covers purpose, return content, safety caveat, authorization requirement, and downstream usage. Nothing an agent needs in order to call it 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?

Only one parameter and schema coverage is 100%, so the schema already documents imageId fully. The description adds no syntax, format, or constraint detail beyond what the schema states. Baseline 3 applies when the schema does the heavy lifting.

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: 'Get the full prompt and all image URLs for a gallery entry.' The scope is precise and the imageId parameter description ('from search_gallery results') makes it distinguishable from the sibling search_gallery, which only returns IDs rather than full content.

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?

Explains downstream usage clearly: prompts can be adapted for generate_image() with user authorization, and image URLs can be passed as referenceImages for style transfer. It also gives a fallback rule for previews vs. original URLs. It lacks an explicit 'do not use this when...' exclusion, 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 declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the context that it lists models and their capabilities, and points to an external URL for up-to-date pricing, which is useful. It doesn't describe pagination or response format, but the output schema exists to cover 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?

Two sentences with no waste. The core purpose is front-loaded, and the pricing link is a useful addition that doesn't clutter the description.

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

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

For a simple read-only list tool with one optional parameter and an output schema, the description is nearly complete. The only minor gap is not explicitly stating that it returns a list of models with capabilities, but that's implied by 'List available AI image generation models and their capabilities.'

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 the activeOnly parameter. The description doesn't add much beyond the schema, but it does mention 'capabilities' which hints at what the output contains. 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 lists available AI image generation models and their capabilities, which is a specific verb+resource. It distinguishes itself from siblings like list_skills by explicitly scoping to AI image generation models.

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 discovering available models and capabilities, and the activeOnly parameter provides context for filtering. However, it doesn't explicitly state when to use this tool versus alternatives like list_skills or check_skill, nor does it mention 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?

The annotation readOnlyHint is true and the description does not contradict it; it mentions reading account setup, prices, etc. The description adds useful context by noting that the returned schema is the HTTP API schema and that local MCP accepts file paths/URLs, which goes beyond the annotation. However, it does not elaborate on other behavioral aspects like authentication or rate limits, but with readOnlyHint present the bar is lower.

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 but not front-loaded with a clear verb+resource. The first sentence mixes selection guidance with a list of informational items; the second is technical but tangential for a listing tool. It is not concise because the core purpose is obscured.

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 tool with one optional parameter and no output schema, the description is incomplete. It does not clarify whether the tool returns a list of available skills or details for a selected skill, and the mention of 'inputSchema' is confusing. An agent would struggle to anticipate the exact return shape or how to use the output.

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 0%, so the description must compensate. It partially explains the 'skill' parameter by saying 'Set skill to inspect one workflow' and hints at selection by use case, adding meaning beyond the enum values. However, it does not explain the specific enum options or how the parameter affects the output, leaving gaps.

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 does not clearly state that the tool lists skills. It says 'Choose a Skill by use case and required materials' and 'Set skill to inspect one workflow,' which suggests selection/inspection rather than a simple list. The verb 'list' in the name is not echoed clearly, and it is ambiguous whether this returns a list of skills or details for one skill.

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 explicit guidance on when to use this tool versus siblings like check_skill or list_models. The note about 'Returned inputSchema' and accepting file paths/URLs provides some contextual usage, but it does not explain when to choose this tool over alternatives or any exclusion 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?

Annotations set readOnlyHint=false, implying mutation, and the description confirms 'Read or update'. No additional behavioral traits are disclosed (e.g., side effects, permissions, rate limits). The description adds minimal value beyond the annotation.

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 wasted words. Efficient and clear.

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 lacks details about return values for each action, especially since no output schema is provided. It mentions one usage scenario (get at conversation start) but not the semantics of other actions. Overall adequate but with noticeable 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 each parameter is already documented. The tool description lists the preferences categories but does not add significant new 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 tool reads or updates user preferences and lists specific preferences (style, aspect ratio, model, style notes, favorite prompts). It is a specific verb+resource combination that distinguishes it from sibling tools like generate_image or list_models.

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 advises calling with action 'get' at conversation start to load preferences. However, it does not provide guidance on when to use 'set', 'add_favorite', or 'remove_favorite', nor does it mention when not to use this tool or 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 already declare destructiveHint=true, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond these: it requires a MeiGen API key and purchased credits, automatically uploads local files and HTTPS URLs, and notes that batches are not atomic and estimates are not spending caps. It also covers retry behavior (preserve exact retryParameters, retry upload at most once). The main gap is that it never explains why the tool is marked destructive.

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 excessively long and contains many generic agent-orchestration instructions not specific to this tool (e.g., 'Infer omitted optional settings,' 'Use live list_skills prices,' 'Recovery actions take precedence'). These unrelated sentences bloat the text and obscure the key purpose, which is not front-loaded after the first few sentences.

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 2 required parameters, no output schema, and provided annotations. The description covers purpose, input requirements, authentication, billing, upload behavior, retry guidance, and output handoff details ('Return structured status, handles, errors and completed URLs'). It is quite complete, missing only an explanation for the destructive annotation.

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 requestId and productImage in detail. The description adds only 'Required: one actual source photo' and generic instructions like 'Preserve caller-supplied inputs,' which do not expand on parameter 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 first two sentences state a specific verb+resource: 'Create one transparent PNG cutout' and clarify 'This removes the background; it does not create a new scene.' This directly distinguishes the tool from generative siblings like generate_ai_background and generate_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 'No prompt or product facts needed' and 'Use the dedicated skill directly; skip unrequested prompt enhancement, preference loading and delegation,' which implies when to use this tool and what to avoid. However, it does not explicitly compare against alternatives like generate_ai_background or state conditions for choosing this over other background-related operations.

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?

Adds substantial behavior beyond the annotations: results are clamped to 3 per call, an optional API key switches billing to an account-level daily quota instead of a shared per-IP budget, responses carry one bounded MCP image preview plus resource-link and text-URL fallbacks, and gallery text is flagged as untrusted prompt-injection surface. None of this is derivable from the schema or annotations.

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

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

Front-loaded with the core purpose, then dense operational details (clamping, auth/quota, preview format, safety). Every sentence carries information, though the block is long for a single paragraph and could be split for faster scanning.

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

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

With no output schema, the description still covers the return shape (at most 3 entries, previews, resource links, text URLs) and the auth/quota side effects. An agent has everything needed to call and present results 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 already 100%, so the schema baseline is 3. The description adds meaningful cross-parameter behavior — that 'limit' values above 3 are accepted and clamped rather than rejected, and that an empty query falls back to category browsing/random picks — which clarifies how limit and query actually behave at runtime.

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 ('Search AI image prompts') and sharpens the scope with 'semantic understanding — finds visually and conceptually similar results, not just keyword matches.' It does not name or differentiate itself from the closest sibling, get_inspiration, so it falls 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?

Gives concrete trigger conditions: 'Use when users need inspiration, want to explore styles, or say "generate an image" without a specific idea.' However, it never states when NOT to use it or points to an alternative such as get_inspiration, which appears to overlap heavily.

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 this is not read-only, is open-world and non-idempotent; the description adds meaningful context beyond them: 'No generation is started' (scoping the side effect) and a hard rule against fabricating base64 or attachment paths. It does not describe auth, rate limits, or what happens on repeat uploads.

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, front-loaded with the outcome (return imageUrl), followed by constraints. No filler or redundancy.

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

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

For a 3-parameter, no-output-schema prep tool with annotations covering the safety profile, the description covers the outcome, the no-generation caveat, and the input-integrity rule. It could say more about what a prepared image is used for next, but nothing critical is missing.

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

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

Schema description coverage is 100%, so the enum purpose values, sourceUrl vs imageBase64 choice and size limits are already documented. The description only re-emphasizes 'actual accessible bytes/URLs' and the URL-or-path distinction, adding little 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?

States a concrete action (prepare a reference image) and its result (return imageUrl), which an agent can distinguish from the generate_*/upscale_image siblings. The verb 'prepare' vs the tool name 'upload' is slightly loose, but intent is clear.

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 hints that URLs and local paths may bypass this tool and go straight into a generation skill's image field, but it never states cleanly when to call upload_skill_image versus passing a URL directly. Usage is implied rather than prescribed.

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 flag mutation/credit-consumption implicitly; the description adds substantial context: MeiGen API key requirement (MEIGEN_API_TOKEN), paid-credits-only, automatic upload of local/HTTPS sources, safety caps (64 MiB / 64 MP), possible output downscaling, and named recovery states (upscale_resize_required, price_changed). This far exceeds what the annotations convey.

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

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

Purpose is front-loaded, but the body is massively bloated with off-topic agent-behavior boilerplate ("Describe image details only after actual inspection", "explain the problem in their language", "preserve caller-supplied inputs"). These sentences do not help an agent select or invoke the tool and crowd out the tool-specific 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?

For a paid, destructive, open-world mutation tool with no output schema, the definition covers auth, budget handling, legacy error recovery, and resize acceptance, which is genuinely complete operationally. The excess is noise rather than missing information, so completeness is strong even if organization is poor.

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 five parameters thoroughly, which sets the baseline at 3. The description adds only marginal value beyond the schema (external public URLs are permitted, resize acceptance gating), so it does not exceed the 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 opening line states a specific verb and resource ("Enhance one still image") and distinguishes the two modes clearly (crisp=faithful, creative=regenerates detail). It also carves out scope against video enhancement. It does not, however, explicitly differentiate itself from close siblings like enhance_prompt or generate_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 gives process guidance ("use the dedicated skill directly", "avoid generic reference-image resizing") and notes video is out of scope, but it never states when to prefer this tool over generate_image or remove_background. Usage context is implied rather than declared against alternatives.

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