Provides Apple Podcasts lookup and episode scraping, enabling retrieval of podcast and episode data.
Provides Bluesky post, search, and profile scraping capabilities.
Provides Google Search results scraping via a SERP API, enabling retrieval of Google search results through the MCP tool.
Provides Substack publication and posts scraping, enabling retrieval of publication and post data.
Provides Telegram channel posts scraping, enabling retrieval of posts from Telegram channels.
Provides tools for YouTube data, including comments and replies, channel latest videos, channel videos/shorts/live, search results for videos and channels, and video details such as views, likes, description, and tags.
webdatatools-social-mcp
An MCP server with 10 search, video & social data tools for AI agents — Claude Desktop, Cursor, Cline or any MCP client. Google search results, YouTube channels, videos, search and comments, podcasts, Bluesky, Telegram channels and Substack publications — no API keys needed.
This server uses your own Apify API token. Every tool call runs a WebDataTools Actor under your Apify account and is billed to your Apify credit — pay per result, the price is in each tool description. Your token is only sent to Apify's API.
Requires Node.js 18+.
APIFY_TOKEN=apify_api_... npx -y github:paulet4a-commits/webdatatools-social-mcpGet a free token (the free plan includes monthly credit): https://console.apify.com/settings/integrations
Related MCP server: jiro
Add this to claude_desktop_config.json (Claude Desktop) or .cursor/mcp.json (Cursor):
{
"mcpServers": {
"webdatatools-social": {
"command": "npx",
"args": [
"-y",
"github:paulet4a-commits/webdatatools-social-mcp"
],
"env": {
"APIFY_TOKEN": "apify_api_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
}
}
}Tool | What it does | Price (free plan) | Backing Actor |
| Google Search Results Scraper — SERP API | $0.005 / result | |
| YouTube Comments Scraper — Comments & Replies | $0.0005 / result | |
| YouTube Channel Latest Videos (RSS, no API key) | $0.001 / result | |
| YouTube Channel Scraper (videos, shorts, live) | $0.0005 / video | |
| YouTube Search Results Scraper (videos, channels, no API key) | $0.0005 / result | |
| YouTube Video Details Scraper (views, likes, description, tags) | $0.001 / video | |
| Apple Podcasts Lookup & Episodes Scraper | $0.001 / episode | |
| Bluesky Post, Search & Profile Scraper | $0.0005 / post | |
| Telegram Channel Posts Scraper | $0.0005 / Post | |
| Substack Publication & Posts Scraper | $0.0005 / Post |
webdatatools-mcp-server — the 10 most popular tools in one server
webdatatools-domain-mcp — Domain & website intelligence
webdatatools-rag-mcp — Web content for AI & RAG
webdatatools-leads-mcp — Leads, jobs & company data
webdatatools-dev-mcp — Developer, app & research data
MIT
Bluesky Post, Search & Profile Scraper returns post text, engagement counts, images, profile bios, followers, follows and thread replies from Bluesky's public API — one row per item, no login required. Billed to your own Apify account: ~$0.0005 per post (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Mode — Choose what to scrape. "posts" reads a user's own posts, "search" finds posts matching a query (requires an app password below — Bluesky's public search API needs a signed-in session), "profile"/"followers"/"follows" read account data, and "thread" reads one post and its replies. Options: posts = User's posts; search = Search posts; profile = Profile; followers = Followers; follows = Follows; thread = Thread. Example: "posts". | |
| sort | No | Sort order — Choose how search results are ordered: "latest" (newest first) or "top" (most engagement first). Used by the "search" mode only. Options: latest = Latest; top = Top. | latest |
| since | No | Since (ISO date) — Enter an ISO 8601 date/time to only return posts created on or after it, e.g. 2026-01-01. Leave blank for no lower bound. Used by the "search" mode only. | |
| until | No | Until (ISO date) — Enter an ISO 8601 date/time to only return posts created before it, e.g. 2026-06-01. Leave blank for no upper bound. Used by the "search" mode only. | |
| handles | No | Handles, DIDs or profile URLs — Enter one or more Bluesky handles, DIDs or bsky.app profile URLs, e.g. bsky.app, did:plc:z72i7hdynmk6r22z27h6tvur or https://bsky.app/profile/jay.bsky.team. Used by the "posts", "profile", "followers" and "follows" modes. Example: ["bsky.app"]. | |
| postUrl | No | Post URL — Enter one post's bsky.app URL (e.g. https://bsky.app/profile/bsky.app/post/3l6oveex3ii2l) or its at:// URI. Used by the "thread" mode only, to fetch that post and its replies. Example: "https://bsky.app/profile/bsky.app/post/3l6oveex3ii2l". | |
| maxItems | No | Max items — Enter the maximum number of rows to return per handle or per search query, e.g. 100. Raise this for bulk exports; lower it to keep runs quick. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose two important traits: no authentication needed for scraping, and real billing on the user's own Apify account at ~$0.0005 per post. It also clarifies output cardinality ('one row per item'). It stops short of rate limits, pagination, or failure behavior, so not 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?
Two sentences, front-loaded with the capability and output scope, followed by the cost model. Dense but every clause earns its place; slightly run-on rather than wasteful.
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 7-parameter, mode-driven scraper with no output schema and no annotations, the description adequately conveys what comes back and what it costs. Mode-specific behavior and the search-mode credential requirement are left entirely to the schema, which keeps it just short of 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 every parameter including the mode enum is already documented in the schema. The description adds only the aggregate field list, not syntax, defaults, or the app-password caveat for search mode, so this is the baseline 3.
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?
Names a specific verb (scrape) and resource (Bluesky posts, search, profiles) and enumerates the returned fields: post text, engagement counts, images, bios, followers, follows, thread replies. It is instantly distinguishable from every sibling, which are YouTube, Podcast, Telegram, Substack and Google scrapers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states no when-to-use conditions, no alternatives, and no mode-selection guidance — the actual routing logic (which mode needs handles vs postUrl) lives only in the schema. The 'no login required' note is a constraint, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Google Search Results Scraper returns organic results (title, real URL, snippet, position) for any query through the Apify GOOGLE_SERP proxy — one row per SERP page, priced per page not per result. Billed to your own Apify account: ~$0.005 per result (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| device | No | Device — Choose desktop or mobile to control which User-Agent is sent — Google sometimes shows slightly different snippets/layout per device. Options: desktop = Desktop; mobile = Mobile. | desktop |
| queries | Yes | Search queries — Enter the Google search queries to scrape, e.g. apify web scraping. One dataset row is returned per query per result page. Example: ["apify web scraping"]. | |
| safeSearch | No | SafeSearch — Turn this on to request Google's SafeSearch filtering (adds safe=active to the request). | |
| countryCode | No | Country code (gl) — Enter the 2-letter country code Google should localise results for, e.g. us, gb, de. Sent as the gl parameter. | us |
| languageCode | No | Language code (hl) — Enter the 2-letter interface language code, e.g. en, es, fr. Sent as the hl parameter and affects snippet language. | en |
| resultsPerPage | No | Results per page — Enter how many results Google should return per page, e.g. 10. Higher values (up to 100) fit more organic results on one billed page but Google may still cap what it actually returns. | |
| maxPagesPerQuery | No | Max pages per query — Enter how many result pages to fetch per query, e.g. 1. Each extra page is a separate billed SERP page (start=N*resultsPerPage). | |
| includePeopleAlsoAsk | No | Include People Also Ask — Keep this on to parse the People Also Ask question box. Note: Google only loads each answer's text/link after a click, so answerSnippet/url are often null — only the question text is reliably available. | |
| includeRelatedSearches | No | Include related searches — Keep this on to parse the related-searches suggestions shown near the bottom of the page. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden, and it delivers uncommon value: it discloses output granularity (one row per SERP page), a per-page rather than per-result pricing model, and self-billed Apify cost (~$0.005/result). It stops short of covering auth/token setup, rate limits, or error behavior, so it is strong but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the deliverable and then the cost model, with no filler. Effective and appropriately sized, though it could be marginally tighter in the pricing clause.
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 describes return fields and row granularity plus the cost model. For a 9-parameter scraper it is nearly complete, missing only error/retry and async behavior context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the parameter descriptions are already detailed (gl/hl mappings, billing implications of resultsPerPage and maxPagesPerQuery), so the description adds little parameter-specific meaning. Baseline 3 is correct when the schema does the heavy lifting.
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 — returns organic Google results (title, real URL, snippet, position) for any query — so the agent knows exactly what it produces. It is unmistakably distinct from the sibling scrapers (YouTube, podcast, Bluesky, Telegram, Substack), which are all different platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool does but never states when to use it versus alternatives or any preconditions. With siblings covering unrelated platforms selection is somewhat obvious, but there is no explicit when-to-use or when-not guidance, leaving usage to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apple Podcasts lookup by id, URL, RSS feed or search term — podcast metadata (artwork, genres, episode count) plus the full episode list from the show's own RSS feed, one row per podcast or episode. Billed to your own Apify account: ~$0.001 per episode (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | Storefront country — Enter the two-letter country code of the Apple Podcasts storefront to search and look up ids in, e.g. us, gb, de. Only affects the iTunes lookup/search step — an RSS feed URL entry ignores this. | us |
| podcasts | Yes | Podcasts — Enter one podcast per row: an Apple Podcasts id (1200361736), an Apple Podcasts URL (https://podcasts.apple.com/us/podcast/the-daily/id1200361736), an RSS feed URL (https://feeds.simplecast.com/Sl5CSM3S), or a search term prefixed with search: (search:true crime, which returns up to searchLimit podcasts). Example: ["1200361736"]. | |
| outputMode | No | Output mode — Choose podcasts for one row per podcast (metadata only), or episodes for one row per episode (podcast metadata repeated on every episode row). Choosing episodes automatically fetches the RSS feed even if includeEpisodes is off. Options: podcasts = One row per podcast; episodes = One row per episode. | episodes |
| maxEpisodes | No | Max episodes per podcast — Enter how many of the most recent episodes to read from each podcast's RSS feed, e.g. 20. Only used when includeEpisodes is on and outputMode is episodes. | |
| searchLimit | No | Results per search term — Enter how many podcasts each search: term should return, e.g. 25. Only affects rows starting with search: — an id, URL or feed entry always resolves to exactly one podcast. | |
| includeEpisodes | No | Fetch episodes from RSS — Keep this on to fetch each podcast's own RSS feed (via its feedUrl) and read its language, full description and website — and, in episodes output mode, its episode list. Turning this off skips the RSS request entirely and leaves those fields null. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses the notable behavioral facts: a per-episode billing cost against the user's Apify account, the fact that the show's own RSS feed is fetched for episode data, and that output is one row per podcast or episode. It omits auth requirements and rate-limit/error behavior, but the cost and data-source disclosures are unusually valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the input/output contract and closing with the cost model. Dense and largely waste-free, though the parenthetical pricing note is a slight digression from the operational instructions.
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 six-parameter scraper with no output schema and no annotations, it covers inputs, row-level output shape, the RSS dependency, and cost. Missing only auth/permission prerequisites and failure handling, which keeps it just short of fully 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 the schema already documents all six parameters in detail. The description repeats the accepted input forms but adds no syntax or format detail beyond what the parameter descriptions provide, so baseline 3 is correct.
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 (Apple Podcasts lookup) and enumerates the four accepted input forms (id, URL, RSS feed, search term), plus what comes back (metadata and full episode list). No sibling tool covers podcasts, so the platform 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?
The enumerated input formats make clear when the tool applies, and the schema notes for country/searchLimit spell out which entries each option affects. It stops short of explicit when-not or alternative-tool routing, but siblings are all other platforms so there is little ambiguity to resolve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrapes any Substack publication's own public JSON archive API — title, author, publish date, paywall status, word count, likes and comments per post, one row per post, with an RSS fallback and optional full article text. Billed to your own Apify account: ~$0.0005 per Post (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| freeOnly | No | Free posts only — Keep this on to skip posts marked paywalled/subscriber-only (isPaywalled) and only return posts anyone can read. | |
| maxPosts | No | Max posts per publication — Enter how many of the most recent posts to fetch per publication, e.g. 50. The Actor pages through the publication's own archive API in batches of 50 until this many posts are collected. | |
| includeBody | No | Include full article text — Keep this off for metadata only (fast). Turn it on to also fetch each post's own page and extract its full article text into bodyText — one extra request per post. | |
| publications | Yes | Publications — Enter one Substack publication per row: a subdomain handle (bariweiss), a full subdomain (bariweiss.substack.com), or any post/publication URL on a custom domain (https://www.thefp.com or https://www.thefp.com/p/some-post). Example: ["bariweiss"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses billing to the user's own Apify account with a per-post price estimate, reveals the RSS fallback path, and warns that includeBody costs one extra request per post. It does not mention auth requirements or rate limits, but 'public JSON archive API' implies no credentials are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with output scope and followed by cost/billing context. Every clause earns its place by either describing returned data or setting cost expectations.
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 or annotations exist, so the description must describe returns — and it enumerates the per-post fields and the one-row-per-post shape, which is adequate. Minor gaps remain around pagination limits and auth, though those are partially covered by the schema and the 'public API' phrasing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter already has a rich description (freeOnly, maxPosts, includeBody, publications formats). The description adds only marginal mapping, e.g. 'optional full article text' to includeBody and 'paywall status' to freeOnly, 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 and resource — scraping a Substack publication's public JSON archive API — and enumerates the returned fields (title, author, publish date, paywall status, word count, likes, comments). This clearly distinguishes it from the YouTube/Google/Telegram/Bluesky scrapers among its siblings, which target entirely different platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the resource (use this to scrape Substack publications) and it notes an RSS fallback, but it never states when to prefer this over adjacent tools like podcast_lookup or when it is inappropriate. No explicit when/when-not framing is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrapes public Telegram channels via the t.me/s/ web preview — post text, view counts, media flags, forwards, replies and links, one row per post, no API key or login required. Billed to your own Apify account: ~$0.0005 per Post (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| channels | Yes | Channels — Enter one public Telegram channel per row: a bare handle (telegram), an @handle (@telegram) or a t.me URL (https://t.me/telegram). The channel must have public content preview enabled at t.me/s/<handle> — private channels and groups are not supported. Example: ["@telegram"]. | |
| maxPosts | No | Max posts per channel — Enter how many of the most recent posts to fetch per channel, e.g. 50. The Actor pages through https://t.me/s/<channel>?before=<id> until this many posts are collected. | |
| includeText | No | Include post text — Keep this on to include each post's message text and the links found inside it. Turning it off leaves text and links empty, which is faster when you only need view counts and media flags. | |
| newestFirst | No | Newest posts first — Keep this on to sort each channel's rows from newest to oldest post. Turn it off for oldest-first order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the scraping mechanism (t.me/s web preview), that no auth is needed, output granularity (one row per post) and the billing model (~$0.0005 per Post). It stops short of rate limits, failure modes when preview is disabled, or pagination behavior.
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 tightly packed sentences with zero filler. The capability and mechanism are front-loaded, and the billing caveat is placed last where it belongs.
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 4 well-documented parameters and no output schema, the description usefully enumerates returned fields (text, view counts, media flags, forwards, replies, links), filling the output gap. Only edge-case behavior (blocked previews, partial failures) is unaddressed.
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 adds only the per-post cost framing and output shape ('one row per post'), which lightly informs maxPosts but contributes no syntax or format beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with a specific verb and resource ('Scrapes public Telegram channels') and immediately names the mechanism (the t.me/s/ web preview), which distinguishes it cleanly from the YouTube, podcast, Bluesky and Substack siblings. An agent can identify this tool from the first clause alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditions: public channels only, no API key or login required, billing accrues to your own Apify account. The exclusion of private channels/groups appears in the schema, so the description covers context without explicit when-not routing or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
YouTube Channel Scraper extracts videos, Shorts or livestreams from any YouTube channel — title, views, duration, publish time and thumbnail — no API key or quota needed. Billed to your own Apify account: ~$0.0005 per video (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| tab | No | Tab — Choose which channel tab to read: 'videos' for regular uploads, 'shorts' for Shorts, or 'streams' for the Live tab (past and current livestreams). A channel without that tab returns an error row for it. Options: videos = Videos; shorts = Shorts; streams = Live. | videos |
| sortBy | No | Sort by — Choose 'newest' for the channel's default upload order, or 'popular' to sort by view count using the channel's own 'Popular' filter. Popular sort only applies to the Videos and Live tabs; Shorts always returns newest first, and any channel without a Popular filter falls back to newest automatically. Options: newest = Newest first; popular = Most popular. | newest |
| channels | Yes | Channels — Enter YouTube channels to scrape, one row is returned per video. Accepts a channel ID (UCX6OQ3DkcsbYNE6H8uQQuVA), a handle with or without @ (@MrBeast), or a channel/c/user URL, e.g. https://www.youtube.com/@MrBeast. Example: ["@apify"]. | |
| maxVideosPerChannel | No | Max videos per channel — Enter the maximum number of video rows to return per channel, e.g. 100. The scraper pages through the channel's grid one request per ~30 videos until this cap is reached or the channel runs out of videos. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It usefully discloses that no API key or quota is needed and that billing goes through the user's Apify account at roughly $0.0005 per video, but it omits rate limits, error handling, and authentication requirements beyond billing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The core purpose and returned fields are front-loaded, and the billing detail earns its place by setting cost expectations.
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?
There is no output schema, so listing returned fields (title, views, duration, publish time, thumbnail) is helpful. But with nine sibling tools, the description lacks the usage guidance and differentiation an agent needs to confidently select this tool over alternatives. The rich parameter schema compensates somewhat.
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 input schema already documents all four parameters thoroughly, including enums and defaults. The description adds no parameter-specific syntax or meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (extracts) and resource (videos, Shorts or livestreams from any YouTube channel) plus the returned metadata fields. However, it does not explicitly distinguish itself from siblings such as youtube_channel_videos or youtube_search_scraper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but gives no when-to-use guidance, prerequisites, or alternatives. It never mentions when to choose this over youtube_search_scraper or youtube_channel_videos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
YouTube channel latest videos scraper: give it a channel ID, @handle or channel URL and get the newest uploads with title, URL, views, likes, description and thumbnail — one row per video, no API key. Billed to your own Apify account: ~$0.001 per result (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| channels | Yes | YouTube channels — Enter the YouTube channels to read, one row is returned per video. Every form works: a channel ID (UCX6OQ3DkcsbYNE6H8uQQuVA), a handle (@MrBeast), or a channel URL (https://www.youtube.com/@apify, /channel/UC..., /c/Name, /user/Name). Channel IDs are read directly; handles and URLs cost one extra request to look the ID up, so paste UC... IDs when you have them. Example: ["UCX6OQ3DkcsbYNE6H8uQQuVA"]. | |
| maxVideosPerChannel | No | Max videos per channel — Enter how many of the newest videos to return per channel, e.g. 15. YouTube's public RSS feed only ever contains the latest 15 uploads, so 15 is both the default and the maximum — there is no way to page further back without the official Data API. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses no API key is required, that billing goes to the caller's own Apify account at ~$0.001 per result (lower on paid plans), and the hard 15-video ceiling imposed by YouTube's RSS feed. It stops short of covering auth setup or failure/empty-channel behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the action, input forms, output fields, and pricing without filler. Every clause (input formats, returned fields, cost) carries information the agent needs.
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 compensates by listing the returned fields, and it also covers cost and the 15-video limit. Minor gaps remain around error handling and whether results are sorted by recency, but the core call path 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%, so the schema already documents both parameters, including accepted channel ID/handle/URL forms and the 15-item maximum. The description adds little beyond that apart from 'one row per video' and the per-result cost, 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?
Names a specific verb+resource (scrape latest YouTube channel uploads) and enumerates the returned fields (title, URL, views, likes, description, thumbnail), so the agent knows exactly what comes back. It does not, however, differentiate itself from the sibling youtube_channel_scraper, leaving ambiguity about which channel tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the phrasing 'give it a channel ID, @handle or channel URL', which tells the agent what to feed it. There is no explicit when-to-use versus youtube_channel_scraper or youtube_search_scraper, and no stated exclusions, so routing must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comments Scraper extracts comments, replies, likes and author details from any YouTube video URL or ID — no YouTube Data API key or quota needed. Billed to your own Apify account: ~$0.0005 per result (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| sortBy | No | Sort comments by — Choose 'top' for YouTube's featured/most-relevant comments first, or 'newest' to get the most recently posted comments first — useful for monitoring what people are saying about a video right now. Options: top = Top comments; newest = Newest first. | top |
| videos | Yes | Videos — Enter YouTube video IDs or URLs, one row is returned per comment. Accepts a bare ID (dQw4w9WgXcQ), a watch URL, a shorts URL, or a youtu.be link, e.g. https://www.youtube.com/watch?v=dQw4w9WgXcQ. Example: ["dQw4w9WgXcQ"]. | |
| language | No | Language — Enter a 2-letter language code YouTube should localize its UI text to, e.g. en. This affects labels like relative-time text ('2 days ago'), not the comments themselves. | en |
| includeReplies | No | Include replies — Keep this off to fetch only top-level comments (fastest, cheapest). Turn it on to also fetch replies to each comment thread — every reply needs one extra request, so runs take longer and replies count toward the per-video cap above. | |
| maxCommentsPerVideo | No | Max comments per video — Enter the maximum number of comment rows to return per video, e.g. 100. Replies count toward this cap when 'Include replies' is on. Raise this for deep sentiment analysis, lower it to sample large channels cheaply. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it usefully discloses that no YouTube Data API key/quota is required and that runs are billed to the caller's Apify account at ~$0.0005 per result. However it omits run-behavior details such as failure modes, pagination behavior on large videos, or how the per-video cap interacts with long runs (left to the schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the tool does and followed by the cost model. Every sentence earns its place with no filler or redundancy.
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, but the schema notes one row per comment and the description plus schema together convey extraction scope, cost, and API-key independence. Minor gaps remain around run failure behavior and result volume limits, but the core information an agent needs to invoke this 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 description coverage is 100%, so all five parameters are already well documented in the schema, including defaults, enums, and limits. The description adds no parameter-level meaning beyond what the schema provides, which is the expected 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?
The description names a specific verb (extracts) and resource (comments, replies, likes, author details) from YouTube videos, with a clear scope (video URL or ID). An agent can immediately tell this apart from youtube_search_scraper, youtube_channel_videos, and youtube_video_details by resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named despite several closely related YouTube siblings. Cost mode is mentioned, but that is pricing context rather than routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
YouTube Search Results Scraper returns videos, channels or playlists for any keyword, with title, views, duration, channel and publish time — no API key, no quota. Billed to your own Apify account: ~$0.0005 per result (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Result type — Choose what kind of result to return: all mixes videos, channels and playlists; video/channel/playlist restrict the search server-side to one kind (verified live against YouTube's search endpoint). Options: all = All (videos, channels, playlists); video = Videos only; channel = Channels only; playlist = Playlists only. | video |
| region | No | Region — Country code sent to YouTube as gl, e.g. US. Affects which results and trending content YouTube considers local. | US |
| sortBy | No | Sort by — How to order results. relevance (default) and views are applied by YouTube's server and verified live (views produces a clean view-count-descending order). date and rating could not be verified server-side during testing — for those two the Actor instead re-sorts the page(s) it already fetched by parsed publish time client-side, which is a best-effort approximation, not a true site-wide sort; see the README. Options: relevance = Relevance (default); date = Upload date (best-effort, client-side); views = View count (verified server-side); rating = Rating (best-effort, unreliable — YouTube hides ratings). | relevance |
| queries | Yes | Search queries — Enter the search terms to run on YouTube, one row is returned per result, e.g. web scraping tutorial. One dataset row is produced per matching video, channel or playlist. Example: ["web scraping tutorial"]. | |
| duration | No | Duration — Only return videos of this length: short is under 4 minutes, medium is 4-20 minutes, long is over 20 minutes. Verified live against YouTube's own duration filter. Ignored when Result type is channel or playlist. Options: any = Any length; short = Short (< 4 min); medium = Medium (4-20 min); long = Long (> 20 min). | any |
| language | No | Interface language — Language code sent to YouTube as hl, e.g. en. Affects relative time text ("2 days ago") and UI strings the parser reads. | en |
| uploadDate | No | Upload date — Only return videos uploaded within this window, e.g. week for the last 7 days. Verified live against YouTube's own upload-date filter. Ignored when Result type is channel or playlist. Options: any = Any time; hour = Last hour; today = Today; week = This week; month = This month; year = This year. | any |
| maxResultsPerQuery | No | Max results per query — Enter how many results to return per search query, e.g. 50. The Actor pages through YouTube's search continuations until it reaches this number or YouTube runs out of results. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose unusual operational context: no API key or quota needed, and results are billed to the caller's Apify account at roughly $0.0005 per result. It omits auth setup details, rate limits, failure behavior, and pagination cutoffs (the maxResultsPerQuery cap lives only in the schema).
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: capability and output fields first, then cost and no-key/no-quota caveat. Nothing is redundant and the most decision-relevant facts are front-loaded.
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 an 8-parameter tool with a fully documented schema and no output schema, the description covers purpose, output shape, and billing model adequately. It leaves the agent without explicit sibling routing or auth prerequisites, which is the main remaining 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% and the parameter docs are exceptionally detailed (live-verified sort behaviors, duration boundaries, ignored-when-channel caveats), so the schema already does the heavy lifting. The description adds no parameter-level meaning 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?
States a specific verb and resource: scrapes YouTube search results (videos, channels, playlists) for any keyword, and lists the returned fields. It is clearly distinguishable from sibling lookups like youtube_video_details or youtube_channel_videos by being keyword-driven, but it never names an alternative to sharpen the contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by 'for any keyword' — use it when you need keyword-based YouTube search rather than direct ID lookups. There is no explicit when-to-use, when-not-to-use, or named alternative among the nine siblings, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
YouTube Video Details Scraper returns views, likes, description, tags, category, channel and comment count for any YouTube video URL or ID — no YouTube Data API key or quota needed. Billed to your own Apify account: ~$0.001 per video (Apify free-plan price, lower on paid plans).
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Region — Enter a 2-letter country code for YouTube to use when resolving region-specific details, e.g. US. | US |
| videos | Yes | Videos — Enter YouTube video IDs or URLs, one row is returned per video. Accepts a bare ID (dQw4w9WgXcQ), a watch URL, a shorts URL, or a youtu.be link, e.g. https://www.youtube.com/watch?v=dQw4w9WgXcQ. Example: ["dQw4w9WgXcQ"]. | |
| language | No | Language — Enter a 2-letter language code YouTube should localize its UI text to, e.g. en. This affects labels like the category name and relative date text, not the video's own title or description. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two non-obvious behavioral facts: no YouTube Data API key or quota is required, and each call is billed to the caller's Apify account at ~$0.001 per video. What it omits is failure behavior for invalid/private IDs and any rate-limit context, so it is strong but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both earning their place: the first front-loads what is returned and the input domain, the second front-loads cost. No filler, no restating of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, single-purpose scraper, the description covers purpose, input shape, pricing, and auth context. It also enumerates returned fields, which partially substitutes for the missing output schema, though error cases and per-call limits remain undocumented.
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 region, videos, and language are already fully documented in the schema, including accepted ID/URL formats and localization semantics. The description adds no parameter-level meaning beyond that, making the baseline 3 the correct score.
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 ('returns views, likes, description, tags, category, channel and comment count for any YouTube video URL or ID') and names its input domain. It is clear what the tool does, though it never differentiates itself from siblings like youtube_search_scraper or youtube_comments_scraper.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the input contract — an agent should reach for it when it already has a video URL/ID. However, there is no explicit when-to-use or when-not-to-use guidance, and no mention of how it relates to the search, channel, or comments siblings in the same family.
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.
v0.1.0bluesky_scrapergoogle_search_scraperpodcast_lookupsubstack_scrapertelegram_channel_scraperyoutube_channel_scraperyoutube_channel_videosyoutube_comments_scraperyoutube_search_scraperyoutube_video_detailsScored across 10 tools
Several YouTube-related tools have overlapping purposes: youtube_search_scraper, youtube_channel_videos, and youtube_channel_scraper can all retrieve videos from channels with unclear distinctions. Similarly, youtube_comments_scraper and youtube_video_details both extract comments-related data, causing potential confusion.
Most tool names follow a consistent [platform]_[resource]_[action] pattern (e.g., youtube_search_scraper, google_search_scraper, bluesky_scraper), with minor deviations like podcast_lookup and substack_scraper that omit the action suffix but remain clear.
The server provides 10 tools covering multiple social media and web platforms, which fits the stated purpose of a multi-platform data scraping toolkit without being excessive or too sparse.
While most platforms have at least one scraper, notable gaps exist: no tools for Twitter/X, Instagram, or TikTok, which are major social media platforms. Additionally, some tools only cover specific aspects (e.g., YouTube lacks a dedicated playlist scraper), limiting completeness for a social media data toolkit.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Hosted MCP with 91 agent tools: X, domains, SEO, Maps, Trends, Search, YouTube, TikTok, and more.
Your 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
Your agent needs the open web — searched by more than one engine, and read as clean markdown rather than raw HTML. **What you can ask for** • "Search this question with two providers and tell me where they disagree." • "Scrape these 40 URLs into markdown, in one batch." • "Crawl this documentation site and give me every page." • "Do deep research on this topic and cite the sources." • "Find the academic papers behind this claim." **How to use it** Point any MCP client at https://mcp.aisa.one/search/mcp and sign in with OAuth — there is no key to create or paste. 30 tools across several independent providers: Tavily and Exa search, answers, contents and agent runs; Firecrawl scrape, batch scrape, crawl, map and search; Perplexity Sonar, Sonar Pro, reasoning and deep research; Oxylabs AI search and LLM jobs; OpenAI and Anthropic web search; and scholarly search. **Why this rather than the source** Several independent indexes behind one account, because one engine's blind spot is not visible from inside it. **It is also a door to the rest** The same login reaches 26 sources and 580+ operations. Find the page here, then ask the same agent who links to it or how much traffic it gets — without adding a second server. **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** https://mcp.aisa.one/seo-serp/mcp for the Google results page itself, https://mcp.aisa.one/seo-serp-other-engines/mcp for Bing, Baidu and Naver.
