Digest MCP Server
Uses puppeteer-core to connect to browserless.io cloud browsers for extracting fully rendered DOM content from dynamic web pages, including SPAs and infinite scroll sites, with configurable wait times and scrolling behavior.
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., "@Digest MCP Serverget the full article from https://news.example.com/long-read with cleanup"
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.
Digest MCP Server
MCP server for web content digestion using browserless.io via puppeteer-core. Extracts fully rendered DOM content from dynamic web pages including SPAs and infinite scroll sites.
Features
Connect to browserless.io cloud browsers
Load web pages with configurable wait times
Scroll down pages multiple times with delays
Extract complete page content (HTML)
Related MCP server: MCP Fetch Page
Installation
npm install
npm run buildConfiguration
Set your browserless.io API key using one of these methods:
Option 1: Using .env file (recommended)
Create a .env file in the project root:
cp .env.example .envThen edit .env and add your API key:
BROWSERLESS_API_KEY=your_api_key_hereOption 2: Using environment variable
export BROWSERLESS_API_KEY=your_api_key_hereUsage
Running the Server
The server uses stdio transport for MCP communication:
node build/index.jsTool: web_content
Fetches web page content with optional scrolling and HTML cleanup.
Parameters:
url(string, required): The URL to fetchinitialWaitTime(number, optional): Time to wait in milliseconds after loading the page. Default: 3000scrolls(number, optional): Number of times to scroll down the page. Default: 5scrollWaitTime(number, optional): Time to wait in milliseconds between each scroll. Default: 1000cleanup(boolean, optional): Whether to clean up HTML (remove scripts, styles, SVG, forms, etc.) and keep only meaningful text content. Default: false
Returns:
size(number): Size of the content in bytescontent(string): The fetched HTML content
Example:
{
"url": "https://example.com",
"initialWaitTime": 2000,
"scrolls": 3,
"scrollWaitTime": 1000,
"cleanup": true
}How It Works
Connects to browserless.io using your API key via WebSocket
Creates a new page in the remote browser
Navigates to the specified URL (waits for DOM content loaded)
Waits 1 second for page stabilization
Waits for the initial wait time (default: 3 seconds)
Scrolls to the bottom of the page the specified number of times
After each scroll, intelligently waits for new content to load by:
Monitoring page height changes
Detecting dynamically loaded content
Waiting up to scrollWaitTime for new content (default: 3 seconds)
Waits for network to idle (AJAX requests complete)
Waits 1 additional second for JavaScript rendering
Returns the fully RENDERED DOM (not raw HTML source)
Includes all JavaScript-generated content
Includes all AJAX-loaded content
Includes all dynamically inserted elements
Uses
document.documentElement.outerHTMLfor complete rendered state
Dynamic Content & Infinite Scroll
The tool is specifically designed for modern web applications with dynamic content:
AJAX/JavaScript Handling:
✅ Waits for network idle: Ensures all AJAX requests complete
✅ Returns rendered DOM: Gets actual content after JavaScript execution
✅ Not raw HTML source: Uses browser's rendered output
✅ Includes dynamic elements: Captures content inserted by React, Vue, Angular, etc.
Infinite Scroll Support:
✅ Scrolls to bottom: Triggers lazy-loading mechanisms
✅ Detects new content: Monitors page height changes
✅ Smart waiting: Exits early when content loads
✅ Multiple fallbacks: Keyboard scroll if JavaScript fails
Perfect for:
Single Page Applications (React, Vue, Angular)
Infinite scroll feeds (Twitter, Facebook, LinkedIn)
Lazy-loaded images and content
AJAX-powered content (search results, filters)
Dynamic dashboards and admin panels
Tips for best results:
Default
scrolls: 5works well for most pages with lazy-loaded contentIncrease
scrollsto 10-15 for very long infinite scroll pagesSet
scrolls: 0to disable scrolling for static pagesUse
scrollWaitTimeof 1000-3000ms for slow-loading content (default: 1000ms)Increase
initialWaitTimeto 5000+ if page has heavy initializationFor SPAs, allow time for initial JavaScript bootstrap
Use
cleanup: trueto extract only meaningful text content without scripts, styles, and visual elementsUse
cleanup: false(default) to get the full rendered HTML
MCP Client Configuration
Add to your MCP client configuration (e.g., Claude Desktop):
{
"mcpServers": {
"digest": {
"command": "node",
"args": ["/path/to/digest-mcp/build/index.js"],
"env": {
"BROWSERLESS_API_KEY": "your_api_key_here"
}
}
}
}License
ISC
Available Tools
1 toolweb_contentFetch Web ContentA
Fetch fully rendered DOM content using browserless.io. Handles AJAX/JavaScript dynamic loading. Optimized for SPAs and infinite scroll pages. Returns the complete rendered HTML after all JavaScript execution, including dynamically loaded content. Each scroll waits for page height changes and network activity to settle.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to fetch | |
| initialWaitTime | No | Time to wait (in milliseconds) after loading the page before scrolling | |
| scrolls | No | Number of times to scroll down the page | |
| scrollWaitTime | No | Time to wait (in milliseconds) between each scroll action | |
| cleanup | No | Whether to clean up HTML (remove scripts, styles, SVG, forms, etc.) and keep only meaningful text content |
Output Schema
| Name | Required | Description |
|---|---|---|
| size | Yes | Size of the content in bytes |
| content | Yes | The fetched HTML content |
TDQS
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 effectively describes key behavioral traits: it handles dynamic loading, waits for JavaScript execution, includes scrolling behavior with wait times, and mentions cleanup options. However, it lacks details on error handling, rate limits, or authentication needs, which would be beneficial for a tool with external dependencies.
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 appropriately sized and front-loaded, starting with the core purpose and progressively detailing capabilities and behavior. Each sentence adds value without redundancy, making it efficient and easy to understand quickly.
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 (external service integration, dynamic content handling) and rich schema (100% coverage, output schema exists), the description is mostly complete. It covers the tool's purpose, key behaviors, and context, but could improve by addressing potential limitations or error scenarios. The existence of an output schema means return values need not be explained.
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 schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds some context by mentioning scrolling and cleanup in general terms, but it does not provide additional semantic meaning beyond what the schema specifies (e.g., explaining why certain defaults are chosen or how parameters interact).
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 purpose with specific verbs ('Fetch fully rendered DOM content') and resource ('using browserless.io'), and distinguishes its capabilities from basic web scraping by mentioning AJAX/JavaScript handling, SPAs, infinite scroll pages, and complete rendered HTML after JavaScript execution. It provides a comprehensive overview of what the tool does beyond just fetching content.
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 implies usage scenarios (e.g., for SPAs, infinite scroll pages, dynamic content) but does not explicitly state when to use this tool versus alternatives or provide any exclusions. With no sibling tools mentioned, the lack of explicit guidance is less critical, but it still relies on implication rather than clear directives.
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.
1 tool update
v1.0.0- Changed
web_content9 fields changed- added
Input schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#" - added
Input schema / additionalPropertiesAdded value: +false - added
Input schema / properties / cleanupAdded value: +{ + "default": false, + "description": "Whether to clean up HTML (remove scripts, styles, SVG, forms, etc.) and keep only meaningful text content", + "type": "boolean" +} - removed
Input schema / properties / scrollCountRemoved value: -{ - "default": 0, - "description": "Number of times to scroll down the page", - "type": "number" -} - changed
Input schema / properties / scrollWaitTime / defaultPrevious value: -3000New value: +1000 - added
Input schema / properties / scrollsAdded value: +{ + "default": 5, + "description": "Number of times to scroll down the page", + "type": "number" +} - changed
Output schema / properties / content / descriptionPrevious value: -"The fully rendered DOM HTML content including all dynamically loaded elements"New value: +"The fetched HTML content" - added
Output schema / properties / sizeAdded value: +{ + "description": "Size of the content in bytes", + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "content" -]New value: +[ + "size", + "content" +]
1 tool update
- First observed
web_content
TDQS
With only one tool, there is no possibility of confusion or overlap between tools. The single tool 'web_content' has a clearly defined and distinct purpose of fetching fully rendered DOM content from web pages.
Since there is only one tool, naming consistency is inherently perfect. The tool name 'web_content' follows a clear and descriptive pattern, though no pattern can be established across multiple tools.
A single tool is too few for a server named 'Digest MCP Server', which suggests a broader scope of digesting or processing content. While the tool is well-described, the server's purpose likely requires more operations (e.g., parsing, summarizing, or managing multiple sources) to be effectively useful.
The tool surface is severely incomplete for a digest server. It only provides fetching of web content, with no tools for processing, analyzing, summarizing, or managing the fetched data. This creates significant gaps that will hinder agents from performing comprehensive digest-related tasks.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Crawl, scrape, search the web, and automate browsers at scale with anti-bot bypass.
Automate cloud browsers to navigate websites, interact with elements, and extract structured data.…
Headless browser primitives for AI agents when sites need real JS rendering.
Extract and parse web pages into clean HTML, links, or Markdown. Handle dynamic, complex, or block…
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceEnables 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.4MIT
- AlicenseAqualityCmaintenanceEnables browser-based web page fetching with automatic cookie management and CSS selector extraction, supporting JavaScript rendering and authenticated sessions through a Chrome extension.172MIT
- AlicenseAqualityAmaintenanceEnables web scraping, structured data extraction, and screenshot capture with automatic anti-bot bypass, supporting JavaScript rendering, proxy rotation, and tiered pricing.252181MIT
- AlicenseNot gradedqualityBmaintenanceFetches web pages with JavaScript rendering, pierces Shadow DOM, and enables interactive actions like clicking and form filling using a real Chrome browser.2MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/bakhtiyork/digest-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server