Supadata (supadata.ai): video transcripts, social media metadata, AI video analysis, and web scraping for AI agents, behind one MCP server.
Supadata 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; the remote MCP server lives at https://api.supadata.ai/mcp.
Video to text: fetch transcripts through the YouTube Transcript API, TikTok Transcript API, Instagram Transcript API, and X (Twitter) Transcript API. When a video has no captions, the AI Transcription 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 that also covers TikTok, Instagram, X, and Facebook.
Structured data from video: give a prompt or a JSON schema and the 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.
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.
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 has the details.
The same capabilities are available as a plain REST API with TypeScript and Python SDKs and no-code integrations for Make, Zapier, n8n, and Active Pieces. To try it without writing code, use the playground or the free tools: YouTube Transcript Generator, TikTok Transcript Generator, Instagram Transcript Generator, Facebook Transcript Generator, and Video Transcript Generator.
Docs index: docs.supadata.ai/llms.txt
MCP setup guide: docs.supadata.ai/integrations/mcp
Hosted endpoint: https://api.supadata.ai/mcp (OAuth)
Source: github.com/supadata-ai/mcp
Best YouTube Transcript API (comparison guide)
GitHub issues and support
Scored across 9 tools
Each tool targets a distinct action on a distinct resource type: scrape (single page), map (URL discovery), crawl (whole site), transcript, metadata, and extract. Descriptions explicitly cross-reference each other (e.g. 'use supadata_transcript for what is said in it', 'use supadata_scrape for ordinary web pages'), eliminating overlap. The three status-check tools map cleanly to their respective async job creators.
All tools share a consistent supadata_ prefix and snake_case format, with the check_*_status pattern applied uniformly. Minor deviation: some names are verbs (scrape, crawl, extract) while others are nouns (metadata, transcript), but this remains predictable and readable.
Nine tools is well-scoped for a content-scraping service, with each tool earning its place across the fetch, discover, and media-extraction workflows. The three parallel status checkers are justified by three distinct async job types.
The surface covers the full content-extraction lifecycle (discover, scrape, crawl, extract, transcript, metadata) with async polling. Minor gap: no job-cancellation tool despite 'cancelled' being a valid status, and no credits/usage check, though agents can work around these.
Check crawl job status and retrieve results. Returns status: "scraping", "completed", "failed", or "cancelled". If status is "scraping", call this tool again after a few seconds with the same id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job id returned by supadata_crawl. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower. The description adds real value beyond them: it enumerates the possible status values and prescribes the polling loop on 'scraping', which is exactly what an agent needs to drive the call correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the purpose, then the return values, then the polling instruction. Nothing is wasted.
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 by listing the status strings. The only gap is what the 'results' payload contains on completion, but the polling contract an agent needs is fully specified.
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 single id parameter as 'returned by supadata_crawl'. The description only reinforces this via 'the same id', adding polling-reuse semantics but little else beyond the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Check crawl job status and retrieve results'), which distinguishes it from the sibling status-check tools (extract, transcript) by resource. It stops short of explicitly naming those siblings, but the scope is unambiguous.
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 conditional usage rule: if status is 'scraping', re-call after a few seconds with the same id. This tells the agent how to poll. It does not state when to prefer this over the other check_*_status siblings, but the context is otherwise clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check extract job status and retrieve results. Returns status: "queued", "active", "completed", or "failed". If status is not "completed" or "failed", call this tool again after a few seconds with the same id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job id returned by supadata_extract. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds genuinely new behavior: the four possible status values and the retry cadence, which is the core operational detail for a polling tool. It stops short of saying what a completed job's results contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the purpose, then the return values, then the polling instruction. Every sentence carries distinct information with no padding.
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 usefully enumerates the status values and tells the agent how to loop. The remaining gap is what 'results' actually look like on completion, but the polling contract an agent needs is largely 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 single parameter's description already states it is the job id returned by supadata_extract. The description only echoes this via 'with the same id', adding no format, uniqueness, or expiry details beyond the schema. Baseline 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?
States a specific verb+resource ('Check extract job status') and adds 'retrieve results', which is the actual payoff. The resource noun 'extract job' cleanly separates it from the sibling polling tools supadata_check_crawl_status and supadata_check_transcript_status.
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 an explicit polling rule: if status is not 'completed' or 'failed', call again after a few seconds with the same id. That is concrete when-to-use guidance, though it never states the precondition that the id must come from a prior supadata_extract call or names alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check transcript job status and retrieve results. Returns status: "queued", "active", "completed", or "failed". If status is not "completed" or "failed", call this tool again after a few seconds with the same id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The job id returned by supadata_transcript. |
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 bar is lower. The description adds the terminal vs. non-terminal status contract and the repeat-polling expectation, which is exactly the behavior an agent needs. It doesn't say what 'retrieve results' actually returns on completion or whether 'failed' carries error detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: purpose first, then the return contract, then the polling instruction. Every sentence 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?
No output schema exists, so the description carries the return-value burden, and it does so by enumerating the four statuses and telling the agent when to stop polling. What's missing is a brief note on what a completed result contains or whether a failed status includes diagnostic information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter, and the schema already documents it at 100% coverage. The description reinforces its semantics by specifying that the same id must be reused across polls, which adds operational meaning beyond the schema's 'job id returned by supadata_transcript'.
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 ('Check transcript job status and retrieve results') and enumerates the possible outcomes, which is more than a restatement of the title. It implicitly distinguishes itself from the crawl/extract status siblings by naming the transcript job resource, though it never names those siblings 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?
Gives concrete, actionable polling guidance: if status is not 'completed' or 'failed', call again after a few seconds with the same id. It doesn't explicitly state the prerequisite (that the id comes from starting a transcript job) in the description body, but the conditional loop is clear and correct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a crawl job to extract content from all pages on a website. Not available on every Supadata plan; if it returns upgrade-required, tell the user rather than retrying. Returns a jobId - use supadata_check_crawl_status with that jobId to poll for results.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL to start crawling from, including https://. | |
| limit | No | Maximum number of pages to crawl (1-5000, default 100). Each page costs 1 credit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (readOnly, openWorld, idempotent=false, destructive=false), and the description goes beyond them with plan gating, the upgrade-required failure semantics, and the asynchronous jobId-then-poll workflow. This is meaningful behavioral context the annotations do not provide.
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: purpose, plan/error handling, and return-value workflow. Front-loaded with the action and the polling instruction is placed where it is needed.
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 discloses the return (jobId) and the exact sibling to poll it with, and covers the plan-gating edge case. Nothing essential for a correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents url and limit richly (including 1-5000 range, default 100, 1 credit per page), so the schema carries the parameter burden. The description adds no parameter syntax or format detail beyond what the schema states.
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?
Specific verb+resource: 'Create a crawl job to extract content from all pages on a website.' Clearly distinguishable from siblings like supadata_scrape (single page) and supadata_map, and it names the exact follow-up 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?
States the plan restriction and what to do on an upgrade-required response ('tell the user rather than retrying'), plus routes the agent to supadata_check_crawl_status for polling. No explicit when-not-to-use versus scrape/extract, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract structured data from a video URL using AI. Provide a prompt for what to extract, a JSON Schema for the output format, or both. Returns a jobId for async processing - use supadata_check_extract_status with that jobId to poll for results.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of a single video or post on YouTube, TikTok, Instagram, X (Twitter) or Facebook. | |
| prompt | No | What to extract from the video, in plain language. | |
| schema | No | JSON Schema describing the output format. Provide this, prompt, or both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds the crucial non-obvious behavior: extraction is asynchronous and returns a jobId that must be polled elsewhere. It omits rate limits, credit cost, or failure modes, which keeps 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?
Three tight sentences: capability first, input requirements second, async follow-up last. Nothing is padded and the downstream call is placed where an agent needs it.
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 usefully discloses that the immediate return is a jobId rather than extracted data, closing the biggest gap for this tool. It leaves residual unknowns such as media size/duration limits or processing latency, but the async contract is 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?
Schema description coverage is 100%, so all three parameters (url, prompt, schema) are already documented in the schema. The description restates the prompt/schema-or-both rule without adding format, syntax, or size guidance, so the 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?
States a specific verb and resource ("Extract structured data from a video URL using AI") and names the companion tool supadata_check_extract_status, which separates it from siblings like supadata_transcript or supadata_scrape. An agent can identify the tool's job without opening the 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?
Explicitly states that the caller must supply a prompt, a JSON Schema, or both, and that the returned jobId should be polled with supadata_check_extract_status. It does not contrast this tool against alternatives like supadata_transcript for plain text or supadata_metadata, so routing among siblings is only partly covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the URLs found on a website without fetching their content. Use this to discover a site's pages before choosing which ones to read with supadata_scrape, or to check a site's size before starting a supadata_crawl. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the website to map, including https://. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the bar is lower. The description adds genuinely new context: that it lists URLs without fetching content and that each call costs 1 credit, which matters for budgeting. It does not mention result limits or pagination behavior for large sites.
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 with no waste. The core behavior leads, followed by the routing guidance, and the credit cost is a brief trailing note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only discovery tool with no output schema, the description covers what it does, when to use it, and its cost. It could say more about the shape or volume of the returned URL list, but nothing essential to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single url parameter is fully documented in the schema including the https:// requirement, so parameter meaning is already handled. The description adds nothing further about the parameter; 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?
States a specific verb (list) and resource (URLs found on a website) plus the key scoping constraint that content is not fetched. This cleanly separates it from supadata_scrape (which reads content) and supadata_crawl (which traverses), both named in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names two use cases and the alternatives that follow: discover pages before choosing which to read with supadata_scrape, or check site size before starting a supadata_crawl. The agent has a clear decision rule for selecting this tool over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch metadata from a media URL (YouTube, TikTok, Instagram, Twitter/X, Facebook). Returns platform info, title, description, author details, engagement stats, media details, tags, and creation date. Use this for details about a video or post; use supadata_transcript for what is said in it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of a single video or post on YouTube, TikTok, Instagram, X (Twitter) or Facebook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds value by enumerating the returned fields unambiguously (platform info, title, description, author, engagement stats, tags, creation date), but doesn't mention failure modes for unsupported platforms/private content or rate limits.
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, zero waste: scoping clause, return-value clause, sibling-routing clause. Front-loaded with the core action and platform list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with full annotation coverage, no output schema, and no nested objects, the description covers purpose, scope, return contract, and alternative routing. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and only one parameter exists, so the schema already documents the URL. The description confirms platform support but adds no syntax or format guidance beyond what the schema property description provides. 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?
States a specific verb (Fetch) and resource (metadata from a media URL), enumerates supported platforms, and names the sibling it is not (supadata_transcript) with a crisp distinction between details vs. spoken content. An agent can route between them 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?
Explicitly says when to use this tool ('details about a video or post') versus the alternative ('use supadata_transcript for what is said in it'). The only missing piece is explicit single-URL scoping, which is implied by 'a media URL'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single web page and return its main content as Markdown, along with the page title, description and the links it contains. Use this to read or summarize a specific URL. To find which pages exist on a site, use supadata_map; to fetch many pages at once, use supadata_crawl. Costs 1 credit.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Full URL of the web page, including https://. Use a URL you know exists; to find pages on a site, use supadata_map. | |
| lang | No | Preferred page language as an ISO 639-1 code, e.g. "en", for sites that serve several languages. | |
| noLinks | No | true leaves out the list of links found on the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: the credit cost (1 credit) and the shape of the returned content (Markdown, title, description, links). No notable gap remains, though return format details are still fairly high-level.
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 tightly packed sentences: what it returns, when to use it, and the sibling alternatives plus cost. Front-loaded with the primary capability and zero 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?
With no output schema, the description carries the return-value burden and does so by naming Markdown content, title, description and links. Combined with the fully documented input schema and the safety annotations, an agent has everything needed to invoke it 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 description coverage is 100%, so all three parameters are already documented in the schema, including the noLinks-to-links relationship and the lang ISO code. The description only restates that links are returned and does not add syntax or edge-case detail beyond the schema, so the baseline 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?
Specific verb (Fetch) and resource (single web page) with an explicit statement of what is returned (main content as Markdown, title, description, links). It clearly distinguishes itself from supadata_map and supadata_crawl by naming both siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case ('read or summarize a specific URL') and routes the agent to alternatives with their selecting conditions: supadata_map for discovering pages, supadata_crawl for bulk fetching. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the transcript (what is said) of a video or post on YouTube, TikTok, Instagram, X (Twitter) or Facebook, or of an audio or video file URL. Not for ordinary web pages: use supadata_scrape for those. For large files, returns a jobId instead of the transcript directly - use supadata_check_transcript_status with that jobId to poll for results.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of a single video or post on YouTube, TikTok, Instagram, X (Twitter) or Facebook, or a direct link to an audio or video file. Not for ordinary web pages (use supadata_scrape). | |
| lang | No | Preferred transcript language as an ISO 639-1 code, e.g. "en". Falls back to the first available language. | |
| mode | No | "native" only fetches an existing transcript, "generate" always transcribes with AI, "auto" (default) tries native first and falls back to generate. | |
| text | No | true returns the transcript as plain text; false (default) returns timestamped segments. | |
| chunkSize | No | Maximum characters per timestamped segment (at least 50). Ignored when text is true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely non-structured behavior: the dual return mode (transcript directly vs. jobId for large files) and the polling follow-up. It stops short of mentioning auth requirements, rate limits, or failure modes, so it is not maximally 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?
Three sentences, zero filler, front-loaded with the core capability before the exclusion and the async caveat. Every sentence carries information an agent needs to select and call the tool correctly.
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 compensates by explaining the two possible return shapes (transcript or jobId) and the follow-up tool needed for the latter. Combined with the platform coverage, the exclusion rule, and complete schema param docs, nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema already documents lang (ISO 639-1 + fallback), mode (native/auto/generate semantics), text (plain text vs timestamped segments), and chunkSize (minimum 50, ignored when text is true). The description adds no parameter-level meaning beyond that, so the baseline 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?
States a specific verb+resource ('Get the transcript ... of a video or post') and enumerates the supported platforms (YouTube, TikTok, Instagram, X, Facebook, plus direct audio/video file URLs). It also explicitly separates itself from supadata_scrape by naming the excluded resource type, so an agent can distinguish it from siblings 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?
Gives an explicit when-not ('Not for ordinary web pages: use supadata_scrape for those') with the alternative named. It also routes the async case: large files return a jobId and the agent should use supadata_check_transcript_status to poll, which is a clear conditional workflow rather than implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
supadata_check_crawl_status1 field changedInput schema / properties / id / descriptionAdded value: +"The job id returned by supadata_crawl."supadata_check_extract_status1 field changedInput schema / properties / id / descriptionAdded value: +"The job id returned by supadata_extract."supadata_check_transcript_status1 field changedInput schema / properties / id / descriptionAdded value: +"The job id returned by supadata_transcript."supadata_crawl4 fields changedInput schema / properties / limit / descriptionAdded value: +"Maximum number of pages to crawl (1-5000, default 100). Each page costs 1 credit."Input schema / properties / limit / maximumAdded value: +5000Input schema / properties / limit / minimumAdded value: +1Input schema / properties / url / descriptionAdded value: +"Full URL to start crawling from, including https://."supadata_extract3 fields changedInput schema / properties / prompt / descriptionAdded value: +"What to extract from the video, in plain language."Input schema / properties / schema / descriptionAdded value: +"JSON Schema describing the output format. Provide this, prompt, or both."Input schema / properties / url / descriptionAdded value: +"URL of a single video or post on YouTube, TikTok, Instagram, X (Twitter) or Facebook."supadata_map1 field changedInput schema / properties / url / descriptionAdded value: +"Full URL of the website to map, including https://."supadata_metadata1 field changedInput schema / properties / url / descriptionAdded value: +"URL of a single video or post on YouTube, TikTok, Instagram, X (Twitter) or Facebook."supadata_scrape3 fields changedInput schema / properties / lang / descriptionAdded value: +"Preferred page language as an ISO 639-1 code, e.g. \"en\", for sites that serve several languages."Input schema / properties / noLinks / descriptionAdded value: +"true leaves out the list of links found on the page."Input schema / properties / url / descriptionAdded value: +"Full URL of the web page, including https://. Use a URL you know exists; to find pages on a site, use supadata_map."supadata_transcript7 fields changedInput schema / properties / chunkSize / descriptionAdded value: +"Maximum characters per timestamped segment (at least 50). Ignored when text is true."Input schema / properties / chunkSize / minimumAdded value: +50Input schema / properties / lang / descriptionAdded value: +"Preferred transcript language as an ISO 639-1 code, e.g. \"en\". Falls back to the first available language."Input schema / properties / mode / descriptionAdded value: +"\"native\" only fetches an existing transcript, \"generate\" always transcribes with AI, \"auto\" (default) tries native first and falls back to generate."Input schema / properties / mode / enumAdded value: +[
+ "native",
+ "auto",
+ "generate"
+]Input schema / properties / text / descriptionAdded value: +"true returns the transcript as plain text; false (default) returns timestamped segments."Input schema / properties / url / descriptionAdded value: +"URL of a single video or post on YouTube, TikTok, Instagram, X (Twitter) or Facebook, or a direct link to an audio or video file. Not for ordinary web pages (use supadata_scrape)."supadata_check_crawl_statussupadata_check_extract_statussupadata_check_transcript_statussupadata_crawlsupadata_extractsupadata_mapsupadata_metadatasupadata_scrapesupadata_transcriptYour agent needs live data — a competitor's traffic, who to contact there, what people are saying, what Google and ChatGPT answer about you, a company's filings. Normally that is six vendor accounts, six sets of keys and six SDKs. This is one URL. **What you can ask for** • "How much traffic does stripe.com get, where does it come from, and who competes for the same keywords?" • "Find 20 Series-B fintech companies in Germany and the heads of marketing there, with emails." • "Does ChatGPT mention our brand when someone asks for the best CRM — and what does it cite?" • "What is X saying about $NVDA today, and what did the stock actually do?" • "Search the web for this, then scrape the three best pages into markdown." **How to use it** Point any MCP client at https://mcp.aisa.one/mcp and sign in with OAuth — there is no key to create or paste. Then just ask: the agent calls search to find the right operation and use to run it. **Why this rather than the source** 26 sources behind one account and one bill — DataForSEO, Semrush, Ahrefs, Similarweb, Apollo, X/Twitter, Instagram, Reddit, Pinterest, YouTube, Tavily, Exa, Perplexity, Firecrawl, CoinGecko, Kalshi, Polymarket, AgentMail and more, 580+ operations. tools/list returns five tools, not 580, so the introduction does not eat your context window. **What it costs** Finding and inspecting an operation is free. Running one is billed per call at API prices, with no seat and no monthly minimum, and every call takes max_price_usd so an agent cannot overspend by accident. **Where else it reaches** One slice at a time: https://mcp.aisa.one/seo/mcp · /finance/mcp · /social/mcp · /search/mcp · /sales/mcp · /mail/mcp · /gtm/mcp, or a single provider like /twitter-api/mcp. Same account, fewer tools listed, and search still reaches everything. Full list at https://mcp.aisa.one/servers
SubDownload exposes YouTube as an MCP-native data source. Connect via OAuth and your AI agent can summarize videos, fetch full transcripts (even for videos with no captions, via AI ASR), search across channels, and save everything into a private knowledge base. Works with Claude, ChatGPT, Cursor, and 40+ MCP clients. Free credits on signup, no card required.
YouTube transcripts, search, channel browsing, and playlists for AI agents via MCP.
# Poof **Poof ([poof.bg](https://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](https://poof.bg) 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](https://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](https://poof.bg/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](https://poof.bg/alternative/remove-bg). - **Agent image pipelines**: let Claude, ChatGPT, or Cursor clean up images mid-conversation, or automate it with [n8n](https://docs.poof.bg/integrations/n8n), [Zapier](https://docs.poof.bg/integrations/zapier), and [Make](https://docs.poof.bg/integrations/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`, or `webp`. - `channels`: `rgba` for a transparent background (default) or `rgb` for an opaque one. - `bg_color`: fill colour for opaque output, as hex, RGB, or a colour name. - `size`: `full` (default), `preview`, `medium`, or `hd`. Ignored when `width` or `height` is set. - `crop`: crop to the subject bounds. - `width` and `height`: 1 to 6000 pixels. Set one and the other follows the aspect ratio. - `fit`: how the image fits a `width` x `height` canvas without stretching: `contain` (default, pad), `cover` (fill and crop the overflow around the subject), or `scale-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](https://poof.bg/pricing) 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](https://poof.bg/privacy). ## Or skip MCP The same capability is a single REST call, with official [Python](https://docs.poof.bg/integrations/python) and [TypeScript](https://docs.poof.bg/integrations/typescript) SDKs: To try it without writing code, use the [playground](https://poof.bg/playground). The [quickstart](https://docs.poof.bg/quickstart) and the [Node.js tutorial](https://poof.bg/blog/integrating-api-in-nodejs) cover the first integration. ## For AI agents reading this - Docs index: [docs.poof.bg/llms.txt](https://docs.poof.bg/llms.txt) - MCP setup guide: [docs.poof.bg/integrations/mcp](https://docs.poof.bg/integrations/mcp) - API reference: [docs.poof.bg/api-reference/remove-background](https://docs.poof.bg/api-reference/remove-background) - Hosted endpoint: `https://api.poof.bg/mcp` (OAuth) - Source: [github.com/poof-bg/mcp](https://github.com/poof-bg/mcp) ## Docs and support - [Connect guide](https://docs.poof.bg/integrations/mcp) (per-client, kept current) - [Documentation](https://docs.poof.bg) and [all integrations](https://docs.poof.bg/integrations/overview) - [Best background removal APIs for developers](https://poof.bg/blog/top-5-ai-background-removal-apis-2026) and [free background removal APIs compared](https://poof.bg/blog/affordable-free-bg-removal-apis-2026) - [Changelog](https://feedback.poof.bg/changelog) and [support](https://feedback.poof.bg) - [GitHub issues](https://github.com/poof-bg/mcp/issues) - [Privacy](https://poof.bg/privacy) and [terms](https://poof.bg/terms) - Questions: <support@poof.bg>
Add one secure layer between your agents and this server.
