Fixes a bug where the output contained "this is a high level summary"
before then outputting the call frame / network format information
before then outputting the trace summary.
With this commit, we now output the summary & insights before ending
with the format information.
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
PR Description
- Fix the stop-trace guard to call context.isRunningPerformanceTrace()
so we skip page.tracing.stop() when nothing is recording, avoiding the
Puppeteer error that bubbled up
to users.
- Extend the “does nothing” test to stub tracing.stop() and assert it
stays untouched, guaranteeing the guard path is covered.
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.
Nikolay Vitkov