Update DataLens dashboard

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

With annotations already declaring readOnlyHint=false and idempotentHint=true, the description still adds real value: it discloses that there is no revision check on save, so a write silently clobbers anything saved since the read (a lost-update hazard). That is a genuine behavioral trait beyond the annotation set, though it does not cover the lock_token's role or failure behavior.

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?

Two tight sentences: the first front-loads the workflow, the second front-loads the concurrency hazard. No filler, no restating of the title, and the most decision-relevant fact (overwrite on save) is not buried.

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 nested-object mutation tool with no output schema but full schema coverage and a full annotation set, the description supplies the operational model and the destructive-ish overwrite semantics. Only lock_token behavior is left entirely to the schema, which is acceptable given 100% coverage.

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 the baseline is 3, but the description adds meaning beyond the schema: `entry` must be sent back as a complete object rather than a partial patch, and `data` is the field to mutate. That clarifies the whole-object contract that the nested DashboardUpdate schema alone does not spell out.

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?

It states a specific verb+resource (save a dashboard) and immediately defines the operation as a whole-object write ("read it, change data, send it back whole"), which separates it from the sibling datalens_dashboards_get/create/delete. It does not name those siblings explicitly, so routing still relies on the name, but the mechanism 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?

The prescription "read it, change ``data``, send it back whole" tells the agent the required sequence, implicitly pointing at datalens_dashboards_get as the prerequisite step. There is no explicit when-not-to-use or named alternative, so it stops short of a 5.

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