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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the single-vs-list duality, but that is also spelled out in the id parameter schema ('omit to query many'), so incremental behavioral value is modest; pagination, clamping, and return shape are left to the schema or unstated.

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 well-formed sentence that front-loads the resource and packs both operating modes into one dash-separated clause. No wasted words; slightly terse but efficiently structured.

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 6 parameters, a nested query object, no output schema, and 83% schema coverage, the description covers the two main modes adequately. But it is silent on the fields parameter (undocumented in schema) and does not hint at the MongoDB-style query semantics that the schema only partially explains.

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 high (83%), so the schema already documents id, skip, sort, limit, and query. The description reinforces the id/query distinction but adds no format or syntax detail beyond the schema, fitting the baseline of 3 when structured data carries the load.

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 (Find) and resource (LimAd records), and clarifies the two operating modes: single-record fetch via id versus filtered list via query. It does not explicitly distinguish itself from the many sibling query_lim* tools, but the resource name and mode split make its purpose 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?

Provides mode-selection guidance ('pass id for one record, or query for a filtered list'), which is a form of usage instruction. However, it offers no when-to-use/when-not context relative to the ~45 sibling query tools and no prerequisites or exclusions.

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