MeiGen AI Image Generation MCP

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

Annotations already include readOnlyHint=true, and the description adds value beyond that by guaranteeing no new charges and explaining that requestId lookup survives restarts and host changes. It also instructs the agent to follow structured status and nextAction, giving practical behavioral guidance.

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 concise sentences, each earning its place: purpose, identifier rule, recovery scenario, and action guidance. The most important information is front-loaded, with no redundant 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 output schema, full parameter documentation, and readOnly annotation, the description covers the essential operational details: what the tool reads, how to identify the job, recovery scenarios, and a caution against unnecessary paid actions. Nothing critical is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful semantic guidance by clarifying the OR relationship between generationId and requestId and explaining when requestId lookup is valuable, which is not fully captured in the schema. It does not add much for requestedMediaType, but the schema already documents that parameter well.

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 sentence states a specific action and resource: 'Read an existing MeiGen job without new charges.' This clearly distinguishes a read/status operation from the generation siblings like generate_image and generate_video, and clarifies the non-billing aspect upfront.

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 concrete when-to-use context: after a lost submit response, process restart, or another host. It also explicitly warns against converting an uncertain status into a new paid UUID, effectively telling the agent when not to fall back to generation.

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 provide readOnlyHint=true, and the description meaningfully extends this with 'No new charges,' concrete retry timing, and a conditional recovery rule. This gives the agent operational expectations beyond the structured 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?

Three compact sentences, front-loaded with the core read behavior and side-effect note, followed by precise polling and recovery rules. No filler; the closing instruction about resource links adds actionable output 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?

Even without an output schema, the description covers what the response should surface ('Show completed resource links'), how to poll, when to stop polling, and how to handle retryable versus non-retryable failures. The remaining gap is explicit parameter guidance, already penalized separately.

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 names or explains the two parameters, skill and requestId. It implies a request context via 'retry_request, with its exact parameters,' but does not clarify that requestId identifies the operation or how skill selects the resource, leaving the agent to rely solely on field names and enum values.

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

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

Description states a specific verb ('Read') and resource ('skill images, partial failures and refund states'), and clarifies the operation has no side effects ('No new charges'). It does not explicitly contrast with sibling check_generation, but the skill-specific wording makes the tool's role 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?

Provides explicit polling instructions: 'wait afterSeconds before polling (normally 10s)' and 'recover only when it says retry_request, with its exact parameters.' It also directly handles when-not-to-poll by stating that payment/auth/input failures and daily limits require a different action instead of polling.

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?

No annotations are provided, so the description carries the full disclosure burden and meets it thoroughly: it discloses authentication requirements (MEIGEN_API_TOKEN or saved local config), purchased-credit gating, automatic upload of local files and HTTPS URLs, non-atomic batch behavior, lack of a server-enforced spending cap, exact retry semantics (same requestId, at most one retry after suggested wait), and recovery-action precedence over generic retry advice.

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 core purpose is front-loaded and the opening sentences are tight, but the description becomes a dense wall of operational policy — budget planning, requestId persistence, user-interaction language, and progress ownership — with some redundancy (e.g., asking only for missing material vs. explaining problems to the user). Most sentences carry information, but the length strains conciseness.

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 6-parameter tool with no annotations and no output schema, the description is unusually complete: it covers auth, cost accounting, upload behavior, retry/recovery semantics, and return expectations ('structured status, handles, errors and completed URLs'). The only minor gap is that it doesn't describe the concrete shape of the success/failure return structure, but it says the caller owns presentation, which covers the essentials.

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, and the description adds real value on top: mode/customPrompt interdependence ('custom=customPrompt required'), ratio and quality being smart/custom-only and ignored in white mode, and nuanced productImage semantics (do not pre-remove background, no credentials/fragments/custom ports, GIF first frame, never invent paths). This exceeds the baseline meaningfully.

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 sentence states a specific verb and resource — 'Create one product photo with a new background' — and the three modes (white/smart/custom) are clearly enumerated. It distinguishes itself from siblings by explicitly naming remove_background for transparent PNG cutouts, so an agent can differentiate it without opening schemas.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: 'Use remove_background for transparent PNG cutouts', 'Use the dedicated skill directly; skip unrequested prompt enhancement, preference loading and delegation', and 'Use live list_skills prices'. It also directs recovery flows to check_skill and names the sibling for pricing lookups, leaving little to inference.

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

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

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?

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses authentication/credit requirements, automatic file uploads, non-atomic batch behavior, retry semantics, budget estimation caveats, and the caller's ownership of progress and presentation. It also warns against inventing event details or describing images before actual inspection.

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

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

The description is front-loaded with purpose and essential constraints, and the guidance is topically organized from scope to prerequisites to execution to recovery. However, it is a long single paragraph with some operational details that could be condensed or split for easier scanning, though virtually every sentence carries actionable information.

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

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

For a complex tool with 14 parameters and no output schema, the description covers the full call lifecycle: prerequisites, file upload, budget planning, retry handling, caller responsibilities, and response shape. It also correctly points to list_skills for dynamic details like prices, ratios, and style options, leaving no critical gap for an agent to 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%, so the baseline is 3; the description adds meaningful semantic guidance beyond the schema by explaining copy preservation rules, omitted-setting inference, confirmation boundaries, and requestId reuse/retry behavior. It does not redefine every parameter, but it clarifies how parameter choices should be made in context.

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

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

The description opens with a specific verb and resource: 'Design one poster for a brand, shop, event, promotion or topic.' It clearly states the tool's unique scope (a single poster) and differentiates it from generic image generation by noting an image is not required and the service plans the layout and writes the prompt.

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

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

The description gives clear context: use the dedicated skill directly, skip prompt enhancement, preference loading and delegation, and ask only for missing required material. It does not explicitly name sibling alternatives like generate_image for non-poster requests, but it does define the tool's boundaries and prerequisites, including API key and purchased credits.

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 of behavioral disclosure, and it does so extensively. It discloses that each module creates one paid image, that batches are not atomic, that estimates are not spending caps, that uploads are automatic, that retries should preserve retryParameters, and that recovery actions take precedence over generic retry advice. It also explains the requestId reuse semantics and that image details should only be described after actual inspection.

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 information-dense and front-loaded with the core purpose, but it is quite long and covers many operational details that could arguably live in a separate workflow document. Every sentence does add some value, but the density makes it harder to parse quickly. It is structured as a block of prose rather than scannable sections, which hurts usability for an agent.

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 paid-image-generation tool with 16 parameters, no annotations, and no output schema, the description is remarkably complete. It covers required inputs, optional inputs, pricing/credit behavior, retry semantics, error recovery, caller responsibilities, and user interaction guidelines. The only minor gap is that it doesn't describe the exact return structure, but it explicitly says it returns 'structured status, handles, errors and completed URLs,' which is sufficient given no output schema exists.

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 94%, so the schema already documents most parameters well. The description adds meaningful context beyond the schema: it explains the relationship between modules and count ('MCP calls must explicitly select modules to match that count'), clarifies that quality selects rendering quality not resolution, and emphasizes that productName and sellingPoints must not be invented. It doesn't add per-parameter syntax details, but the schema already covers those.

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

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

The description opens with a specific verb and resource: 'Create 1–6 coordinated ecommerce listing images.' It clearly distinguishes this tool from siblings like generate_marketing_poster or generate_ai_background by focusing on coordinated listing images with modules. It also names the dedicated skill and explicitly says to skip delegation, which further differentiates it.

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

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

The description gives explicit when-to-use guidance: 'Use the dedicated skill directly; skip unrequested prompt enhancement, preference loading and delegation.' It also states when to ask the user ('Ask only for missing required material or unresolved scope') and when not to reconfirm scope. It references list_skills for prices and check_skill for interruptions, providing clear alternatives and recovery paths.

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 declare readOnlyHint=true, so the tool is safe. Description adds that it returns full prompt and image URLs and suggests showing images to users, which is helpful context beyond annotations.

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

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

Three concise sentences that front-load the main action and provide immediate value with downstream usage tips. No redundant or extraneous 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 simple retrieval tool with one parameter and no output schema, the description fully explains what is returned and how to use it in conjunction with sibling tools. 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 the single parameter imageId. The tool description does not add further detail about the parameter, so baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves the full prompt and all image URLs for a gallery entry, distinguishing it from search_gallery (which lists entries) and generate_image (which creates 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?

Provides direct guidance on using the prompt with generate_image() and image URLs as referenceImages for style transfer, and implies it should be used after selecting an entry from search_gallery. Lacks explicit when-not-to-use, but context is clear.

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

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

Annotations 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so extensively: it discloses upload behavior (local files and public HTTPS URLs uploaded automatically), auth requirements (MeiGen API key, MEIGEN_API_TOKEN or saved config), credit requirements (purchased credits only), retry semantics (at most once after suggested wait, preserve retryParameters), batch non-atomicity, and the fact that estimates are not spending caps. It also discloses that files are decoded, metadata removed, and GIF uses the first frame. The only minor gap is that it doesn't explicitly state the output format beyond 'transparent PNG cutout' and 'completed URLs', but the description is unusually 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 information-dense and front-loaded with the core purpose, but it is quite long and includes a large amount of operational policy (budget planning, recovery actions, caller ownership of progress) that, while valuable, could be trimmed or moved to a more structured location. Every sentence does earn its place in terms of content, but the sheer length makes it harder to parse quickly. It's not bloated with fluff, but it's at the edge of what an agent can absorb efficiently.

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

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

For a tool with 2 parameters, no output schema, and no annotations, the description is remarkably complete. It covers input requirements, auth, upload behavior, retry semantics, error handling, caller responsibilities, and interaction guidance. An agent has everything it needs to invoke this tool correctly and handle failures appropriately. The only thing not specified is the exact response shape, but the description says it returns 'structured status, handles, errors and completed URLs', which is sufficient given no output schema exists.

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

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

Schema coverage is 100%, so the schema already documents both parameters well. The description adds meaningful context beyond the schema: it clarifies that productImage must be an actual source photo containing the subject, that relative paths are rejected, that files are decoded and metadata removed, and that GIF uses the first frame. It also reinforces the requestId reuse semantics. This goes beyond the baseline 3 by adding operational meaning to the parameters.

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

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

The description opens with a specific verb and resource: 'Create one transparent PNG cutout' for compositing, catalog assets, or logos. It explicitly distinguishes itself from scene creation ('it does not create a new scene'), which separates it from siblings like generate_ai_background and generate_marketing_poster. The purpose is unmistakable.

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

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

The description gives explicit when-to-use guidance: requires one actual source photo, no prompt or product facts needed, and it explicitly says to use the dedicated skill directly while skipping prompt enhancement, preference loading, and delegation. It also names the alternative path (list_skills for prices, check_skill for interruptions) and clarifies when to ask the user. This is comprehensive 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?

The description discloses key behavioral traits: returns at most 3 entries per call, larger limits are clamped, and authentication affects quota counting. It also mentions that results include image URLs and instructs to render them as markdown images. The readOnlyHint annotation is consistent with the description's read-only nature, and the description adds context about quotas and clamping 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?

The description is concise and front-loaded with the core purpose, then adds key behavioral details and usage guidance. Every sentence adds value, and it is well-structured for an agent to quickly grasp the tool's function and constraints.

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

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

Given the tool's complexity (5 parameters, no output schema), the description covers the essential behavioral aspects: result limits, authentication, rendering instructions, and usage scenarios. It doesn't detail the exact response structure, but since there is no output schema, the description's mention of image URLs and markdown rendering is sufficient for an agent to use the tool effectively.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds value by explaining the semantic search capability, the clamping behavior for limit, and the browsing behavior when query is empty. It also clarifies that natural language descriptions work well, which is not in the schema.

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

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

The description clearly states the tool's function: searching AI image prompts with semantic understanding, distinguishing it from keyword-only search. It also explicitly mentions the return of image URLs and how to render them, which is a specific and actionable purpose.

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 guidance on when to use this tool: when users need inspiration, want to explore styles, or say 'generate an image' without a specific idea. It also contrasts with the shared per-IP budget and mentions authentication with MeiGen API key, giving clear context for 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?

With no annotations provided, the description carries the full burden. It adds a key safety trait ('No generation is started') and the instruction to use 'actual accessible bytes/URLs only,' which helps agents avoid invalid inputs. It does not disclose storage, lifetime, permissions, or other side effects of preparing the image, so transparency is only partial.

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 with the core purpose and return value front-loaded, followed by concise caveats about real inputs and no generation. The direct-passing note is slightly ambiguous but not padding, and the overall length is appropriate.

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 definition covers the essential contract: it returns imageUrl, does not start generation, and requires real accessible bytes/URLs. However, without an output schema or annotations, it leaves the purpose/upscale distinction and the exact relationship to direct generation partly ambiguous, so an agent may still need to infer important call context.

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

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

Schema description coverage is 100%, so baseline 3 applies. The description reinforces the no-fabrication rule and notes that external URLs/local paths can bypass the tool, but it adds little new meaning about purpose, sourceUrl, or imageBase64 beyond what the property descriptions already provide.

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

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

The description states a concrete outcome ('Prepare a reference image and return imageUrl') and explicitly distinguishes the tool from generation by adding 'No generation is started.' The verb 'prepare' is slightly vague, but the tool name, the return-value mention, and the sibling context make the resource and result reasonably 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?

The description gives partial routing guidance by noting that external URLs and local file paths 'can also be passed directly to the generation skill' and by warning against fabricated inputs. However, it never clearly states when upload_skill_image is required versus when to skip it, and the sourceUrl parameter makes the 'external URLs can be passed directly' advice ambiguous.

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 transparency burden and does so thoroughly: it discloses upload behavior, metadata removal, 64 MiB/64 MP caps, possible downscaling, non-atomic batches, quote-vs-spending-cap semantics, retry rules, requestId reuse, and the structured return contract. This goes well beyond simple 'upscale this image' and gives an agent realistic expectations of side effects and failures.

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 long, but it is front-loaded with the core purpose and then parcels planning, retry, and cost guidance into useful clauses. It earns most of its length, though a few operational policies could be tightened without losing meaning; this keeps it just shy of a 5.

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, upload-capable, retry-sensitive tool with no output schema, the description is remarkably complete: it covers prerequisites, cost handling, failure recovery, interaction boundaries, and what the caller receives. An agent has enough context to invoke it correctly and to coordinate with check_skill and list_skills.

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

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

Although schema coverage is 100%, the description enriches every parameter meaningfully: imageUrl gets path formats, size limits, and metadata behavior; requestId gets retry semantics; confirmedCredits gets quote and budget context; allowDownscale gets a clear charge-related caveat; mode gets user-acceptance considerations. This is far beyond the baseline 3 for complete schemas.

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

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

The description opens with a specific verb and resource — 'Enhance one still image' — and immediately distinguishes the two operating modes, crisp vs creative. It also explicitly separates this from video enhancement and general image generation, making it easy to differentiate from siblings like 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?

The description gives concrete when-to-use guidance: pass original public URLs, avoid generic reference-image resizing, do not use this for video, and use the dedicated skill directly rather than routing through prompt enhancement or delegation. It references check_skill and list_skills as supporting tools, though it does not explicitly name sibling tools as alternatives for similar still-image operations.

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