MCP budget: lower get_index_usage's default row limit under budget (#4198)

[erikdarlingdata]

Part of #4198.

Why

get_index_usage already had a caller-optional limit parameter (#2636), but its default value was still the pre-#2636 hardcoded cap of 200 rows. #4198 measured a default call, with no arguments, at 69,290 bytes on a busy production store (848 ms). That is more than double McpResponseBudget.DefaultBytes, 32 KB. A default call's reply was large enough for an MCP client to refuse it outright, the same failure #4198 found across the read-tool set.

What changes

• Darling (DarlingMcpObjectStatsTools.GetIndexUsage) and Lite (McpObjectStatsTools.GetIndexUsage): IndexUsageTop, the limit parameter's default, drops from 200 to 75 rows. That size comes from the measured rate, about 346 bytes per row (69,290 bytes over 200 rows). The parameter itself, its validation (McpHelpers.ValidateTop), and the truncation envelope (returned_index_count, matching_index_count, truncated, note) stay the same. [BUG] - get_index_usage MCP tool hardcodes a 200-row cap ordered unused-first, silently hiding all "Active"/"Write-only" indexes and any database whose indexes don't rank in the global top 200 #2636 already built that shape. This lane only resizes the fallback. An explicit limit still gets exactly what it asks for, up to McpHelpers.MaxTop.
• Parameter description text changes from "Default 200." to "Default 75." on both products. The tools/list byte-budget pins (DarlingMcpObjectStatsTools.txt, McpObjectStatsTools.txt) drop from 36 to 35 bytes to match, one fewer digit.
• New live test Darling.Tests/IndexUsageBudgetLiveTests.cs. It seeds 200 index rows across 10 databases on a real PostgreSQL store and checks three things. The default call stays under budget and comes back truncated. An explicit limit covering the seeded set returns every row untruncated.
• New Lite test Lite.Tests/IndexUsageBudgetTests.cs, the same three checks against Lite's shared DuckDB fixture. No rig needed.
• get_index_usage is not on A budget pin over every MCP read tool (part of #4198) #4224's McpReadToolBudgetLiveTests ExemptOffenders roster. That fixture does not seed index_object_stats, so McpReadToolBudgetLiveTests.cs itself is untouched here. This lane's own fixture covers the gap A budget pin over every MCP read tool (part of #4198) #4224 already documents for this tool.

Test plan

• Darling.Tests build: 0 Warning(s), 0 Error(s).
• Lite.Tests build: 0 Warning(s), 0 Error(s).
• New live test IndexUsageBudgetLiveTests: default call measured 25,913 bytes, down from the 69,290 bytes the field measurement found, under the 32,768-byte budget. truncated is true. An explicit limit=200 returns all 200 seeded rows, not truncated.
• New Lite test IndexUsageBudgetTests: default call measured 25,902 bytes. Same three checks, passing.
• Targeted classes green on the rig. Darling: IndexUsageBudgetLiveTests, IndexUsageTruncationTests, IndexUsageTruncationLivePostgresTests, DarlingMcpObjectStatsToolsSurfaceAndSqlTests, DarlingMcpObjectStatsToolsLivePostgresTests, DarlingIndexLockingRenamedDatabaseLivePostgresTests, McpToolsListBudgetTests, McpPayloadContractCensusTests. Lite: IndexUsageBudgetTests, IndexUsageTruncationTests, McpToolsListBudgetTests, CrossAppMcpToolInventoryPinTests.
• Full Lite.Tests suite after merging origin/dev: 5,340 total, 0 failed.
• Full Darling.Tests suite after merging origin/dev: 13,849 total, 3 failed, 47 skipped, 1 not run. All 3 failures passed cleanly when re-run alone right after, on a freshly recreated database: CaptureDownChunkOrderTests...AgainstDevPostgres, ServerListAndSummaryPlanShapeTests...AgainstDevPostgres, TrendPayloadBudgetLiveTests.EveryDefaultAnswer.... These are suite-order, chunk-count flakes from a 13,800-test run sharing one database, not from this change. TrendPayloadBudgetLiveTests is the exact flake the MCP read tools have no default response-size budget: at default arguments 12 tools return >50 KB and 3 return >100 KB for one server, more than an agent client's per-result cap #4198 common brief already names as failing locally on unrelated branches tonight. None of the three touch index_object_stats, DarlingObjectStatsReader, or either object-stats tools file.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• get_index_usage's default answer now fits the response budget ([MCP budget: lower get_index_usage's default row limit under budget (#4198) #4260]) - A default call, with no limit argument, always returned up to 200 rows regardless of width. That measured over 69 KB on a busy server, large enough for an MCP client to refuse it outright. The default limit is now 75 on both Darling and Lite. An explicit limit still returns exactly what was asked for.
  REF:
  [MCP budget: lower get_index_usage's default row limit under budget (#4198) #4260]: MCP budget: lower get_index_usage's default row limit under budget (#4198) #4260

Generated with Claude Code

https://claude.ai/code/session_01TszxYhJJbTEh4LrZ56NYo3