feat: Add pagination and request type filtering to list_network_requests #107
Conversation
OrKoN
left a comment
OrKoN
left a comment
There was a problem hiding this comment.
First of all, thank you for the PR! I have left a few comments but I also have a general suggestion: let's split the PR into two 1) for the pagination 2) for the filtering by request type.
| return; | ||
| } | ||
|
|
||
| const sanitizedOptions: NetworkRequestsListingOptions = {}; |
There was a problem hiding this comment.
We do not need to sanitize the values as we can rely on the types and JSON schema.
Could we replace this with the following?
this.#networkRequestsPaginationOptions = options;
| export type NetworkRequestsOptions = { | ||
| pageSize?: number; | ||
| pageToken?: string | null; | ||
| requestType?: FilterableResourceType | FilterableResourceType[] | null; |
There was a problem hiding this comment.
It appears that FilterableResourceType[] is not used.
| }); | ||
| } | ||
|
|
||
| export function paginateNetworkRequests( |
There was a problem hiding this comment.
let's make paginate function generic to support any list of objects.
| options?: NetworkRequestsListingOptions, | ||
| ): NetworkRequestsListingResult { | ||
| const sanitizedOptions = options ?? {}; | ||
| const filteredRequests = filterNetworkRequests( |
There was a problem hiding this comment.
let's filter before the paginate function.
| ); | ||
| } | ||
|
|
||
| function validatePageSize(pageSize: number | undefined, total: number): number { |
There was a problem hiding this comment.
Would not the JSON schema already validate the page size? If not, can we update the JSON schema.
| http://example.com GET [pending]`, | ||
| ); | ||
| const text = result[0].text as string; | ||
| assert.ok(text.includes(`## Network requests`)); |
There was a problem hiding this comment.
Let's revert to the previous assertion style to ensure relative order and verify full structure.
Sounds good! Closing this PR, I'll work through the comment and reopen the pagination PR. Once we get this merged I'll rebase the filtering and open another one. |
### 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.
3 participants
Summary
This PR enhances the
list_network_requeststool with two major features:Motivation
Playing around with this MCP, I often found that calls to
list_network_requestswould frequently cause the LLM (in my case - Claude Code) hit token limits, resulting in errors like:This made the tool unusable for pages with many network requests, which is common in modern web applications. The new pagination and filtering capabilities solve this by allowing users to:
Changes
Pagination Support
pageSizeparameter (max 100, defaults to 20) to control the number of requests returnedpageTokenparameter for pagination navigationMcpResponse.tsandnetworkUtils.tsRequest Type Filtering
requestTypeparameter to filter requests by resource typeImplementation Details
networkUtils.tswith comprehensive utility functions for filtering and paginationMcpResponse.tsto handle the new parameters and pass them to the pagination logicToolDefinition.tsto support the new parameter structureDocumentation
Testing
Backward Compatibility
list_network_requestswithout parameters continue to work as before