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

Annotations already cover readOnly/idempotent/destructive, so the bar is lowered, yet the description still adds real context: the database is shared by every version, the lambda itself is the writer (via Database.GetConnection()), and feature mode reads a copy rather than the shared store. That shared-vs-copy distinction is a genuinely useful behavioral trait. It omits write-permission/auth friction but this is a read tool.

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?

Information-dense with no filler, but the opening sentence is a long semicolon run-on that buries mode behavior inside a single breath. A mildly restructured version would scan better for an agent.

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, the description carries the return-value burden and does so reasonably: it says what the database summary contains (on/off state, fullness, tables and views with columns and row counts) and what table mode returns. Pagination cues (offset/limit) exist in the schema. It is complete enough to invoke confidently, with only minor gaps around large-result behavior.

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 coverage is 100%, so the baseline is 3 and the schema already documents every parameter including defaults. The description reinforces table/feature/limit semantics but adds little beyond the schema, and its 'newest first' default for ordered pages sits awkwardly against the schema's 'order the rows were written in' default.

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 names the concrete resource (the lambda's database) and enumerates its modes: table listings, a page of a table's rows, feature copies. This is unmistakably more than a restatement of the name. It stops short of a 5 because it never positions itself against siblings like read_lambda or read_logs.

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?

'Use it to see that migrations were applied and records were written' gives a concrete motivating scenario. There is no explicit when-not guidance or named alternative, so it does not reach the top band.

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