search_messages: 'chatIDs' filter caps results to 1 message per chat (silent truncation)

[braklo]

Summary

When search_messages is called with the chatIDs parameter set, the response is silently capped to 1 message per chat even though many more match the date/account filters. Removing chatIDs and paginating by accountIDs/date returns the full set.

Reproduction

WhatsApp account, single chat with ~16 messages on 2024-10-30.

Buggy call (chatIDs filter, returns 1):

{
  "tool": "search_messages",
  "args": {
    "chatIDs": ["!i3n2kC7NpNu54zasP6WImqN31eI:ba_…local-whatsapp.localhost"],
    "dateAfter": "2024-10-01T00:00:00Z",
    "dateBefore": "2024-12-01T00:00:00Z",
    "limit": 20,
    "includeMuted": true,
    "excludeLowPriority": false
  }
}

Response: Found 1 message across 1 chat (complete) — only the most recent message returned, response is marked complete.

Same is true with query: "a" (any keyword) and limit 20: still 1 message returned, marked complete.

Working call (no chatIDs, paginated):

{
  "tool": "search_messages",
  "args": {
    "accountIDs": ["local-whatsapp_…"],
    "dateAfter": "2024-10-01T00:00:00Z",
    "dateBefore": "2024-12-01T00:00:00Z",
    "limit": 20
  }
}

Response: Found 20+ messages across 5 chats (showing 20) — including 16 messages from the chat above, and a working cursor for older pages.

Expected behavior

search_messages with chatIDs should return up to limit matching messages per page (or in total) across the supplied chats, with a working pagination cursor when more exist — not silently cap to 1 message per chat and report complete.

Impact

• Hard to detect: response says complete, no warning that results were filtered down.
• Forces clients to drop chatIDs and post-filter by chat ID after pagination, multiplying API calls when the user only wants a subset of chats.
• list_messages with cursor pagination on the same chat returns items: [] hasMore: true repeatedly, so it isn't a usable workaround either.

Environment

• Beeper Desktop (Linux, openSUSE Tumbleweed)
• MCP transport: HTTP at localhost:23373/v0/mcp
• REST /v1/chats/<id>/messages?limit=100&before=<sortKey> exhibits the same single-message cap, so the issue likely lives below the MCP layer.

Notes / workaround

Skip chatIDs, paginate by accountIDs + date range, and filter chat IDs client-side from the response. The cursor/direction pagination works correctly in that mode.