[MaxHaro]

What this changes

edgar_read stopped a 13F-HR holdings section at 30 rows and cut every section to 6,000 characters, so a full portfolio could not be read or reconciled to its filed total. It now takes an optional limit (default 30; 0 returns every row). 13F holdings skip the 6,000-character cap, since limit already bounds them; other sections keep it. The default output is unchanged for realistic issuer names.

limit is validated for all forms and applied only to 13F holdings. A negative or non-integer value (including True) returns an INVALID_ARGUMENTS error before any filing is fetched; integral floats like 30.0 are accepted, since the JSON schema counts them as integers. The error is a deliberate divergence from edgar_ownership (no validation) and edgar_fund (clamps), so limit=-1 doesn't quietly return nothing or everything.

Fixes #1416

Verification

• Ground truth: Contrarius Group Holdings 13F-HR 0001999371-26-017606 (period 2026-06-30), run live on 2026-10-15. Default returns Top holdings (30 of 34); limit=0 returns all 34 rows (34 of 34), matching the filing's 34 holdings ($2,170,182,768 total). The tests use a synthetic 211-row fixture.
• Regression test in tests/issues/regression/test_issue_1416_edgar_read_limit.py, docstring links edgar_read: opt-in limit so a full 13F portfolio can be read #1416; all 13 cases fail on main's reader.py
• Silence check: negative, string, fractional and boolean limit return a clear error, not a silent result
• Docs: docs/ai/mcp-tools.md, MCP_QUICKSTART.md and the server.py examples list limit
• Changelog: changelog.d/1416.added.md

Working context

Written with AI assistance (Claude Code) and reviewed by me; I'm responsible for it.

Evidence: reproduced the cap offline (a 211-row fixture returned 30 rows). limit=0 is turned into the row count because DataFrame.head(0) is empty. The new tests pass; tests/ai and the related MCP regression tests pass (534 passed). ruff check adds no findings, and the provenance and changelog checks pass. Failures in the full fast suite on Windows are pre-existing on clean main (verified).

[arhancanli]

Read the diff and checked the synthetic fixture: 211 rows give 188,845,000 in total and the first 30 give 29,565,000, as the test docstring says. The limit=0 path (head(0) is empty, so 0 becomes the row count) is handled correctly. I did not run the suite.

Three things I'd look at:

1. Top holdings (N of M) assumes the frame is sorted by value. _holding_rows is holdings_table.head(limit), so it returns the first rows in whatever order ThirteenF.holdings has. If that order is the filing's order (not descending by Value), "Top" is wrong for any limit below the row count, and a caller reconciling to the filed total from a partial read gets a misleading subset. The Contrarius check (34 rows) can't show this, since limit=0 returns everything there. A test with an unsorted frame and limit=5 would settle it.

2. shown can overstate what is returned. The header prints shown, but _holding_rows skips rows with no usable cell, so the line count can be lower than the number in the header. The new tests use clean rows, so they would not catch it. Counting len(parts) for the header is cheap.

3. limit=0 has no ceiling at all, and these sections are now exempt from the 6,000-character cap. That is intended, but a large manager's 13F can have thousands of rows, and at roughly 60 characters a row that is hundreds of KB returned into a model's context in one tool call. Maybe a high hard maximum (or a note in the tool description about it) so one edgar_read call cannot return an unbounded payload.

The input validation (bool, negative, 30.0) reads well.

[MaxHaro]

@arhancanli Thanks for the careful review, all three points were useful. (1) ThirteenF.holdings is already sorted by Value descending (there's an existing test for that), so the first N rows are the top N; I left the sorting alone and added a comment saying so. (2) You're right about the header: it now counts the rows actually listed rather than the rows requested, and there's a test with a skipped junk row. (3) limit=0 stays uncapped since the issue asks for the full portfolio, but the tool schema and docs now say it can return thousands of rows for large managers; the follow-up commit is pushed.