fetch: server-issued @odata.nextLink/$skiptoken on /chats/{chat-id}/messages is rejected by its own endpoint (Unknown error)

[chad-ss]

Prepared by Claude.

Summary

On the hosted Work IQ MCP endpoint (https://workiq.svc.cloud.microsoft/mcp), fetch on /chats/{chat-id}/messages issues an @odata.nextLink continuation that its own endpoint then rejects. Every attempt to follow the server-issued $skiptoken fails with "Unknown error", making chat history beyond the first page unreachable via the documented pagination mechanism. The response schema (via get_schema) still advertises @odata.nextLink in the collection response.

Environment

• Hosted Work IQ MCP prod endpoint, tested 2026-07-08 and 2026-07-09
• Reproduced independently by two users in the same tenant, on multiple real chats (meeting chats and 1:1s)
• Persistent, not transient — the base call succeeds between continuation attempts

Repro

1. fetch {"entityUrls":["/chats/{chat-id}/messages?$top=50"]} against any chat with more than ~10 messages.
   • Returns a small page (observed 10–20 messages regardless of $top), newest-first by lastModifiedDateTime, plus an @odata.nextLink containing a $skiptoken.
2. fetch the returned @odata.nextLink — verbatim, exactly as issued.
   • Result: "Unknown error".
3. Variants tried (~10): relative path vs absolute URL, uppercase/lowercase percent-encoding, decoded token, double-encoded token. All fail identically.

Also rejected on this path

• $filter on createdDateTime (rejected)
• $orderby=createdDateTime in either direction (rejected)
• messages/delta via call_function (rejected)

The only working paging lever we found is $orderby=lastModifiedDateTime desc combined with $filter=lastModifiedDateTime gt <T1> and lastModifiedDateTime lt <T2> — walking lt backward window by window. That workaround is complete (since lastModifiedDateTime >= createdDateTime) but costs one call per ~10 messages and returns items out of created order (edits/reactions bump lastModifiedDateTime).

Expected

Following the exact continuation URL the server issued should return the next page, per the schema's advertised @odata.nextLink contract.

Impact

Any agent that needs more than the first page of a Teams chat (meeting recaps, thread summarization, "what did I miss") either dead-ends or burns many failed calls discovering the wall. Before we documented the workaround internally, a scheduled recap agent spent nine failed tool calls on continuation attempts and produced no output.

Notes

• Observed on chat messages (/chats/{chat-id}/messages); channel messages not tested for this behavior.