## 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
Coquinate