Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Scrapedo MCP Server Scrape the headlines from https://news.ycombinator.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Enable Claude Desktop to scrape websites using the Scrapedo API. Simple setup, powerful features.
This is an MCP (Model Context Protocol) server that gives Claude Desktop the ability to:
Scrape any website (with or without JavaScript)
Take screenshots
Use proxies from different countries
Convert web pages to markdown
Related MCP server: mcp-webscraper
Sign up at scrape.do to get your free API key.
Run this command:
npx scrapedo-mcp-server initThat's it! The tool will automatically configure Claude Desktop for you.
Just ask Claude to scrape any website:
"Can you scrape the latest news from https://example.com?"
"Take a screenshot of the Google homepage"
"Get the product prices from this e-commerce site using a US proxy"npm install -g scrapedo-mcp-server
scrapedo-mcp initgit clone https://github.com/umutc/scrapedo-mcp-server.git
cd scrapedo-mcp-server
npm install
npm run buildAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"scrapedo": {
"command": "npx",
"args": ["scrapedo-mcp-server", "start"],
"env": {
"SCRAPEDO_API_KEY": "your_api_key_here"
}
}
}
}// Claude can now do this:
scrape("https://example.com")// For modern SPAs and dynamic content:
scrape_with_js("https://app.example.com", {
waitSelector: ".content-loaded"
})// Capture any webpage:
take_screenshot("https://example.com", {
fullPage: true
})// Super requests with geo-targeting:
scrape("https://example.com", {
super: true, // Switch to residential & mobile pool
geoCode: "us", // Country code (defaults to "us" if omitted)
sessionId: 42 // Optional sticky session
})scrape_with_js("https://app.example.com", {
playWithBrowser: JSON.stringify([
{ action: "wait", selector: ".cookie-banner", timeout: 2000 },
{ action: "click", selector: ".accept" },
{ action: "type", selector: "#search", value: "gaming laptop" },
{ action: "press", key: "Enter" },
{ action: "wait", selector: ".results" }
])
})scrape_with_js("https://example.com/product", {
screenShot: true, // or fullScreenShot / particularScreenShot
returnJSON: true, // enforced automatically when screenshot flags are set
callback: encodeURI("https://webhook.site/your-endpoint"),
customHeaders: false, // override Scrape.do default headers
forwardHeaders: true
})// Get clean, readable content:
scrape_to_markdown("https://blog.example.com/article")Toggle headers/cookies: customHeaders, extraHeaders, forwardHeaders, setCookies, pureCookies
Switch response modes: transparentResponse, returnJSON, showFrames, showWebsocketRequests, output: 'markdown'
Combine screenshots with scraping by setting screenShot, fullScreenShot, or particularScreenShot (only one at a time; automatically forces render + returnJSON)
Receive results later via callback webhooks (Scrape.do posts JSON payloads to the provided URL)
scrapedo-mcp-server/
├── src/ # TypeScript source code
│ ├── index.ts # MCP server entry point
│ ├── cli.ts # CLI tool for setup
│ └── tools/ # Scraping tool implementations
├── dist/ # Compiled JavaScript (generated)
├── package.json # Project configuration
└── README.md # You are hereScrapedo charges credits per request type:
Features | Credits Usage |
Normal Request (Datacenter) | 1 |
Datacenter + Headless Browser (JS Render) | 5 |
Residential & Mobile Request ( | 10 |
Residential & Mobile Request + Headless Browser | 25 |
Check your usage anytime by asking Claude: "Check my Scrapedo usage stats"
Price Monitoring: Track product prices across e-commerce sites
News Aggregation: Collect articles from multiple sources
Data Research: Gather public information for analysis
Content Migration: Export content from websites
SEO Analysis: Check how pages render for search engines
Competitive Analysis: Monitor competitor websites
Q: Do I need to install anything?
A: Just Node.js 18+. Everything else is handled by npx.
Q: How do I update?
A: Run npx scrapedo-mcp-server@latest init to get the newest version.
Q: Is this free?
A: The MCP server is free. Scrapedo offers a free tier with limited credits.
Q: Can I use this with other MCP clients?
A: Yes! This works with any MCP-compatible client, not just Claude Desktop.
Q: How do I see debug logs?
A: Set LOG_LEVEL=DEBUG in your environment or configuration.
Q: How do I disable logging?
A: Set LOG_LEVEL=NONE to stop writing logs entirely.
Issue | Solution |
"Tool not found" | Restart Claude Desktop |
"401 Unauthorized" | Check your API key is correct |
"Insufficient credits" | Check usage with |
"Empty response" | The site might need JavaScript rendering |
We welcome contributions! See CONTRIBUTING.md for guidelines.
MIT - See LICENSE file
Built with ❤️ to make web scraping easy in Claude Desktop
Get API usage statistics and remaining credits
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Get' implies a read-only operation, and it states the kind of data returned. However, it does not disclose any additional behavioral traits such as whether it consumes credits, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the essential information without any wasted words. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity - no parameters, no annotations, no output schema - the description is reasonably complete. It states what the tool does and what information it provides. A bit more context (e.g., using it to check quota before scraping) would improve it, but it is sufficient for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description correctly focuses on what the tool returns rather than input details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving API usage statistics and remaining credits. It uses a specific verb ('Get') and resource ('API usage statistics and remaining credits'), and it is distinct from the sibling scraping tools.
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 provides no explicit guidance on when to use this tool versus alternatives. While siblings are all scraping tools, making the distinction obvious, there is no stated context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Basic web scraping without JavaScript rendering
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scrape | |
| body | No | Request body for POST/PUT | |
| super | No | Use residential & mobile proxy network (Super requests) | |
| device | No | Device type to emulate | |
| method | No | HTTP method (default: GET) | |
| output | No | Output format (raw HTML/text or markdown) | |
| geoCode | No | Country code for proxy location (defaults to "us" when Super and region unspecified) | |
| timeout | No | Request timeout in milliseconds (5000-120000) | |
| blockAds | No | Block advertisements | |
| callback | No | Webhook URL for asynchronous delivery (url-encoded) | |
| sessionId | No | Sticky session ID (0-1000000) for maintaining the same IP | |
| returnJSON | No | Return Scrape.do JSON payload (required for screenshots/frames data) | |
| screenShot | No | Capture default viewport screenshot (requires render & returnJSON) | |
| setCookies | No | Send cookies to the target site (use JSON string or cookie header) | |
| showFrames | No | Return iframe/frame metadata (requires returnJSON) | |
| pureCookies | No | Return cookies exactly as sent by the target | |
| disableRetry | No | Disable automatic retry on failure | |
| extraHeaders | No | Forward extra upstream headers | |
| retryTimeout | No | Retry timeout in milliseconds (5000-55000) | |
| customHeaders | No | Let Scrape.do add default headers automatically | |
| blockResources | No | Block images, CSS, fonts to speed up loading | |
| forwardHeaders | No | Forward client headers to the target site | |
| fullScreenShot | No | Capture full-page screenshot (requires render & returnJSON) | |
| playWithBrowser | No | JSON-encoded Play-with-Browser action list (array or DSL string) | |
| regionalGeoCode | No | Regional proxy location | |
| disableRedirection | No | Disable following redirects | |
| transparentResponse | No | Return the origin response body directly with no parsing | |
| particularScreenShot | No | Capture CSS selector screenshot (selector must be URL-encoded) | |
| showWebsocketRequests | No | Return websocket request/response logs (requires returnJSON) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'basic' and 'without JavaScript rendering', but does not explain response formats, default methods, proxy usage, retries, or other behaviors. This is insufficient for a tool with 29 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and wastes no words. It effectively communicates the core purpose in minimal space, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (29 parameters), lack of output schema, and no annotations, the one-sentence description is inadequate. It fails to explain return values, overall workflow, or what to expect from the tool, leaving the agent with insufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific information beyond what the schema already provides, meaning it does not enhance parameter understanding.
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 'Basic web scraping without JavaScript rendering' clearly identifies the tool's function (web scraping) and its scope (no JS rendering). This directly differentiates it from the sibling tool scrape_with_js, making its purpose 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 phrase 'without JavaScript rendering' implies this tool is for static pages when JS execution is not required, contrasting with scrape_with_js. However, it doesn't explicitly mention alternatives or when-not-to-use cases, so it falls short of fully explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape and convert to markdown format
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scrape | |
| body | No | Request body for POST/PUT | |
| super | No | Use residential proxy | |
| device | No | Device to emulate | |
| method | No | HTTP method (default: GET) | |
| render | No | Enable JavaScript rendering | |
| geoCode | No | Country code for proxy | |
| timeout | No | Request timeout in milliseconds (5000-120000) | |
| blockAds | No | Block advertisements | |
| callback | No | Webhook URL for async delivery (url-encoded) | |
| sessionId | No | Sticky session ID (0-1000000) | |
| setCookies | No | Send cookies to the target (JSON or header format) | |
| pureCookies | No | Return cookies as provided by the target | |
| disableRetry | No | Disable automatic retry | |
| extraHeaders | No | Forward extra upstream headers | |
| retryTimeout | No | Retry timeout in milliseconds (5000-55000) | |
| customHeaders | No | Let Scrape.do inject default headers | |
| blockResources | No | Block images, CSS, fonts to speed up loading | |
| forwardHeaders | No | Forward tool consumer headers to target | |
| playWithBrowser | No | JSON-encoded Play-with-Browser script to run before conversion | |
| regionalGeoCode | No | Regional proxy location (europe, asia, etc.) | |
| disableRedirection | No | Disable auto redirect following |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral transparency. It does not mention that the tool performs network requests, potential authentication needs, rate limits, or side effects. For a scraping tool, this is a significant disclosure gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but for a tool with 22 parameters it is under-specified. It is not bloated, but it lacks structure and fails to add value beyond the basic purpose.
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?
The tool has high complexity (22 params, no output schema), and the description is incomplete. It states the output format (markdown) but gives no information about return values, error behavior, parameter interactions, or typical use cases. The required URL parameter is not mentioned in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of all 22 parameters with descriptions, so the baseline is 3. The description adds no meaning beyond the schema, but it also does not contradict or omit anything the schema already covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core action ('Scrape and convert to markdown format') with a clear subject (URL via required parameter). It differentiates from the sibling 'scrape' by specifying markdown output, though it does not explicitly name alternatives.
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?
No guidance is provided on when to use this tool versus siblings like 'scrape' or 'scrape_with_js'. There are no prerequisites, exclusions, or context about ideal use cases, leaving the agent to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape JavaScript-rendered pages using headless browser
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to scrape | |
| body | No | Request body for POST/PUT | |
| super | No | Use residential & mobile proxy network (Super requests) | |
| width | No | Browser viewport width (default: 1920) | |
| device | No | Device type to emulate | |
| height | No | Browser viewport height (default: 1080) | |
| method | No | HTTP method (default: GET) | |
| output | No | Output format (raw HTML/text or markdown) | |
| render | No | Enable JavaScript rendering (forced true) | |
| geoCode | No | Country code for proxy location (defaults to "us" when Super and region unspecified) | |
| timeout | No | Request timeout in milliseconds (5000-120000) | |
| blockAds | No | Block advertisements | |
| callback | No | Webhook URL for asynchronous delivery (url-encoded) | |
| sessionId | No | Sticky session ID (0-1000000) for maintaining the same IP | |
| waitUntil | No | Wait condition for page load | |
| customWait | No | Additional wait time in milliseconds | |
| returnJSON | No | Return Scrape.do JSON payload (required for screenshots/frames data) | |
| screenShot | No | Capture default viewport screenshot (requires render & returnJSON) | |
| setCookies | No | Send cookies to the target site (use JSON string or cookie header) | |
| showFrames | No | Return iframe/frame metadata (requires returnJSON) | |
| pureCookies | No | Return cookies exactly as sent by the target | |
| disableRetry | No | Disable automatic retry on failure | |
| extraHeaders | No | Forward extra upstream headers | |
| retryTimeout | No | Retry timeout in milliseconds (5000-55000) | |
| waitSelector | No | CSS selector to wait for before capturing | |
| customHeaders | No | Let Scrape.do add default headers automatically | |
| blockResources | No | Block images, CSS, fonts to speed up loading | |
| forwardHeaders | No | Forward client headers to the target site | |
| fullScreenShot | No | Capture full-page screenshot (requires render & returnJSON) | |
| playWithBrowser | No | JSON-encoded Play-with-Browser action list (array or DSL string) | |
| regionalGeoCode | No | Regional proxy location | |
| disableRedirection | No | Disable following redirects | |
| transparentResponse | No | Return the origin response body directly with no parsing | |
| particularScreenShot | No | Capture CSS selector screenshot (selector must be URL-encoded) | |
| showWebsocketRequests | No | Return websocket request/response logs (requires returnJSON) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the core function. There is no mention of headless browser nuances, asynchronous delivery, proxy behavior, retries, screenshots, or dependencies like 'returnJSON'. This is a significant omission for a tool with 35 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence and front-loaded, but it is under-specified. While concise, it fails to provide sufficient detail to be useful; it is a terse statement rather than a helpful summary. The brevity is not backed by meaningful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (35 parameters, no output schema, no annotations), the description is grossly inadequate. It provides no context about return values, async behavior, limitations, or prerequisites. The agent cannot reasonably understand the tool's full scope from this description alone.
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 parameters are fully documented in the schema. The description adds no extra semantic meaning, but with complete schema coverage, the baseline of 3 is appropriate. No parameter information is missing from the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes JavaScript-rendered pages using a headless browser, which identifies the specific resource and action. It distinguishes from sibling tools like 'scrape' (likely static) and 'scrape_to_markdown' (formatting), though it doesn't explicitly name them.
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?
No guidance is provided on when to use this tool versus alternatives. It lacks exclusions or contextual cues, leaving the agent to infer usage from the name alone. The presence of sibling tools like 'scrape' suggests complementary use cases but is never addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture webpage screenshots
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL to capture | |
| super | No | Use residential & mobile proxy network | |
| width | No | Viewport width (default: 1920) | |
| device | No | Device type to emulate | |
| height | No | Viewport height (default: 1080) | |
| geoCode | No | Country code for proxy routing (defaults to "us" if omitted in Super mode) | |
| timeout | No | Request timeout in milliseconds (5000-120000) | |
| blockAds | No | Block advertisements | |
| callback | No | Webhook URL for async delivery (url-encoded) | |
| fullPage | No | Capture full page screenshot | |
| selector | No | CSS selector of specific element to capture | |
| sessionId | No | Sticky session ID (0-1000000) | |
| waitUntil | No | Wait condition for render completion | |
| customWait | No | Additional wait time in milliseconds | |
| setCookies | No | Send cookies to the target (JSON or header format) | |
| pureCookies | No | Return cookies exactly as target provided | |
| disableRetry | No | Disable automatic retry | |
| extraHeaders | No | Forward extra upstream headers | |
| retryTimeout | No | Retry timeout in milliseconds (5000-55000) | |
| waitSelector | No | CSS selector to wait for before shooting | |
| customHeaders | No | Let Scrape.do add default headers automatically | |
| forwardHeaders | No | Forward tool consumer headers to the target | |
| regionalGeoCode | No | Regional proxy location | |
| disableRedirection | No | Disable automatic redirect following |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic function and does not mention critical behaviors such as JavaScript execution, retry logic, proxy usage, cookie handling, or return formats. The schema hints at these features, but the description itself adds no transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and free of fluff. It is appropriately sized for a simple purpose, though given the tool's complexity, a bit more detail would be helpful. Still, as far as conciseness, it scores well.
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?
The tool is highly complex with 24 parameters, no annotations, and no output schema. The one-sentence description is grossly inadequate; it does not explain return values, usage scenarios, error conditions, or how the tool behaves. This is a significant completeness gap for such a feature-rich tool.
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% for all 24 parameters, so the description is not required to explain parameters. Since the schema already documents each parameter with clear descriptions, the description adds no additional semantic value, but 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?
The description 'Capture webpage screenshots' clearly states the action (capture) and resource (webpage screenshots), and it distinguishes itself from sibling scraping tools like scrape and scrape_with_js by focusing on visual capture. However, it lacks specificity about screenshot variants (full-page, element, etc.), which are only in 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?
The description offers no guidance on when to use this tool versus alternatives such as scrape_with_js or scrape. There is no mention of use cases, exclusions, or prerequisites. Users are left to infer from the name and schema that it is for screenshots, but the description does not explicitly clarify when it should be preferred.
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. Dates show when Glama detected each change.
v1.2.8get_usage_statsscrapescrape_to_markdownscrape_with_jstake_screenshotThe three scraping tools (scrape, scrape_with_js, scrape_to_markdown) overlap in core functionality, but their names clearly indicate use cases: basic, JS-rendered, and markdown output. Screenshot and usage stats are distinct. Minor ambiguity remains between scrape and scrape_to_markdown regarding whether the latter also handles JS rendering.
All tool names use snake_case and follow a verb-first pattern (e.g., take_screenshot, get_usage_stats). The bare verb 'scrape' slightly deviates from the verb_noun structure, but it remains readable and consistent with the overall style.
Five tools is well-suited for a scraping server, covering essential capabilities without unnecessary bloat. Each tool serves a distinct purpose, and the count is within the ideal 3-15 range.
The toolset covers the core scraping lifecycle: basic scraping, JS-rendered scraping, screenshots, markdown conversion, and usage tracking. Minor gaps like session/cookie handling exist, but they are not critical for standard scraping workflows and can be worked around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Enable language models to perform advanced AI-powered web scraping with enterprise-grade reliabili…
Cloud scraping & crawling API for AI agents. Turn any URL into clean, LLM-ready markdown.
Web scraping for AI agents. Extract text and metadata from any URL worldwide. $0.005/page.
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/umutc/scrapedo-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server