Increase log retrieval limit and improve pagination for Logs API used by LLM/Agentic Workflows

Problem Statement

The current Logs API enforces a hard max limit of 100 rows per API call. This constraint surfaces across both the MCP integration and the CLI, since both hit the same underlying API. For workflows that require pulling comprehensive log context (particularly automated/agentic debugging pipelines), 100 rows are frequently insufficient to capture the full picture needed to diagnose an issue.

• LLM-driven and agentic workflows that consume the API struggle with pagination. Models don't reliably know when they need to make additional paginated calls, leading to silent context gaps where the relevant signal exists in logs but isn't retrieved. The "continue search" pagination pattern requires multiple round-trips, which automated consumers handle inconsistently.

Solution Brainstorm

• Consider a query-based model for MCP/agentic consumers longer term, where log retrieval is constrained by time/compute budgets rather than hard row caps.

• Increase the default row limit per API call.

Product Area

Other

Start by tracing the shared Logs API path used by the MCP integration and CLI, then locate the hard 100-row limit and current pagination behavior. The issue needs a decided retrieval model and acceptance criteria; done should mean the API and its consumers reliably retrieve the intended log context without silent pagination gaps.