Skip to main content
When you use responseType: "paging", the Xpoz MCP server creates a server-side cached table and returns results 100 items per page. This enables efficient iteration through large datasets without re-executing the underlying query.

How It Works

First Call

Set responseType to "paging" on your initial request. The response includes pagination metadata alongside the first page of results. Example — search Twitter posts:
Response metadata:

Fetching Additional Pages

Pass the tableName from the first response along with the desired pageNumber:
When fetching subsequent pages, you only need tableName and pageNumber. The original query parameters are not required — the cached table already contains the full result set.

Iterating Through All Pages

A typical pattern for retrieving all results:
Example conversation flow:

Bulk Page Fetching

Some tools support fetching multiple pages at once using the pageNumberEnd parameter:
This returns pages 1 through 5 in a single response, reducing the number of round trips.

Page Size

All paginated tools use a fixed page size of 100 items per page. User connection tools (getTwitterUserConnections, getInstagramUserConnections) use 1,000 users per page with default fields.

Table Lifecycle

Cached pagination tables are temporary and managed automatically:
  • Tables are created when the first paging request is made
  • The server handles cleanup automatically
  • If a table expires or is not found, re-issue the original query with responseType: "paging" to create a new one
Do not store tableName values for long-term use. They are temporary identifiers tied to a specific query execution. Always be prepared to re-query if a table is no longer available.
  • Response Modes — Choosing between fast, paging, and CSV
  • Field Selection — Reduce page payload size by selecting specific fields
  • Operations — Long-running operations that produce paginated results