fgis_read_document_table

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Even with annotations declaring readOnlyHint and openWorldHint, the description adds substantial behavioral detail: merged cells are not expanded, each row paginates physical source cells, long previews are explicitly truncated, and the tool returns surrounding text without inferred applicability. This goes well beyond the annotation safety profile and clarifies exactly what the call will and won't return.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, each carrying distinct value: what it reads, how to identify the table, how pagination works, and how to handle truncation. No filler or repetition. The most important operational directive ('Get table_index from outline') appears early.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 8 parameters, no output schema, and only partial parameter documentation in the description. It gives enough context to use table_index and cell pagination, but not enough to know how to obtain or set document_guid and expected_sha256, or what the response structure looks like. For a read-only table reader with a companion workflow, this is adequate but not fully self-contained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does explain table_index ('Get table_index from outline') and the cell_offset/cell_limit pagination pattern, but it omits meaning for limit, row_offset, source, document_guid, and expected_sha256. An agent would not know what document_guid refers to or how source is selected, leaving most parameters underspecified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb-resource pair, 'Read source table rows/cells online', and scopes it with details like preserving header flags, rowspan and colspan. It implicitly distinguishes itself from fgis_read_document (full document text) and fgis_document_outline (table index discovery), and even notes what it does not do (no inferred price or coefficient applicability). An agent can tell this is the table-reading companion to the outline tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear prerequisite: 'Get table_index from outline.' It also explicitly routes truncated cells to read_document. However, it does not enumerate when to prefer this tool over fgis_read_document or fgis_read_dataset_document, and the 'no inferred price or coefficient applicability' is more of a boundary than a usage guideline. Still, the workflow guidance is concrete and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.