Give a spreadsheet agent a response budget, not just a cell-range argument

When exposing Univer CLI sheet reads to an agent, a cell-range argument is only part of the interface. The agent can ask for an entire sheet, or request a few cells containing enormous strings. The useful limit is on what the tool is allowed to return. For a question like “which orders are still awaiting a delivery date?”, start with a small workbook inventory: sheet names, table boundaries and headers. Then run the row selection beside the file and return matching records with their locations. The model doesn't need every unrelated row to explain the result. The CLI's structured range output distinguishes stored values, types, formulas and display text. Choose which of those the question needs. Put row selection and hard row/byte limits in the wrapper around the read; accepting a range argument alone doesn't enforce them. A useful response includes the file version, sheet, addresses, matching-row count, returned-row count and whether more results remain. If the limit is reached, return an explicit continuation point. Silently returning the first batch makes a partial answer look complete. Also make the next request purposeful. A delivery-date question might need a second range containing status definitions, or a formula's input cells. Let the agent ask for that context rather than bundling every possible dependency into the first response. Test that interface against the actual workbook sizes and questions before making performance claims. The thing to measure is whether the bounded response contains enough evidence to answer correctly, including when the answer requires more than one read.