datalens_entries_revisions_listList revision history of a DataLens entry to see who saved changes and when; auto-pagination supports long histories.
The revisions of an entry: who saved it and when. Auto-paginated.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max revisions to return; omitted means the configured cap (YCLI__HTTP__MAX_ITEMS). | |
| rev_ids | No | Keep only these revisions. | |
| entry_id | Yes | Entry id. |
Changes observed during successful MCP inspections.
v0.122.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description earns its keep by disclosing 'Auto-paginated', a behavioral trait absent from the annotations, and by describing the returned facts (author and timestamp).
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 short sentence-fragment, front-loaded with the resource and the returned content, with no filler. It is tight, though arguably too terse to be fully instructive.
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 3-parameter read tool with no output schema, the description at least characterizes the return shape (who saved it and when) and mentions auto-pagination. It does not explain ordering, whether limit caps pagination, or how rev_ids interacts with pagination, leaving modest gaps.
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%, so entry_id, limit and rev_ids are already documented in the schema, including the MAX_ITEMS cap and the rev_ids filter. The description adds nothing parameter-specific beyond the pagination hint, so the baseline 3 applies.
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 and resource ('revisions of an entry') and adds the payload semantics ('who saved it and when'), so the agent knows it returns authorship metadata. It does not differentiate from the sibling wiki_pages_revisions_list, which is a different resource, but within DataLens it is unambiguous.
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?
Usage is implied by the phrasing: fetch revision history for a known entry_id. There is no explicit when-to-use/when-not guidance and no pointer to a related tool such as datalens_audit_entries_updates_list, which an agent might plausibly confuse with revision history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.