Skip to main content
Glama

Remove background from image (Recraft + fal.ai BiRefNet v2 fallback)

aetherwave_remove_background

Strips the background from an image, returning a PNG with transparent alpha. Pass a public imageUrl. Useful for product shots, character cutouts, logo isolation, or compositing onto a new background. ~5 credits per image. Recraft is the primary provider; on outage the tool auto-falls back to fal.ai BiRefNet v2 so single-image calls never silently fail. Works best on photographic subjects (people, products, animals); transparent-PNG inputs have no foreground to segment.

Returns within ~45 s. If the result has state "running" the job is still rendering: poll aetherwave_get_job with the returned taskId and kind every ~10 s. Pass wait:true ONLY if your MCP client permits tool calls longer than 60 s (most do not). Pass async:true to get the taskId back immediately without waiting.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoBlock until the job finishes (up to the tool's full budget, 6-15 minutes). ONLY if your MCP client permits tool calls longer than 60 s; most abandon the call at 60 s and lose the taskId. Default false: return within ~45 s and hand back a taskId if still running.
asyncNoSubmit and return the taskId immediately without polling at all. Then poll aetherwave_get_job(taskId, kind).
imageUrlYesPublic URL of the source image.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / async
      Added value: +{
      +  "description": "Submit and return the taskId immediately without polling at all. Then poll aetherwave_get_job(taskId, kind).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / wait
      Added value: +{
      +  "description": "Block until the job finishes (up to the tool's full budget, 6-15 minutes). ONLY if your MCP client permits tool calls longer than 60 s; most abandon the call at 60 s and lose the taskId. Default false: return within ~45 s and hand back a taskId if still running.",
      +  "type": "boolean"
      +}
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Far exceeds the annotations (readOnlyHint=false, openWorldHint=true): discloses cost (~5 credits/image), provider fallback behavior on outage, expected runtime (~45 s), the 'running' state and taskId handoff, and client-timeout risk for wait:true. These are exactly the operational traits an agent needs and none are in the structured fields.

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

Conciseness4/5

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

Front-loads purpose, then usage, then behavior in a tight two-paragraph structure with no filler. Slightly dense in the second paragraph, but every sentence carries actionable information.

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

Completeness5/5

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

Despite no output schema, the description explains the return shape (PNG on success; taskId + 'running' state on incomplete jobs), the polling contract, and the timeout constraint. An agent has everything needed to invoke and follow up correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds value beyond the schema: it stresses that most clients cannot tolerate >60 s calls, names the ~10 s polling interval, and references the 'kind' argument for aetherwave_get_job, which the schema only mentions in passing.

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

Purpose5/5

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

States a specific verb and resource ('strips the background from an image'), names the output format ('PNG with transparent alpha'), and lists concrete use cases. It is clearly distinguishable from the sibling aetherwave_remove_background_video and from editing/upscaling tools.

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

Usage Guidelines5/5

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

Gives explicit use cases (product shots, cutouts, logo isolation), an explicit when-not ('transparent-PNG inputs have no foreground to segment'), and routes the agent to aetherwave_get_job for polling with a concrete interval. The wait:true vs async:true tradeoff is spelled out with the condition that selects each.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources