## Summary
- Add `background` boolean parameter to the `new_page` tool
- When set to `true`, the new page opens in the background without
bringing it to the front
- Uses Puppeteer's existing `background` option for `browser.newPage()`
Fixes#826
---------
Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com>
Co-authored-by: Alex Rudenko <alexrudenko@chromium.org>
bringToFront() not only brings the tab to front in the browser but also
the browser window itself. This PR fixes the issue by making the call to
bringToFront() optional allowing agents to bring a tab to the user's
attention if needed but not always. To mitigate the risk of selected
page that is in the background being throttled, this PR implements
emulation of the focused page to make background tabs run as usual.
If you manually inspect a network request in the DevTools UI, the Chrome
DevTools MCP server is now able to detect it and allow you to refer to
the selected request. The approach was tested in a couple of models.
In the list of the network requests we have a short indication about
which request is selected in DevTools UI. We refer to the DevTools as
"DevTools UI" to disambiguate from the DevTools MCP server.
https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/320
Issue:
It would be very useful to have the ability to simulate offline network
conditions directly through the MCP emulate_network command, similar to
how it's possible in DevTools.
Currently, the command doesn’t support an Offline state, which limits
testing for PWA and offline-first web applications. Adding this option
would make it easier to automate and validate offline behavior through
MCP scripts or tools that rely on this API.
Solution
- Add 'Offline' option to throttlingOptions for simulating offline
network conditions
- Update emulate_network tool to handle offline mode with proper network
conditions
- Update documentation to include offline option and usage instructions
- Add test coverage for offline network emulation functionality
- Enable testing of PWA and offline-first web applications through MCP
## Summary
This PR adds WebP format support to the screenshot tool, providing
superior compression compared to JPEG while maintaining image quality.
## Problem
Currently, the Chrome DevTools MCP only supports PNG and JPEG formats
for screenshots. This leads to:
- Missing out on WebP's superior compression (25-34% better than JPEG at
equivalent quality)
- Larger file sizes than necessary for AI assistants with image size
limits
- No access to a modern format that offers both better compression and
transparency support
- Bug: `saveTemporaryFile` always saved files with `.png` extension
regardless of the specified format
## Solution
Added WebP as a supported format in the screenshot tool schema and
extended the quality parameter to work with WebP (0-100 range, same as
JPEG). Also fixed the file extension bug in `saveTemporaryFile`.
## Changes
- ✅ Added `webp` to screenshot format enum alongside `png` and `jpeg`
- ✅ Extended quality parameter description to include WebP support
- ✅ Updated `saveTemporaryFile` to properly handle WebP MIME type and
file extension
- ✅ Fixed bug where all screenshots were saved as `.png` regardless of
format
- ✅ Updated type definitions in `ToolDefinition.ts` for WebP support
- ✅ Updated documentation via `npm run docs`
## Testing
Puppeteer 24.22.3 (used by this project) has full WebP support including
quality parameter. Expected compression improvements based on WebP
benchmarks:
- **PNG (baseline):** 128 KB
- **JPEG quality 50:** 84 KB (34% reduction vs PNG)
- **WebP quality 50:** ~60 KB (53% reduction vs PNG, 29% better than
JPEG)
- **WebP quality 75:** ~90 KB (optimal quality/size balance)
All existing tests pass (131/131).
## Impact
This change is **backward compatible** - WebP is an optional format that
doesn't affect existing PNG/JPEG usage. It particularly helps with:
- AI assistants that have image size limits
- Reducing bandwidth when capturing many screenshots
- Providing transparency support with better compression than PNG
- Offering a modern, universally-supported image format (Chrome,
Firefox, Safari, Edge)
## Example Usage
```javascript
// High quality WebP
await take_screenshot({
format: 'webp',
quality: 85,
fullPage: false
})
// Optimized for size
await take_screenshot({
format: 'webp',
quality: 50, // ~29% smaller than JPEG quality 50
fullPage: true
})
```
## Checklist
- [x] Code follows conventional commits
- [x] Documentation updated with `npm run docs`
- [x] All tests passing (131/131)
- [x] Backward compatible
- [x] Bug fix included (file extension handling)
- [ ] CLA signed (will complete if needed)
Fixes #[issue-number] (if applicable)
---------
Co-authored-by: aberemia24 <aberemia@gmail.com>
Co-authored-by: Alex Rudenko <alexrudenko@chromium.org>
## Summary
This PR adds support for the `quality` parameter when taking JPEG
screenshots, allowing users to control compression levels and
significantly reduce file sizes.
## Problem
Currently, the Chrome DevTools MCP doesn't expose the `quality`
parameter that Puppeteer natively supports. This leads to:
- Large screenshot file sizes (especially problematic for AI assistants
with image size limits)
- No control over JPEG compression
- Inability to optimize screenshots for different use cases
## Solution
Added the `quality` parameter (0-100) to the screenshot tool schema and
passed it through to Puppeteer's screenshot method.
## Changes
- ✅ Added `quality` parameter to screenshot schema with proper
validation (0-100 range)
- ✅ Pass quality parameter to Puppeteer's `screenshot()` method
- ✅ Added `optimizeForSpeed` flag for improved encoding performance
- ✅ Updated documentation via `npm run docs`
## Testing
Tested locally with various quality settings:
- **PNG (baseline):** 128 KB
- **JPEG quality 100:** 245 KB
- **JPEG quality 50:** 84 KB (35% reduction)
- **JPEG quality 30:** 66 KB (49% reduction)
## Impact
This change is **backward compatible** - the quality parameter is
optional and doesn't affect existing usage. It particularly helps with:
- AI assistants that have image size limits (e.g., 8000px max dimension
errors)
- Reducing bandwidth when capturing many screenshots
- Optimizing storage for screenshot-heavy workflows
## Example Usage
```javascript
// New capability - control JPEG quality
await take_screenshot({
format: 'jpeg',
quality: 50, // New parameter!
fullPage: false
})
```
## Checklist
- [x] Code follows conventional commits
- [x] Documentation updated with `npm run docs`
- [x] Tested locally
- [x] Backward compatible
- [ ] CLA signed (will complete if needed)
Fixes #[issue-number] (if applicable)
Co-authored-by: aberemia24 <aberemia@gmail.com>
### Summary
This PR build upon #145 to also adds filtering by resource type to
`list_network_requests` (Also see: #137 and #107).
### Motivation
Agents often need specific request types (e.g., scripts, stylesheets,
images). Filtering reduces noise and improves performance.
### Changes
- **New parameter**: `resourceType` (array) to filter by resource types
- **Supported types**: all resource types supported by Puppeteer
- **Backward compatible**: when omitted, returns all requests
Filtering runs before pagination, so pagination applies to the filtered
results.
Fixes#124 and #159. People have reported that when asked for CWV
metrics, the AI will use `evaluate_script` to inject some code into the
page to gather them. But, we want to encourage it to record a trace
instead and use those values.
After some testing locally, adding CWV explicitly to the description
makes it much more reliable that the AI will reach for trace recording
when asked about CWVs.
## Summary
This PR enhances the `list_network_requests` tool with pagination
support to handle large numbers of network requests efficiently. See
[this
issue](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/136).
## Motivation
In my experience, the `list_network_requests` tool frequently hits LLM
token limits on pages with many requests, making it unusable for modern
web applications. I wanted to add pagination to allow agents to be more
flexible and manage token limits on their own.
## Changes
### Pagination Support
- Added `pageSize` parameter to limit requests per call
- Added `pageToken` parameter for navigation between pages
- Added pagination metadata in responses (nextPageToken,
previousPageToken, startIndex, endIndex, total)
### Implementation Details
- **New utility**: `src/utils/pagination.ts` - generic pagination
function
- **Enhanced McpResponse**: Added pagination options to
`setIncludeNetworkRequests()`
- **Updated network tool**: Added pagination parameters to schema
- **Offset-based pagination**: Uses numeric tokens, handles invalid
tokens gracefully
## Testing
- Comprehensive test coverage for pagination scenarios
- Tests for first page, subsequent pages, invalid tokens, and edge cases
- All existing tests continue to pass
## Backward Compatibility
- If no pagination parameters are provided, the MCP will return all
requests (same as before)
McpContext currently assumes that there is a page. Eventually we might
support closing the browser by closing the last page but right now we do
not really have responses that indicate that the browser was closed. So
this PR helps the LLM understand that it is okay to keep the last page
running (and there are platform-specific differences as to what happens
if the last page is closed).
Ref https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/87
* add script `npm run docs` that builds, generate docs and runs
formatter to auto fix formatting after doc generation
* rename generate-docs to docs:generate
* update presubmit workflow
* add docs process to contributing.md
Gustav Ernberg von Heijne