Retrieve workbook entries with bounded pagination and a completeness marker to verify all objects are fetched. Specify a workbook ID to list compact DataLens workbook objects.
List compact workbook objects with bounded full pagination and an explicit completeness marker.
| Name | Required | Description | Default |
|---|---|---|---|
| max_pages | No | ||
| page_size | No | ||
| workbook_id | Yes |
Changes observed during successful MCP inspections.
v1.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, yet the description contributes real context: pagination is bounded and results carry an explicit completeness marker. It stops short of naming the marker or explaining what happens when the page bound is hit.
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?
A single front-loaded sentence with no padding, and the key traits (compactness, bounded pagination, completeness marker) appear immediately. The jargon ('bounded full pagination') is slightly dense but earns its space.
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?
With no output schema and no annotation detail about return shape, the description carries the burden in that area. It hints at return content (compact objects plus a completeness marker) but leaves the definition of a 'workbook entry', its relation to dl_workbooks_list, and the pagination defaults unexplained.
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% across three parameters, so the description must compensate. It partly does by tying the tool to pagination ('bounded') and mentioning a completeness signal, but says nothing about max_pages vs page_size interaction, their defaults (100), or the 1000 cap that govern the call.
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?
States a specific verb ('List') and resource ('compact workbook objects'), and adds a scoping qualifier ('compact') that tells the agent these are trimmed representations. It does not, however, distinguish itself from the closely-named sibling dl_workbooks_list or clarify whether entries live inside a given workbook, so an agent still has to infer the boundary.
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?
There is no when-to-use guidance, no stated prerequisite beyond the required workbook_id, and no mention of alternatives such as dl_object_get or dl_workbooks_list. The agent must guess which of the ~24 siblings is appropriate for retrieving workbook contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.