[GravityMCP] gf_list_entries: pagination, exclude, and include parameters not working

[crbdev]

Bug

When calling gf_list_entries, pagination, exclude, and include parameters are silently ignored. The API always returns the same first 10 results regardless of current_page or page_size, and total_count reflects unfiltered totals.

Steps to reproduce

1. Call gf_list_entries with form_ids: [129] — returns 10 entries with total_count: 52
2. Call again with paging: { current_page: 2, page_size: 25 } — returns the same 10 entries
3. Call with exclude: [96656, 96653, ...] — returns the same entries including excluded IDs

Root cause

In src/gravity-forms-client.js around line 314, listEntries() spreads all validated params into searchParams:

const searchParams = { ...validated };

But only search, sorting, and paging are JSON-stringified before being passed to the API. The exclude, include, form_ids, and status parameters are passed as raw arrays, which the Gravity Forms REST API silently ignores.

Expected fix

All array/object parameters (exclude, include, form_ids) should be JSON-stringified before being sent as query params, consistent with how search, sorting, and paging are handled.

Workaround

Query the wp_gf_entry and wp_gf_entry_meta tables directly via Metabase SQL.

[linear]

DEV-4162

[dndco]

Confirming this on v2.1.0 against production forms (one with ~32k entries). Independent repro, plus two refinements that might narrow the fix:

1. sorting is broken too, not just paging/exclude/include. gf_list_entries returns newest-first regardless of sorting.direction (asc/desc) or sorting.key. Asking for ascending by date_created still returns the most recent rows.

2. search filtering and total_count actually work correctly in our testing, which is the opposite of the "total_count reflects unfiltered totals" note. With search.field_filters (date_created ranges, field-value IS, and CONTAINS) the returned total_count matched expectations exactly. We summed 53 monthly date-range counts on one form and they reconciled to the unrestricted window total to the entry. So the unfiltered-total symptom may only occur when no search is supplied, or may already be fixed — worth separating it from the paging bug.

3. Net effect: with paging dead you can't retrieve more than the first ~10 row-level entries per form, so entry-level export is impossible on any sizeable form (blocked us on a 27,774-entry form). The usable workaround when you only need aggregates is repeated filtered total_count queries via search, since that path is accurate — just chatty.

One note on the fix: the array-stringify root cause looks right for exclude/include, but form_ids filtering worked for us while paging did not, even though both are non-search params. That hints paging/sorting may be failing for a separate reason (param naming / how they're appended to the GF REST query) rather than the same JSON-stringify gap. Possibly two bugs, not one.