museav-mcp

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

With no annotations provided, the description carries the full burden. It usefully discloses the auth requirement (no login), processing location (local), implementation library (sharp), and default output behavior (same directory as <name>-min.<format>). It does not explicitly mention whether the original file is preserved or whether existing output files are overwritten, but the default filename strongly implies a new file is created.

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 entire description is one compact sentence with no unnecessary words. It front-loads the core action and then packs auth, locality, and default output into a short clause. Every phrase earns its place.

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

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

For a simple image-compression tool with five fully documented parameters and no output schema, the description plus schema covers the essential invocation details: purpose, input, output location, format options, and sizing/quality controls. The lack of an explicit return-value description is a minor gap but the predictable output filename mitigates it.

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 description does not need to compensate for undocumented parameters. The schema already describes file, out, format, maxEdge, and quality. The description adds only the default output path behavior, which is useful but not a significant expansion beyond the schema.

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

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

The description states a specific verb ('compress'), a resource ('image'), and a concrete scope ('local, sharp, no login'), which immediately distinguishes it from the sibling tools (gen_background, remove_bg, upscale_image, remove_watermark). The default output naming convention adds further precision. An agent can confidently identify this as the local image-compression tool.

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

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

The description makes clear when to use it: for local image compression without authentication, using the sharp library. It provides context about the local/no-login nature of the operation but does not explicitly name alternatives or state when not to use it, which prevents 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It usefully notes that the tool is online and requires login, and the verb '生成' indicates it creates new assets rather than modifying existing ones. However, it does not describe output behavior, potential waiting times, video-vs-image behavioral differences, or failure modes, leaving significant behavioral gaps.

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

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

The description is a single compact sentence that front-loads the action, names the platform, enumerates the output types, and adds the operational constraint '在线，需登录'. There is no filler; every segment contributes to a quick understanding of 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?

With 10 parameters, zero required parameters, no output schema, and no annotations, the description carries a heavy burden to explain the overall invocation model, return values, and default behavior. It only gives a high-level capability statement and a login requirement, leaving ambiguity about what happens after generation, how video generation is triggered or awaited, and which parameter combinations are valid. The schema is rich, but the surrounding operational context is too thin.

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 itself adds little parameter-level meaning; it merely hints at video and general-image outputs that relate to 'video' and 'prompt'/'skill'. Since the schema already documents all parameters thoroughly, the description does not need to compensate here.

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

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

The description clearly states the verb '生成' (generate) and the resources: wallpaper backgrounds, general images, or videos via the MUSE AV platform. This distinguishes it from the sibling tools (remove_bg, upscale_image, remove_watermark, compress_image), which are all post-processing operations rather than generation.

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

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

The usage is implied: use this tool when generating wallpaper, general images, or video. However, it does not explicitly state when to use this tool versus the sibling alternatives, nor does it give exclusion conditions or guidance on choosing among skill/template/prompt modes. Some guidance exists in the schema, but the description itself stops at implication.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the output format (alpha PNG) and the default model (ISNet), but does not disclose important behaviors such as processing time, file size limits, input format constraints, failure modes, or whether the operation is destructive to the input file. With zero annotation coverage, this is a notable gap.

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

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

A single compact sentence that front-loads the core action (抠图去背景), then packs the key differentiators (models, auth-free, output format) without any filler. Every element earns its place.

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

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

For a single-required-parameter tool with a complete schema and no output schema, the description is reasonably complete: the agent knows the action, the models, the output format, and that no login is required. Missing behavioral context—such as expected runtime, input restrictions, or edge cases—prevents a higher score, but the core call path is clear.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters (out, file, model), including the enum for model and the default naming convention. The description adds the default model ('isnet 默认') and the alpha-PNG output detail, but these are minor additions since the schema carries the parameter meanings.

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

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

The description states a specific verb ('抠图去背景') and resource (local image, with named models ISNet/U2Net and an alpha-PNG output). It clearly identifies what the tool does and distinguishes it from a remote service by noting '免登录' (no login required) and local processing. It could be slightly more explicit about the resource being an image file, but the verb-and-resource clarity is solid.

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

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

The description implies when to use the tool: to remove backgrounds locally without authentication. It lists no explicit alternatives or exclusions, but the '免登录' note suggests a context where no account/API key is needed. No explicit guidance on when NOT to use it or which sibling tools to prefer, leaving some inference required.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals meaningful traits: works locally, requires no login, uses LaMa inpainting, automatically locates watermarks, and allows manual masks for difficult cases. This goes beyond a simple 'removes watermarks' statement.

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

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

A single, compact sentence packs in the core purpose, technical method, access mode, and the auto-detection versus manual mask distinction. Every clause earns its place with no filler.

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

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

For a 3-parameter tool with no output schema, the description plus schema cover the function, the behavior, and the output path default. It could be richer with explicit when-not-to-use scenarios or input format constraints, but nothing essential 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?

The input schema already documents all 3 parameters with 100% coverage, including the fact that mask skips auto-detection. The description's mention of auto-locating and mask use for complex scenes slightly reinforces parameter behavior but adds minimal new semantic value beyond the schema.

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

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

The description clearly identifies the action (remove watermark), the method (LaMa inpainting), and key attributes (local processing, no login). It distinguishes itself from sibling tools like remove_bg (background removal) and upscale_image by targeting watermarks specifically.

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

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

Usage is implied: use when an image has a watermark, and use a mask for complex scenes. However, there is no explicit guidance on when not to use this tool or how it compares to alternatives like remove_bg for image cleanup tasks.

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

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

With no annotations provided, the description carries the full transparency burden. It adds useful behavioral context: local processing, GPU-based acceleration via Vulkan, no login required, and PNG output. It does not disclose failure cases or side effects, but the core operational traits are present.

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

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

One dense, front-loaded sentence that commicates the essential purpose, backend, authentication requirement, default behavior, and output format with no filler. Every segment earns its place.

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

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

Given four parameters, no output schema, and no annotations, the description covers the key operational context: local execution, GPU requirement, no login, default scale, and output format. Minor gaps remain around default model choice and error behavior, but the schema covers the parameters thoroughly.

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 a baseline of 3 applies. The description goes slightly beyond the schema by specifying '输出 PNG', which clarifies the format of the out parameter, and '默认 4x', which reinforces the scale default. This adds meaningful value beyond the schema.

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

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

The description states a specific action (super-resolution upscaling), resource (image), engine (Real-ESRGAN + Vulkan), and output behavior (default 4x PNG). This clearly separates it from sibling tools like remove_bg, remove_watermark, and compress_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 purpose and sibling names imply that upscale_image is for enlarging/enhancing images rather than background removal, watermark removal, or compression. However, there is no explicit guidance about when to choose this tool over alternatives or when not to use it.

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