Skip to content

MCP: unify pagination model between search_conversations and list_* tools #20

Description

@detour1999

Follow-up to PR #10.

Two pagination models coexist on the MCP surface after PR #10:

`search_conversations` — offset-based:
```json
{ "count": 20, "offset": 0, "limit": 20, "results": [...], "has_more": true, "next_offset": 20 }
```
Agent paginates by calling again with `offset: 20`.

`list_sessions` / `list_projects` — "raise the limit" model, no offset:
```json
{ "count": 20, "sessions": [...], "has_more": true, "hint": "More sessions exist. Raise limit (max 100)..." }
```
Agent paginates by raising `limit`, capped at 100. No way to page past 100.

Problem

  • Two mental models for the same problem.
  • `list_sessions` / `list_projects` cannot enumerate past the top 100 at all today. For an archive with 500+ projects, the tail is unreachable via MCP.

Proposal

Standardize on the offset-based model already used by `search_conversations`:

  • `list_sessions` accepts `offset` (default 0) alongside `limit`.
  • `list_projects` accepts `offset` (default 0) alongside `limit`.
  • Response shape gains `offset`, `next_offset`, and `has_more` fields uniformly.
  • The "raise the limit" hint stays but points at `offset` instead: "More sessions exist. Fetch next page with offset=N."
  • Underlying `GetSessions` / `GetProjects` may need to grow `offset` parameters.

Fallback

If we decide the current cap is fine (few users care about the top 100 tail), at minimum document it explicitly in the response — "total" field or "top 100 only" language — so agents don't assume they've seen everything.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions