list-excel-table-rows

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

Annotations already include readOnlyHint=true and destructiveHint=false, and the description independently states 'Read-only', so there's no contradiction. The description adds behavioral detail beyond annotations by describing the row structure (index and values array) and recommending pagination strategy, which helps the agent anticipate response shape and context limits. It doesn't detail response format or edge cases, but given the safety profile is covered, this is adequate.

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?

The description is two concise sentences plus a tip. The core action and read-only nature are front-loaded, and the pagination tip is relevant and useful. No fluff or redundant information; every sentence earns its place.

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?

For a tool with 14 parameters and no output schema, the description is minimal but sufficient given the exhaustive schema descriptions. It covers the core purpose and gives a pagination hint, while the schema explains all parameter details. The absence of a return-format description is mitigated by the row structure hint. It's complete enough for an agent to correctly invoke the tool for typical list operations.

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 100% and all 14 parameters have detailed descriptions covering pagination, filtering, search, select, expand, etc. The tool description adds only a generic tip on using $top/$skip, which slightly supplements but does not add new semantics beyond what the schema already communicates. Baseline 3 is appropriate when schema carries the full explanatory load.

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 states the precise verb 'Lists' and resource 'all rows in a table', and adds that each row has index and values array. This clearly distinguishes it from sibling tools like list-excel-tables (which lists tables) and add/update/delete-excel-table-row (which mutate rows). The read-only note reinforces its scope.

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 explicitly notes this is read-only and provides a concrete tip on pagination using $top and $skip for large tables. While it doesn't name alternatives or state when not to use it, the purpose is unambiguous and the tip gives actionable guidance for typical usage scenarios. It could be improved by mentioning that iterative fetching is possible via @odata.nextLink, but that is present in the schema parameter descriptions.

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