This PR Fixes#249
The `onRelease` functionality in the `Mutex` class was unused.
This change removes the `onRelease` callback from the `acquire`
method and the `Guard` class, simplifying the implementation.
We were setting the storage inside the first collect callback which mean
that we double subscribed to the events.
This affected Network request and Console messages
## 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.
This CL adds the descriptions of the call frame format and the network
request format to the summary so that as the AI sees these responses it
can fully parse them.
This includes a better fix for the circular dependency problem and makes
the changes in the MCP server based on the upstream DevTools
implementation changes.
I wanna test more NodeJS versions to see that this does not cause other
issues.
Deno test command:
```sh
npx @modelcontextprotocol/inspector deno --allow-env --allow-read ./build/src/index.js
```
Bun test command:
```sh
npx @modelcontextprotocol/inspector bun ./build/src/index.js
```
This commit updates DevTools to the latest release. This most
importantly includes a fix for #124 and other reported issues where
Insights that were actually errors were not handled correctly. They are
now formatted correctly on the DevTools side and now will not break
performance traces in the MCP server.
## 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
This PR tidies up the code around performance parsing and what we
respond with from our tools. It introduces the ability to have no
Insights from a trace (relatively rare, but can happen), and also adds
more information to the output in the event that something went wrong.
Previously we just logged errors, but if we respond with them here that
will also help users report issues and increase the chances that we can
debug them.
Nikolay Vitkov