Problem
MCP ReadOffset currently clamps only the lower bound with Math.Max(0, ...). Tools such as references, callers, callees, and symbols can pass very large offsets into SQL queries or follow-up count paths.
Large offsets can force SQLite to scan and discard many rows, and some graph paths also compute totals when offset > 0, making a single request far more expensive than the advertised limit suggests.
Suggested fix
Introduce a documented maximum offset for MCP pagination, reject or clamp values above it, and include the cap in the server limits metadata.
Evidence
src/CodeIndex/Mcp/McpToolHandlers.cs: ReadOffsetsrc/CodeIndex/Database/DbReader.References.cs: queries use LIMIT @limit OFFSET @offset.
Problem
MCP
ReadOffsetcurrently clamps only the lower bound withMath.Max(0, ...). Tools such asreferences,callers,callees, andsymbolscan pass very large offsets into SQL queries or follow-up count paths.Large offsets can force SQLite to scan and discard many rows, and some graph paths also compute totals when
offset > 0, making a single request far more expensive than the advertisedlimitsuggests.Suggested fix
Introduce a documented maximum offset for MCP pagination, reject or clamp values above it, and include the cap in the server limits metadata.
Evidence
src/CodeIndex/Mcp/McpToolHandlers.cs:ReadOffsetsrc/CodeIndex/Database/DbReader.References.cs: queries useLIMIT @limit OFFSET @offset.