How do I use mcp-webextrator?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-webextrator extract the main article from https://example.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.

mcp-webextrator

by AceDataCloud

Overview Schema Related Servers Score Discussions

Python

Remote

MCP WebExtrator Server

A Model Context Protocol (MCP) server for web rendering and structured content extraction via the AceDataCloud WebExtrator platform.

Features

Structured extraction: Pull structured data out of any URL via WebExtrator
Web rendering: Render dynamic JavaScript pages and capture the rendered output
Asynchronous tasks: Submit extract / render jobs and poll for results
Batch task lookup: Query multiple task results in one call

Related MCP server: FreeCrawl MCP Server

Installation

pip install mcp-webextrator

Configuration

Set your AceDataCloud API token:

export ACEDATACLOUD_API_TOKEN=your_token_here

Get your token from https://platform.acedata.cloud.

Usage

stdio mode (default)

mcp-webextrator

HTTP mode

mcp-webextrator --transport http --port 8000

Available Tools

Tool	Description
`webextrator_extract`	Extract structured content from a URL
`webextrator_render`	Render a dynamic web page and return the rendered output
`webextrator_get_task`	Get the status / result of an extract or render task
`webextrator_get_tasks_batch`	Batch-fetch the status / result of multiple tasks
`webextrator_get_usage_guide`	Get the API usage guide

Documentation

License

MIT — see LICENSE.

Available Tools

5 tools

webextrator_extractA

Extract structured content from a web page using the WebExtrator API.

Navigates to the specified URL, renders the page, and extracts structured data
such as product details, article content, or general page information.

Use this when:
- You need to extract structured data from a web page
- You want product details, article content, or general page data
- You need LLM-enhanced semantic normalization of extracted content

Returns:
    By default, the extracted structured content inline. With async=true, a JSON envelope with a `task_id` — poll `webextrator_get_task` until it reports `finished_at`, then read the extracted content from its `response`.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL of the web page to extract content from. Required.
`async`	No	Whether to process the request asynchronously.
`delay`	No	Extra delay in seconds after page load before extracting.
`headers`	No	Extra HTTP headers to include with the page request.
`timeout`	No	Total timeout in seconds for page load. Default is 30.
`enable_llm`	No	Enable LLM-based semantic normalization for richer structured output. Default is false.
`user_agent`	No	Override the User-Agent header for the page request.
`wait_until`	No	Page load wait condition before extracting. Options: 'load', 'domcontentloaded', 'networkidle', 'commit'. Default is 'networkidle'.
`callback_url`	No	Callback URL for async processing. If provided, the task runs asynchronously and results are sent to this URL when complete.
`expected_type`	No	Hint about expected page type. Options: 'product', 'article', 'general'. Helps the extractor optimize for the content structure.
`block_resources`	No	Resource types to block during page load to speed up rendering. Options: 'image', 'font', 'media', 'stylesheet', 'xhr', 'fetch'.
`wait_for_selector`	No	CSS selector to wait for before extracting content.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It transparently reveals the core behaviors: navigation, rendering, extraction, sync vs. async returns, and LLM enhancement. It even describes the async envelope structure and how to retrieve results. While it doesn't discuss error handling or rate limits, for a read-only extraction tool this is adequate disclosure.

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

Conciseness4/5

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

The description is well-structured with a short purpose statement, a 'Use this when' bullet list, and a 'Returns' section. It front-loads the core purpose and includes necessary workflow details without extra fluff. It's slightly longer than minimal, but every section earns its place.

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

Completeness4/5

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

Given the tool's complexity (12 parameters, async support, callback URLs), the description covers the key workflow: how to run synchronously vs. asynchronously, how to poll for async results, and the supported content types. It also notes LLM enhancement. Missing details like error handling or specific exceptions are minor given the available output schema and the clear description of the primary flow.

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

Parameters3/5

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

Schema coverage is 100%, so the description doesn't need to restate parameters. It adds context for async (via callback_url and async flag), LLM normalization (enable_llm), and the wait_until options, but doesn't go into depth on each parameter. This aligns with the baseline of 3—the schema handles most semantics, and the description clarifies the most important behavior details.

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

Purpose5/5

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

The description clearly states the tool's action ('Extract structured content from a web page') and names the specific resources (product details, article content, general page info). It distinguishes itself from siblings like webextrator_render by focusing on structured extraction rather than rendering.

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

Usage Guidelines4/5

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

The 'Use this when' section explicitly lists scenarios, and the description explains the async flow with webextrator_get_task for polling results. It doesn't explicitly contrast with alternative tools (e.g., when to use webextrator_render instead), but the primary use cases are clear enough for an agent to select this tool correctly.

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

webextrator_get_taskA

Retrieve the result of a single previously created extract or render task.

Use this when:
- You submitted an extract or render request and got back a task_id
- You want to poll for the result of a specific task by its ID

Returns:
    JSON response containing the task status and result data.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	No	Task UUID to retrieve. Use this to get the result of a single extract or render task.
`trace_id`	No	Trace UUID as an alternative lookup for a single task. Use either task_id or trace_id.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states the tool returns task status and result data, and implies polling behavior. However, it does not disclose whether the task is deleted after retrieval or any other side effects. The description is adequate but not thorough.

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

Conciseness5/5

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

The description is very concise: three short sentences plus bullet-like use cases. It is front-loaded with the verb and resource. No wasted words.

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

Completeness4/5

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

The tool is simple, schema covers all parameters, and output schema exists (so return format is explained). The description is sufficient for basic usage. It could mention that no parameters are required, but that is implied by default values.

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

Parameters4/5

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

Schema coverage is 100% with both parameters described. The description adds value by clarifying that task_id is obtained from an extract/render request and that trace_id is an alternative lookup. This enhances understanding beyond the schema.

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

Purpose5/5

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

The description clearly states it retrieves the result of a single previously created extract or render task. The verb 'Retrieve' and resource 'result of a single... task' are specific. It distinguishes from siblings like webextrator_get_tasks_batch which retrieves batch results.

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

Usage Guidelines4/5

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

The description provides two explicit 'Use this when' conditions: after submitting an extract/render request and getting a task_id, and when wanting to poll for a specific task by ID. This gives clear context, though it could explicitly mention alternatives like 'for batch retrieval, use webextrator_get_tasks_batch'.

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

webextrator_get_tasks_batchA

Retrieve the results of multiple previously created extract or render tasks.

Use this when:
- You submitted multiple async requests and want to check their results together
- You want to paginate through a list of tasks

Returns:
    JSON response containing the list of task statuses and result data.

ParametersJSON Schema

Name	Required	Description
`ids`	No	List of task UUIDs to retrieve in batch.
`limit`	No	Pagination limit for batch retrieval, 1-100. Default is 50.
`offset`	No	Pagination offset for batch retrieval. Default is 0.
`trace_ids`	No	List of trace UUIDs to retrieve in batch.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries burden. Mentions returns JSON with statuses and result data, but no details on idempotency, rate limits, or side effects. Adequate but not detailed.

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

Conciseness5/5

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

Two concise paragraphs, front-loaded with purpose and usage guidelines. No redundant information.

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

Completeness4/5

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

Given output schema exists and good parameter documentation, description is mostly complete. Could mention that tasks are created by webextrator_extract or webextrator_render, but not essential.

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

Parameters3/5

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

Schema coverage is 100% with parameter descriptions. Description adds context on pagination and batch retrieval by IDs/trace_ids, but does not significantly enhance understanding beyond schema.

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

Purpose5/5

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

Clearly states it retrieves results of multiple extract/render tasks, distinguishing from sibling webextrator_get_task which handles single task retrieval.

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

Usage Guidelines4/5

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

Explicitly describes when to use: after multiple async requests or for pagination. Lacks explicit 'when not to use' but context is clear.

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

webextrator_get_usage_guideA

Get a comprehensive guide for using the WebExtrator tools.

Provides detailed information on how to use the WebExtrator tools effectively,
including parameters, examples, and best practices for web extraction and rendering.

Returns:
    Complete usage guide for WebExtrator tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, but description clearly indicates a read-only operation returning a guide, with no destructive or complex side effects mentioned. Minimal but sufficient.

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

Conciseness4/5

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

Concise at 4 lines, but slightly redundant (returns statement repeats purpose). Efficient overall.

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

Completeness5/5

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

For a simple help tool with no parameters and an output schema, the description is complete—states purpose and return value adequately.

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

Parameters4/5

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

No parameters exist, so schema coverage is 100%. Description doesn't need to add param details, but could mention no parameters are required.

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

Purpose5/5

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

The description clearly states the tool returns a comprehensive guide for using WebExtrator tools, distinguishing it from sibling tools that perform extractions or task management.

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

Usage Guidelines3/5

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

Implied use when guidance is needed, but no explicit when-to-use or alternatives guidance. Sibling tools are different operations, but the description doesn't advise against using them.

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

webextrator_renderA

Render a web page and return the fully rendered HTML.

Uses a headless browser to navigate to the specified URL, waits for JavaScript
to execute, and returns the final rendered HTML source.

Use this when:
- You need the fully rendered HTML of a JavaScript-heavy page
- You want to inspect the DOM after dynamic content has loaded
- You need to capture single-page application (SPA) content

Returns:
    By default, the rendered HTML content inline. With async=true, a JSON
    envelope with a `task_id` — poll `webextrator_get_task` until it reports
    `finished_at`, then read the rendered HTML from its `response`.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	The URL of the web page to render. Required.
`async`	No	Whether to process the request asynchronously.
`delay`	No	Extra delay in seconds after page load before capturing HTML.
`headers`	No	Extra HTTP headers to include with the page request.
`timeout`	No	Total timeout in seconds for page load. Default is 30.
`user_agent`	No	Override the User-Agent header for the page request.
`wait_until`	No	Page load wait condition before capturing HTML. Options: 'load', 'domcontentloaded', 'networkidle', 'commit'. Default is 'networkidle'.
`callback_url`	No	Callback URL for async processing. If provided, the task runs asynchronously and results are sent to this URL when complete.
`block_resources`	No	Resource types to block during page load to speed up rendering. Options: 'image', 'font', 'media', 'stylesheet', 'xhr', 'fetch'.
`wait_for_selector`	No	CSS selector to wait for before capturing HTML.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral disclosure burden. It explains the headless-browser mechanism, JavaScript execution wait, and the inline vs. async return behavior, including polling instructions via webextrator_get_task. It does not cover error cases, rate limits, or security implications of executing JS, but the core behavior is transparently described.

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

Conciseness5/5

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

The description is appropriately sized and front-loaded: a one-line summary, a brief mechanism sentence, a compact 'Use this when' list, and a Return section. Every sentence earns its place, and the structure makes it skimmable for an agent.

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

Completeness5/5

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

Given the output schema exists and the input schema has 100% coverage, the description effectively fills the remaining gaps: async processing, task polling flow, and primary use cases. It also cross-references the sibling polling tool, making the complete call-and-retrieve workflow clear without requiring schema inspection.

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

Parameters3/5

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 even though the free-text description adds no per-parameter detail. The description's async explanation and return-format notes are helpful context but not parameter semantics; the schema already documents all parameters, defaults, and enums.

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

Purpose5/5

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

The description opens with a specific verb and resource: 'Render a web page and return the fully rendered HTML.' It clearly distinguishes the tool from siblings like webextrator_extract by focusing on full-page rendering rather than data extraction, and it reinforces the purpose with concrete use cases (JavaScript-heavy pages, DOM inspection, SPA content).

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

Usage Guidelines4/5

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

The 'Use this when' bullet list gives explicit scenarios for when the tool is appropriate, such as needing fully rendered HTML after dynamic content loads. However, it does not explicitly state when not to use it or name alternative siblings like webextrator_extract for non-rendering extraction tasks, so the exclusionary guidance is missing.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

2 tool updatesv0.1.7Aug 28, 2026

Changedwebextrator_extract5 fields changed

addedInput schema / properties / async

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Whether to process the request asynchronously.",
+  "title": "Async"
+}

removedInput schema / properties / bypass_cache

Removed value: -{
-  "anyOf": [
-    {
-      "type": "boolean"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Skip the Redis result cache for this request (still writes the fresh result back). Default is false.",
-  "title": "Bypass Cache"
-}

removedInput schema / properties / cache_ttl_seconds

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Override the global cache TTL (seconds) for this entry. 0 means do not cache this response. Default is 3600.",
-  "title": "Cache Ttl Seconds"
-}

removedInput schema / properties / cookies

Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Cookies to install before navigation. Each cookie is an object with at least 'name' and 'value', plus optional 'domain', 'path', 'expires', 'httpOnly', 'secure', 'sameSite'. Useful for authenticated pages.",
-  "title": "Cookies"
-}

removedInput schema / properties / mode

Removed value: -{
-  "anyOf": [
-    {
-      "enum": [
-        "sync",
-        "async"
-      ],
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Processing mode. Defaults to API sync behavior. Pass 'async' to return immediately with a task_id to poll via webextrator_get_task.",
-  "title": "Mode"
-}

Changedwebextrator_render5 fields changed

addedInput schema / properties / async

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Whether to process the request asynchronously.",
+  "title": "Async"
+}

removedInput schema / properties / bypass_cache

Removed value: -{
-  "anyOf": [
-    {
-      "type": "boolean"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Skip the Redis result cache for this request (still writes the fresh result back). Default is false.",
-  "title": "Bypass Cache"
-}

removedInput schema / properties / cache_ttl_seconds

Removed value: -{
-  "anyOf": [
-    {
-      "type": "number"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Override the global cache TTL (seconds) for this entry. 0 means do not cache this response. Default is 3600.",
-  "title": "Cache Ttl Seconds"
-}

removedInput schema / properties / cookies

Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Cookies to install before navigation. Each cookie is an object with at least 'name' and 'value', plus optional 'domain', 'path', 'expires', 'httpOnly', 'secure', 'sameSite'. Useful for authenticated pages.",
-  "title": "Cookies"
-}

removedInput schema / properties / mode

Removed value: -{
-  "anyOf": [
-    {
-      "enum": [
-        "sync",
-        "async"
-      ],
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Processing mode. Defaults to API sync behavior. Pass 'async' to return immediately with a task_id to poll via webextrator_get_task.",
-  "title": "Mode"
-}

2 tool updatesv0.1.5Aug 17, 2026

Changedwebextrator_extract1 field changed

changedInput schema / properties / mode / description

Previous value: -"Processing mode. Defaults to 'async': returns immediately with a task_id to poll via webextrator_get_task. Pass 'sync' to wait for the result inline (may time out on slow pages)."New value: +"Processing mode. Defaults to API sync behavior. Pass 'async' to return immediately with a task_id to poll via webextrator_get_task."

Changedwebextrator_render1 field changed

changedInput schema / properties / mode / description

Previous value: -"Processing mode. Defaults to 'async': returns immediately with a task_id to poll via webextrator_get_task. Pass 'sync' to wait for the result inline (may time out on slow pages)."New value: +"Processing mode. Defaults to API sync behavior. Pass 'async' to return immediately with a task_id to poll via webextrator_get_task."

2 tool updatesv0.1.3Jul 28, 2026

Changedwebextrator_extract1 field changed

changedInput schema / properties / mode / description

Previous value: -"Processing mode. 'sync' (default) waits for the result; 'async' returns immediately with a task_id to poll via the Tasks API."New value: +"Processing mode. Defaults to 'async': returns immediately with a task_id to poll via webextrator_get_task. Pass 'sync' to wait for the result inline (may time out on slow pages)."

Changedwebextrator_render1 field changed

changedInput schema / properties / mode / description

Previous value: -"Processing mode. 'sync' (default) waits for the result; 'async' returns immediately with a task_id to poll via the Tasks API."New value: +"Processing mode. Defaults to 'async': returns immediately with a task_id to poll via webextrator_get_task. Pass 'sync' to wait for the result inline (may time out on slow pages)."

3 tool updatesv0.1.2Jul 5, 2026

Changedwebextrator_extract4 fields changed

addedInput schema / properties / bypass_cache

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Skip the Redis result cache for this request (still writes the fresh result back). Default is false.",
+  "title": "Bypass Cache"
+}

addedInput schema / properties / cache_ttl_seconds

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Override the global cache TTL (seconds) for this entry. 0 means do not cache this response. Default is 3600.",
+  "title": "Cache Ttl Seconds"
+}

addedInput schema / properties / cookies

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Cookies to install before navigation. Each cookie is an object with at least 'name' and 'value', plus optional 'domain', 'path', 'expires', 'httpOnly', 'secure', 'sameSite'. Useful for authenticated pages.",
+  "title": "Cookies"
+}

addedInput schema / properties / mode

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "sync",
+        "async"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Processing mode. 'sync' (default) waits for the result; 'async' returns immediately with a task_id to poll via the Tasks API.",
+  "title": "Mode"
+}

Changedwebextrator_get_tasks_batch1 field changed

changedInput schema / properties / limit / description

Previous value: -"Pagination limit for batch retrieval. Default is 12."New value: +"Pagination limit for batch retrieval, 1-100. Default is 50."

Changedwebextrator_render4 fields changed

addedInput schema / properties / bypass_cache

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Skip the Redis result cache for this request (still writes the fresh result back). Default is false.",
+  "title": "Bypass Cache"
+}

addedInput schema / properties / cache_ttl_seconds

Added value: +{
+  "anyOf": [
+    {
+      "type": "number"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Override the global cache TTL (seconds) for this entry. 0 means do not cache this response. Default is 3600.",
+  "title": "Cache Ttl Seconds"
+}

addedInput schema / properties / cookies

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Cookies to install before navigation. Each cookie is an object with at least 'name' and 'value', plus optional 'domain', 'path', 'expires', 'httpOnly', 'secure', 'sameSite'. Useful for authenticated pages.",
+  "title": "Cookies"
+}

addedInput schema / properties / mode

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "sync",
+        "async"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Processing mode. 'sync' (default) waits for the result; 'async' returns immediately with a task_id to poll via the Tasks API.",
+  "title": "Mode"
+}

5 tool updatesv0.1.0Jun 28, 2026
- First observedwebextrator_extract
- First observedwebextrator_get_task
- First observedwebextrator_get_tasks_batch
- First observedwebextrator_get_usage_guide
- First observedwebextrator_render

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Disambiguation5/5

Each tool has a distinct purpose: extract vs render are different outputs, guide is informational, task retrieval tools are for async result polling. No overlap between tools.

Naming Consistency5/5

All tools share the 'webextrator_' prefix and use snake_case with a clear verb_noun pattern (extract, render, get_usage_guide, get_task, get_tasks_batch), ensuring predictability.

Tool Count5/5

Five tools cover the core functionality: two main operations (extract, render), a usage guide, and two task management helpers. This is well-scoped for a web extraction server.

Completeness4/5

The tool surface covers extraction, rendering, and async task retrieval. Minor gaps include lack of task listing or cancellation, but the batch retrieval and guide mitigate this for typical use.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AI Website-to-JSON Data Scraper & ExtractorOAuth
com.ranovam
Turn any website into structured JSON data matching your custom schema.
Browser Automation Web Scraping
1
Hydrafetch A
com.hydrafetch
Turn any URL into clean Markdown and structured data. Scrape, crawl, search and extract.
Browser Automation Web Scraping
131
arjunkmrm-scrapermcp_elOAuth
ai.smithery
Extract and parse web pages into clean HTML, links, or Markdown. Handle dynamic, complex, or block…
Web Scraping Browser Automation
2
arjunkmrm-fetchOAuth
ai.smithery
Fetch web pages and extract exactly the content you need. Select elements with CSS and retrieve co…
Web Scraping Browser Automation Search
2

Related MCP Servers

Fetch MCP Server
Web Scraping Browser Automation
phpmac
A
license
Not graded
quality
C
maintenance
Provides functionality to fetch and transform web content in various formats (HTML, JSON, plain text, and Markdown) through simple API calls.
Updated a year ago (2025-07-29 20:06 UTC)
102,856
1
MIT
FreeCrawl MCP Server
Web Scraping Browser Automation Documentation Access
dylan-gluck
A
license
Not graded
quality
D
maintenance
Enables web scraping and document processing with JavaScript execution, anti-detection measures, batch processing, and structured data extraction. Supports multiple formats including markdown, HTML, screenshots, and handles PDFs with OCR capabilities.
Updated a year ago (2025-08-20 03:34 UTC)
4
MIT
alterlab-mcp-server
Web Scraping Browser Automation
RapierCraft
A
license
A
quality
A
maintenance
Enables web scraping, structured data extraction, and screenshot capture with automatic anti-bot bypass, supporting JavaScript rendering, proxy rotation, and tiered pricing.
Updated 2 days ago (2026-09-04 07:13 UTC)
25
218
1
MIT
url-text-fetcher
Web Scraping Browser Automation
evgenyigumnov
A
license
A
quality
D
maintenance
Enables extracting visible text and links from webpages for content analysis.
Updated a year ago (2025-08-03 13:48 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AceDataCloud/WebExtratorMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server