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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results are tenant-scoped and cover both proposal and approved records, but says nothing about result ordering, pagination, or whether the list is bounded — relevant for a listing tool with no output schema.

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 compact sentences with the resource and the filter options front-loaded; nothing is wasted. The only weakness is that the status parenthetical repeats the schema less completely than the schema itself does.

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 simple two-optional-parameter read-only listing tool with full schema coverage and no output schema, the description covers what the tool returns at a conceptual level and how to narrow it. Missing only minor details such as default ordering or result limits.

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 both parameters are already fully documented with types, formats and the enum, which sets the baseline at 3. The description restates the statuses but omits "superseded" from its parenthetical list, adding no meaning and potentially causing an agent to skip a valid filter value.

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 ("List manual correction bookings") and scopes it to the tenant, which clearly separates it from siblings like propose-manual-adjustment, update-manual-adjustment and withdraw-manual-adjustment. The parenthetical "(proposals and approved)" muddies the resource description slightly, since the schema also allows rejected and superseded records.

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 tool name and the mention of filtering by status and/or period, so an agent can infer when to reach for it. However, there is no explicit when-to-use statement, no exclusion criteria, and no routing to related siblings such as update-manual-adjustment when a listed item needs action.

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