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

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds the meaningful behavioral fact that supplying id collapses the call to a single record while omitting it produces a filtered list. It says nothing about pagination, default sort order, or the cost of unbounded queries, which are the traits an agent would still want to know.

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 sentence with no filler, and the two call modes are front-loaded ahead of any qualifying detail. It could be marginally clearer if the two branches were separated, but nothing is wasted.

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 readOnlyHint supplied, six optional parameters, a nested query object, and no output schema, the definition covers the essential shape of the call: identity lookup versus filtered query. What remains uncovered is modest but real - the undocumented 'fields' projection argument, pagination behavior when limit is omitted, and how the list result is shaped.

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 83%, so most parameters are already documented in structured fields (id, skip, sort, limit, query all carry descriptions), and the baseline for this dimension is 3. The description's only semantic addition is the id-versus-query mode relationship; it does not touch the entirely undocumented 'fields' parameter, which is the one real gap left in the schema.

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 gives a specific verb ('Find') and a specific resource ('LimWebhookLog records'), and it splits the tool's two operating modes: single-record fetch by id versus filtered list via query. It does not distinguish this tool from its obvious sibling query_limwebhook, so an agent must infer that this one targets log entries rather than webhook definitions.

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 rather than stated: the agent is told to pass 'id for one record, or query for a filtered list', which is enough to choose an operating mode. There is no explicit guidance on when to prefer this tool over query_limwebhook, nor on prerequisites, exclusions, or what happens when both id and query are supplied.

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