Poof
Server Details
Poof
Poof (poof.bg): a background removal API for AI agents. Send an image, get the subject back on a transparent background in under 2 seconds.
Poof gives your assistant a background removal tool. It handles people, products, cars, animals, and graphics, with hair-level edge precision, and returns a transparent PNG or WebP, or a solid-colour JPG for product listings. Pricing starts at $0.002 per image, with 100 free credits every month.
This repository is the integration front door. The product itself lives at poof.bg; the remote MCP server lives at https://api.poof.bg/mcp.
What you can build with it
Transparent cutouts: remove the background from any JPG, PNG, or WebP up to 20MB and 36 megapixels with the Background Removal API.
E-commerce product photos: white or brand-colour backgrounds, cropped to the subject and resized to a fixed canvas, so every listing image matches.
A remove.bg replacement: remove.bg shuts down on 1 December 2026. Poof accepts the same inputs, so most integrations only change the endpoint and key. See the remove.bg alternative and migration guide.
Agent image pipelines: let Claude, ChatGPT, or Cursor clean up images mid-conversation, or automate it with n8n, Zapier, and Make.
Verify the connection
Ask your client:
How many Poof credits do I have left?
You should see a get_account tool call and your real plan and balance. Then try:
Remove the background from https://example.com/product.jpg and give me a white background JPG.
What the tools do
The server exposes 2 tools.
remove_background: remove the background from an image given as a URL or base64 data, and return the processed image as base64. Optional parameters control the result:format:png(default),jpg, orwebp.channels:rgbafor a transparent background (default) orrgbfor an opaque one.bg_color: fill colour for opaque output, as hex, RGB, or a colour name.size:full(default),preview,medium, orhd. Ignored whenwidthorheightis set.crop: crop to the subject bounds.widthandheight: 1 to 6000 pixels. Set one and the other follows the aspect ratio.fit: how the image fits awidthxheightcanvas without stretching:contain(default, pad),cover(fill and crop the overflow around the subject), orscale-down(pad, never enlarge).
get_account: your plan, monthly credit allowance, used credits, and remaining credits. No parameters.
Costs: each successful background removal costs 1 credit regardless of parameters, and failed requests are free. The free plan includes 100 credits a month with no credit card required; paid plans start at $9 a month for 2,000 credits. The pricing page has the details.
Privacy: Poof is run by an EU company and is GDPR compliant. Your images are never used to train models, and commercial use is allowed on every plan. See the privacy policy.
Or skip MCP
The same capability is a single REST call, with official Python and TypeScript SDKs:
To try it without writing code, use the playground. The quickstart and the Node.js tutorial cover the first integration.
For AI agents reading this
Docs index: docs.poof.bg/llms.txt
MCP setup guide: docs.poof.bg/integrations/mcp
API reference: docs.poof.bg/api-reference/remove-background
Hosted endpoint:
https://api.poof.bg/mcp(OAuth)Source: github.com/poof-bg/mcp
Docs and support
Connect guide (per-client, kept current)
Best background removal APIs for developers and free background removal APIs compared
Questions: support@poof.bg
- Status
- Healthy
- Uptime
- 100.0% over 22 days
- OAuth
- Works in Glama
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
Scored across 4 tools
Each tool targets a distinct resource and action: get_account for billing, get_job for async job status, remove_background for still images, and remove_video_background for videos/animated GIFs. The descriptions preempt the only potential confusion (still GIF vs animated GIF) by explicitly directing animated GIFs to remove_video_background.
All four tools follow a consistent snake_case verb_noun pattern (get_account, get_job, remove_background, remove_video_background). The get_* and remove_* prefixes map predictably to retrieval vs processing actions.
Four tools is well-scoped for a focused background-removal service: credit check, image processing, video processing, and job polling. Each tool earns its place with no redundancy or filler.
Core workflows are covered: check credits, remove image background, remove video background, and poll job status with result URL. Minor gaps exist—no job cancellation or listing tool, which would be useful given video jobs are costly and can be long-running.
Available Tools
4 toolsget_accountGet Poof AccountARead-onlyIdempotentInspect
Get the Poof account's plan and credit usage: maxCredits, usedCredits and remainingCredits for the current billing cycle. Free; use it to check whether there are credits left before processing many images.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds non-obvious context: the call is free and the credits reported are scoped to 'the current billing cycle.' It does not mention rate limits or auth requirements, but for a read-only account query those are minor.
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 tight sentences, front-loaded with the resource and payload, then the practical reason to call it. Every clause earns its place and nothing is repeated from the annotations.
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 and no parameters, the description carries the burden of saying what comes back, and it does so by naming the three credit fields and their billing-cycle scope. Nothing an agent needs to invoke this 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?
Zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description appropriately spends its words on the return values instead.
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 Poof account's plan and credit usage') and even enumerates the returned fields (maxCredits, usedCredits, remainingCredits). It never names or contrasts with the only sibling, remove_background, but that sibling is an obviously unrelated image operation, so ambiguity risk is low.
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 a concrete use case: 'use it to check whether there are credits left before processing many images.' That tells the agent when to reach for this tool. No exclusions or alternative tools are named, which is the only thing separating this from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jobGet Video JobARead-onlyIdempotentInspect
Get the status of a video background removal job started with remove_video_background (or by remove_background given an animated GIF). Polling is free. When status is completed the job carries result_url, a direct download link valid for 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job id returned by remove_video_background (starts with job_) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description's added value is what it says beyond them: polling carries no cost, the job surfaces result_url on completion, and that download link expires in 24 hours. The expiry window is a genuinely useful operational constraint an agent would otherwise miss; only the set of possible status values is left undisclosed.
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 tight sentences with no filler. Purpose, provenance, cost, and the completion/expiry behavior are all front-loaded in the order an agent needs them.
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 correctly carries the return-value burden, naming the result_url field and its 24-hour validity. The one gap is the enumeration of non-completed statuses, which matters for an agent writing a polling loop, but everything needed to call the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the job_id format ('starts with job_'), so the baseline is 3. The description adds provenance the schema lacks — which tools generate this id — which helps an agent confirm it is passing the right 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 ('Get the status of a video background removal job') and explicitly ties it to the originating tools, remove_video_background and remove_background. This clearly separates it from the sibling get_account and from the two removal tools that create the job.
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 the polling use case, that polling is free (a cost signal that encourages repeated calls), and what to wait for ('When status is completed'). It names the tools that produce the job_id, but does not state an explicit stop condition or what to do on failure, so it falls just short of the full when/when-not/alternatives bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_backgroundRemove Image BackgroundARead-onlyIdempotentInspect
Remove the background from an image, leaving the subject on a transparent (or solid color) background. Accepts an image URL, base64-encoded image or an image the user attached to the chat (PNG, JPEG, WebP or still GIF, up to 20 MB) and returns the processed image. For animated GIFs and videos use remove_video_background. Can also crop to the subject and resize the result to an exact width x height without stretching (width, height, fit). Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| fit | No | How to fit the image into width x height. 'contain' pads the remaining area (transparent or bg_color), 'cover' fills the canvas and crops the overflow around the subject, 'scale-down' is like contain but never enlarges a smaller image | contain |
| crop | No | Whether to crop the image to the subject bounds | |
| file | No | A image the user attached to the chat, as a file object with a download_url. Only use it when the client provides one for an attachment (ChatGPT does); never construct it. For a image at a public URL use image | |
| size | No | Output image size preset (megapixel cap). Ignored when width or height is set | full |
| image | No | Image input: a publicly accessible URL to a PNG, JPEG, WebP or still GIF image (including https://), or base64-encoded image data (optionally as a data: URL). Animated GIFs are videos: use remove_video_background. Set this or file | |
| width | No | Output width in pixels. On its own, the height follows the aspect ratio. With height, the image is fitted into an exact width x height canvas without stretching | |
| format | No | Output image format. 'jpg' has no transparency | png |
| height | No | Output height in pixels. On its own, the width follows the aspect ratio. With width, the image is fitted into an exact width x height canvas without stretching | |
| bg_color | No | Background color (hex, rgb, or color name). Setting it fills the background, so the result is opaque; with channels 'rgb' or format 'jpg' and no bg_color the background is white. Omit it for a transparent result. Ignored with channels 'alpha'. Example: '#ffffff' | |
| channels | No | Output color channels. Use 'rgba' for transparency, 'rgb' for an opaque background (bg_color, white by default), 'alpha' for the grayscale alpha mask only | rgba |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely non-structured facts: a 1-credit cost and a 20 MB input ceiling with supported formats. It also states the output is the processed image. It says nothing about latency, failure modes or how the credit is charged on failure, keeping it below a 5.
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 sentences, each carrying distinct load: core action, accepted inputs, sibling routing, and capability/cost. The primary purpose is front-loaded and there is 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 ten-parameter tool with zero required inputs, the description covers input sources, format and size limits, output nature, cost, and the sibling boundary. With no output schema, the return value is only glossed as 'the processed image' — no mention of how the result is delivered (URL vs. file object), which leaves a small but real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the description earns a bump by surfacing the optional crop-to-subject and exact width x height resize behavior (fit) that an agent could otherwise overlook among ten parameters. It does not add syntax or format detail beyond the schema, which already explains fit, channels and bg_color interactions.
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 (remove the background from an image) plus the concrete outcome (subject on transparent or solid background). It also names the sibling it is not for — animated GIFs and videos go to remove_video_background — so an agent can route correctly 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 a clear routing condition to the alternative: 'For animated GIFs and videos use remove_video_background.' It also enumerates accepted inputs (URL, base64, chat attachment) and the 20 MB cap, which frames when the tool applies. It stops short of an explicit exclusion list beyond the video case, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remove_video_backgroundRemove Video BackgroundARead-onlyInspect
Remove the background from a video given by public URL or attached to the chat. Returns a job; when wait is true (default) the tool polls for up to 50 seconds and returns the finished job with result_url (a direct download link valid for 24 hours). For longer videos call get_job with the returned job id until status is completed. Costs 5 credits per second of video, rounded up (10 per second above 30 fps; animated GIFs are always 5 per second), charged when the job is accepted and refunded if it fails.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | A video the user attached to the chat, as a file object with a download_url. Only use it when the client provides one for an attachment (ChatGPT does); never construct it. For a video at a public URL use video_url | |
| size | No | Output size preset. The longest side is capped at 640 (preview), 1280 (medium) or 1920 (hd) pixels; full keeps the source resolution up to 4096 pixels (4K) | full |
| wait | No | Poll until the job finishes (up to 50 seconds) before returning. Set to false to get the job id back immediately | |
| format | No | Output container. 'webm' (VP9) and 'mov' (ProRes 4444) keep transparency unless bg_color is set; 'mp4' (H.264) has no alpha and is composited onto bg_color; 'gif' is a looping GIF with 1-bit transparency (opaque when bg_color is set) and no audio, capped at 1280 px on the longest side (720p for widescreen) and 50 fps (large files, soft edges are hard-cut) for stickers, chat and email: use size 'preview' for sticker-sized output | webm |
| bg_color | No | Background color (hex, rgb, or color name). Setting it fills the background, so the result is opaque in every format (webm, mov and gif included); with channels 'rgb' or format 'mp4' and no bg_color the background is white. Omit it for a transparent video. Ignored with channels 'alpha'. Example: '#00ff00' for green screen | |
| channels | No | 'rgba' for a transparent video (opaque on bg_color if one is set), 'rgb' for an opaque video on bg_color, 'alpha' for a grayscale matte video (no audio) | rgba |
| video_url | No | Public https URL of the video (mp4, mov, webm, m4v, mkv or animated gif; up to 500 MB and 5 minutes). Set this or file |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint true, but this tool creates jobs and burns credits), the description discloses the credit cost formula (5/sec, 10/sec above 30fps, GIF rate), when charges occur, the failure refund, the polling ceiling, and the 24-hour expiry on result_url. That is exactly the behavioral context structured fields do not carry.
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 behavior (what it does, what it returns, cost) is front-loaded in the first two sentences, and the get_job fallback follows naturally. It is dense but every sentence carries operational weight; the cost sentence is long but 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?
With no output schema, the description still explains the return shape (a job, or a finished job with result_url valid 24 hours) and the async escape hatch. For a credit-consuming async tool with nested file input, an agent has everything needed to call it and handle the result.
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 is 3; the schema already explains size presets, formats, channels and bg_color. The description adds only marginal meaning (cost scaling tied to fps/GIF, wait semantics), largely repeating what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Remove the background from a video') and the accepted input sources (public URL or chat attachment). This implicitly distinguishes it from the sibling remove_background (presumably image-oriented), though it never names that sibling 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?
It gives explicit operating conditions: use the default wait for short jobs, switch to get_job with the returned id when the video is longer than the 50-second poll window. The file-vs-video_url choice is also covered via the schema, leaving nothing to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
remove_background3 fields changed- added
Input schema / properties / fileAdded value: +{ + "description": "A image the user attached to the chat, as a file object with a download_url. Only use it when the client provides one for an attachment (ChatGPT does); never construct it. For a image at a public URL use image", + "properties": { + "download_url": { + "description": "Temporary URL to download the file", + "type": "string" + }, + "file_id": { + "description": "Client file id", + "type": "string" + }, + "file_name": { + "description": "Original file name", + "type": "string" + }, + "mime_type": { + "description": "MIME type of the file", + "type": "string" + } + }, + "required": [ + "download_url", + "file_id" + ], + "type": "object" +} - changed
Input schema / properties / image / descriptionPrevious value: -"Image input: a publicly accessible URL to a PNG, JPEG, WebP or still GIF image (including https://), or base64-encoded image data (optionally as a data: URL). Animated GIFs are videos: use remove_video_background"New value: +"Image input: a publicly accessible URL to a PNG, JPEG, WebP or still GIF image (including https://), or base64-encoded image data (optionally as a data: URL). Animated GIFs are videos: use remove_video_background. Set this or file" - changed
Input schema / requiredPrevious value: -[ - "image" -]New value: +[]
- Changed
remove_video_background3 fields changed- added
Input schema / properties / fileAdded value: +{ + "description": "A video the user attached to the chat, as a file object with a download_url. Only use it when the client provides one for an attachment (ChatGPT does); never construct it. For a video at a public URL use video_url", + "properties": { + "download_url": { + "description": "Temporary URL to download the file", + "type": "string" + }, + "file_id": { + "description": "Client file id", + "type": "string" + }, + "file_name": { + "description": "Original file name", + "type": "string" + }, + "mime_type": { + "description": "MIME type of the file", + "type": "string" + } + }, + "required": [ + "download_url", + "file_id" + ], + "type": "object" +} - changed
Input schema / properties / video_url / descriptionPrevious value: -"Public https URL of the video (mp4, mov, webm, m4v, mkv or animated gif; up to 500 MB and 5 minutes)"New value: +"Public https URL of the video (mp4, mov, webm, m4v, mkv or animated gif; up to 500 MB and 5 minutes). Set this or file" - changed
Input schema / requiredPrevious value: -[ - "video_url" -]New value: +[]
2 tool updates
- Changed
remove_background1 field changed- changed
Input schema / properties / bg_color / descriptionPrevious value: -"Background color (hex, rgb, or color name) used when the output has no transparency (channels 'rgb' or format 'jpg'). Defaults to white. Example: '#ffffff'"New value: +"Background color (hex, rgb, or color name). Setting it fills the background, so the result is opaque; with channels 'rgb' or format 'jpg' and no bg_color the background is white. Omit it for a transparent result. Ignored with channels 'alpha'. Example: '#ffffff'"
- Changed
remove_video_background3 fields changed- changed
Input schema / properties / bg_color / descriptionPrevious value: -"Background color (hex, rgb, or color name) used when the output has no transparency (channels 'rgb' or format 'mp4'). Defaults to white. Example: '#00ff00' for green screen"New value: +"Background color (hex, rgb, or color name). Setting it fills the background, so the result is opaque in every format (webm, mov and gif included); with channels 'rgb' or format 'mp4' and no bg_color the background is white. Omit it for a transparent video. Ignored with channels 'alpha'. Example: '#00ff00' for green screen" - changed
Input schema / properties / channels / descriptionPrevious value: -"'rgba' for a transparent video, 'rgb' for an opaque video on bg_color, 'alpha' for a grayscale matte video (no audio)"New value: +"'rgba' for a transparent video (opaque on bg_color if one is set), 'rgb' for an opaque video on bg_color, 'alpha' for a grayscale matte video (no audio)" - changed
Input schema / properties / format / descriptionPrevious value: -"Output container. 'webm' (VP9) and 'mov' (ProRes 4444) keep transparency; 'mp4' (H.264) has no alpha and is composited onto bg_color; 'gif' is a looping GIF with 1-bit transparency and no audio, capped at 1280 px on the longest side (720p for widescreen) and 50 fps (large files, soft edges are hard-cut) for stickers, chat and email: use size 'preview' for sticker-sized output"New value: +"Output container. 'webm' (VP9) and 'mov' (ProRes 4444) keep transparency unless bg_color is set; 'mp4' (H.264) has no alpha and is composited onto bg_color; 'gif' is a looping GIF with 1-bit transparency (opaque when bg_color is set) and no audio, capped at 1280 px on the longest side (720p for widescreen) and 50 fps (large files, soft edges are hard-cut) for stickers, chat and email: use size 'preview' for sticker-sized output"
1 tool update
- Changed
remove_background1 field changed- changed
Input schema / properties / bg_color / descriptionPrevious value: -"Background color (hex, rgb, or color name). Only applies when channels is 'rgb'. Example: '#ffffff'"New value: +"Background color (hex, rgb, or color name) used when the output has no transparency (channels 'rgb' or format 'jpg'). Defaults to white. Example: '#ffffff'"
2 tool updates
- Changed
remove_background3 fields changed- changed
Input schema / properties / channels / descriptionPrevious value: -"Output color channels. Use 'rgba' for transparency, 'rgb' for opaque background"New value: +"Output color channels. Use 'rgba' for transparency, 'rgb' for an opaque background (bg_color, white by default), 'alpha' for the grayscale alpha mask only" - changed
Input schema / properties / channels / enumPrevious value: -[ - "rgba", - "rgb" -]New value: +[ + "rgba", + "rgb", + "alpha" +] - changed
Input schema / properties / image / descriptionPrevious value: -"Image input: a publicly accessible URL to a PNG, JPEG or WebP image (including https://), or base64-encoded image data (optionally as a data: URL)"New value: +"Image input: a publicly accessible URL to a PNG, JPEG, WebP or still GIF image (including https://), or base64-encoded image data (optionally as a data: URL). Animated GIFs are videos: use remove_video_background"
- Changed
remove_video_background2 fields changed- changed
Input schema / properties / format / descriptionPrevious value: -"Output container. 'webm' (VP9) and 'mov' (ProRes 4444) keep transparency; 'mp4' (H.264) has no alpha and is composited onto bg_color; 'gif' is a looping GIF with 1-bit transparency and no audio, capped at 720p and 50 fps (large files, soft edges are hard-cut) for stickers, chat and email: use size 'preview' for sticker-sized output"New value: +"Output container. 'webm' (VP9) and 'mov' (ProRes 4444) keep transparency; 'mp4' (H.264) has no alpha and is composited onto bg_color; 'gif' is a looping GIF with 1-bit transparency and no audio, capped at 1280 px on the longest side (720p for widescreen) and 50 fps (large files, soft edges are hard-cut) for stickers, chat and email: use size 'preview' for sticker-sized output" - changed
Input schema / properties / video_url / descriptionPrevious value: -"Public https URL of the video (mp4, mov, webm, mkv or animated gif; up to 500 MB and 5 minutes)"New value: +"Public https URL of the video (mp4, mov, webm, m4v, mkv or animated gif; up to 500 MB and 5 minutes)"
1 tool update
- Changed
remove_video_background3 fields changed- changed
Input schema / properties / format / descriptionPrevious value: -"Output container. 'webm' (VP9) and 'mov' (ProRes 4444) keep transparency; 'mp4' (H.264) has no alpha and is composited onto bg_color"New value: +"Output container. 'webm' (VP9) and 'mov' (ProRes 4444) keep transparency; 'mp4' (H.264) has no alpha and is composited onto bg_color; 'gif' is a looping GIF with 1-bit transparency and no audio, capped at 720p and 50 fps (large files, soft edges are hard-cut) for stickers, chat and email: use size 'preview' for sticker-sized output" - changed
Input schema / properties / format / enumPrevious value: -[ - "webm", - "mov", - "mp4" -]New value: +[ + "webm", + "mov", + "mp4", + "gif" +] - changed
Input schema / properties / video_url / descriptionPrevious value: -"Public https URL of the video (mp4, mov, webm or mkv; up to 500 MB and 5 minutes)"New value: +"Public https URL of the video (mp4, mov, webm, mkv or animated gif; up to 500 MB and 5 minutes)"
1 tool update
- Changed
remove_video_background1 field changed- changed
Input schema / properties / size / descriptionPrevious value: -"Output size preset. The longest side is capped at 640 (preview), 1280 (medium) or 1920 (hd/full) pixels"New value: +"Output size preset. The longest side is capped at 640 (preview), 1280 (medium) or 1920 (hd) pixels; full keeps the source resolution up to 4096 pixels (4K)"
2 tool updates
- Added
get_job - Added
remove_video_background
1 tool update
- Changed
remove_background7 fields changed- added
Input schema / properties / fitAdded value: +{ + "default": "contain", + "description": "How to fit the image into width x height. 'contain' pads the remaining area (transparent or bg_color), 'cover' fills the canvas and crops the overflow around the subject, 'scale-down' is like contain but never enlarges a smaller image", + "enum": [ + "contain", + "cover", + "scale-down" + ], + "type": "string" +} - changed
Input schema / properties / format / descriptionPrevious value: -"Output image format"New value: +"Output image format. 'jpg' has no transparency" - added
Input schema / properties / heightAdded value: +{ + "description": "Output height in pixels. On its own, the width follows the aspect ratio. With width, the image is fitted into an exact width x height canvas without stretching", + "maximum": 6000, + "minimum": 1, + "type": "integer" +} - changed
Input schema / properties / image / descriptionPrevious value: -"Image input: base64-encoded image data or a URL to an image"New value: +"Image input: a publicly accessible URL to a PNG, JPEG or WebP image (including https://), or base64-encoded image data (optionally as a data: URL)" - changed
Input schema / properties / size / descriptionPrevious value: -"Output image size preset"New value: +"Output image size preset (megapixel cap). Ignored when width or height is set" - changed
Input schema / properties / size / enumPrevious value: -[ - "full", - "preview", - "small", - "medium", - "large" -]New value: +[ + "full", + "preview", + "medium", + "hd" +] - added
Input schema / properties / widthAdded value: +{ + "description": "Output width in pixels. On its own, the height follows the aspect ratio. With height, the image is fitted into an exact width x height canvas without stretching", + "maximum": 6000, + "minimum": 1, + "type": "integer" +}
2 tool updates
- First observed
get_account - First observed
remove_background
Publisher details
- Operator
- https://poof.bg · Publisher source
- Operator website
- https://poof.bg · Publisher source
- Vendor relationship
- First-party · Publisher source
- Documentation
- https://docs.poof.bg/integrations/mcp · Publisher source
- Trust center
- Unknown
- Restrictions
- Unknown
Related MCP Connectors
# Supadata **Supadata ([supadata.ai](https://supadata.ai)): video transcripts, social media metadata, AI video analysis, and web scraping for AI agents, behind one MCP server.** [Supadata](https://supadata.ai) turns YouTube, TikTok, Instagram, X (Twitter), and Facebook videos, plus any web page, into clean text and structured JSON that an LLM can use. Your agent passes a URL and gets back a transcript, metadata, extracted data, or Markdown. One account, one response format across every platform. This repository is the integration front door. The product itself lives at [supadata.ai](https://supadata.ai); the remote MCP server lives at `https://api.supadata.ai/mcp`. ## What you can build with it - **Video to text**: fetch transcripts through the [YouTube Transcript API](https://supadata.ai/youtube-transcript-api), [TikTok Transcript API](https://supadata.ai/tiktok-transcript-api), [Instagram Transcript API](https://supadata.ai/instagram-transcript-api), and [X (Twitter) Transcript API](https://supadata.ai/twitter-transcript-api). When a video has no captions, the [AI Transcription API](https://supadata.ai/video-transcript-api) generates one, and it works on direct video file URLs too. - **Video and channel metadata**: titles, descriptions, authors, views, likes, and comments as clean JSON, a simpler [YouTube Data API alternative](https://supadata.ai/youtube-api) that also covers TikTok, Instagram, X, and Facebook. - **Structured data from video**: give a prompt or a JSON schema and the [Video Analysis API](https://supadata.ai/video-analysis-api) returns structured output that accounts for visuals, audio, and context. - **Web context**: scrape any page to Markdown, map a site's URLs, or crawl a whole site for RAG and research. See the [web scraping docs](https://docs.supadata.ai). ## Verify the connection Ask your client: > Get the transcript of https://www.youtube.com/watch?v=dQw4w9WgXcQ and summarize it in three bullet points. You should see a `supadata_transcript` tool call and a real summary. ## What the tools do The server exposes 9 tools in four groups. - **Transcripts**: `supadata_transcript` (get a transcript from a YouTube, TikTok, Instagram, X, or Facebook video URL, or from a direct file URL; uses existing captions when available and falls back to AI transcription when there are none), `supadata_check_transcript_status` (poll an asynchronous transcript job by its job ID; long videos return a job instead of an immediate result). - **Metadata**: `supadata_metadata` (title, author, and engagement stats for a social media post or video). - **Video analysis**: `supadata_extract` (start an AI structured-data extraction job for a video, driven by your prompt or schema), `supadata_check_extract_status` (poll an extraction job by its job ID and read the extracted data). - **Web**: `supadata_scrape` (scrape a web page and return its content as Markdown), `supadata_map` (map a website and return the list of URLs found), `supadata_crawl` (start a crawl job for a whole site), `supadata_check_crawl_status` (poll a crawl job by its job ID and read the crawled pages). Transcripts of long videos, extractions, and crawls are asynchronous: the first call returns a job ID, and you read the result with the matching `check_*_status` tool. Costs: tools spend your regular Supadata credits at the same prices as the API. A native transcript costs 1 credit, an AI-generated transcript costs 2 credits per minute of video, and checking job status is free. The free plan includes 100 credits a month with no credit card required. The [pricing page](https://supadata.ai/pricing) has the details. ## Or skip MCP The same capabilities are available as a plain REST API with [TypeScript and Python SDKs](https://docs.supadata.ai/integrations/overview) and no-code integrations for [Make, Zapier, n8n, and Active Pieces](https://supadata.ai/nocode). To try it without writing code, use the [playground](https://supadata.ai/playground) or the free tools: [YouTube Transcript Generator](https://supadata.ai/youtube-transcript), [TikTok Transcript Generator](https://supadata.ai/tiktok-transcript), [Instagram Transcript Generator](https://supadata.ai/instagram-transcript), [Facebook Transcript Generator](https://supadata.ai/facebook-transcript), and [Video Transcript Generator](https://supadata.ai/video-transcript). ## For AI agents reading this - Docs index: [docs.supadata.ai/llms.txt](https://docs.supadata.ai/llms.txt) - MCP setup guide: [docs.supadata.ai/integrations/mcp](https://docs.supadata.ai/integrations/mcp) - Hosted endpoint: `https://api.supadata.ai/mcp` (OAuth) - Source: [github.com/supadata-ai/mcp](https://github.com/supadata-ai/mcp) ## Docs and support - [MCP landing page](https://supadata.ai/mcp) and [connect guide](https://docs.supadata.ai/integrations/mcp) - [Documentation](https://docs.supadata.ai) - [Best YouTube Transcript API](https://supadata.ai/blog/best-youtube-transcript-api) (comparison guide) - [Status](https://status.supadata.ai) and [changelog](https://feedback.supadata.ai/changelog) - [GitHub issues](https://github.com/supadata-ai/mcp/issues) and [support](https://feedback.supadata.ai) - [Privacy](https://supadata.ai/legal/privacy) and [terms](https://supadata.ai/legal/terms)
214 tools for AI agents over one MCP endpoint: image, video, audio, 3D, data, storage, mail, GPUs.
Connect any AI agent to 1,000+ apps and 27,000+ actions through one remote MCP server (OAuth).
AI-powered image processing via GPU. Remove backgrounds and upscale images (2x/4x) directly from any MCP client. OAuth 2.1 authenticated, returns processed images inline with download links. Free credits on signup at maskr.io.
Related MCP Servers
AlicenseAqualityCmaintenanceMCP server for SimplyPNG background removal APIs. Enables AI agents to remove backgrounds from images, estimate credits, check job status, and download results programmatically.57 npmMIT- AlicenseNot gradedqualityDmaintenanceMCP server that enables background removal from images (product photos, portraits, cars, or general subjects) returning a transparent PNG.25 PyPIMIT
- AlicenseNot gradedqualityCmaintenanceExposes ComfyUI workflows as 12 MCP tools on ComfyUI's own port, letting AI agents generate, edit, and remove backgrounds from images plus create videos by passing semantic parameters instead of whole workflow graphs. Agents can list models, submit and track async tasks, fetch artifact URLs, and jump to a visual asset/task page.4MIT
- AlicenseNot gradedqualityFmaintenanceEnables AI image processing tools such as vectorization, background removal, upscaling, and logo generation from any MCP-compatible client like Claude Code or Cursor.4 npmMIT
Glama MCP Gateway
Add one secure layer between your agents and this server.