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 genuinely non-obvious behavior: results are paginated to one page, a `next` cursor continues the result set with filters preserved, and the call requires CONTACTS read permission. It does not describe the shape of returned records or what happens with a `limit`/`offset` versus a `next` continuation.

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?

Three short sentences, front-loaded with the action and scope, no filler. The only cost is that the terse phrasing leaves the pagination mechanism ambiguous (is `next` a request param or a response field?) — brevity at the expense of precision.

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 nine undocumented parameters, no output schema, and no annotations beyond readOnlyHint, the description should explain filtering and return behavior. It covers pagination and permissions but leaves filters, defaults, and result contents entirely unspecified, which is thin for a filter-heavy list endpoint.

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 0% across nine parameters, so the description carries the full burden and fails to explain any of them: the type enum values, email/name matching semantics (exact vs partial), orderby syntax, the lastModifiedDateTime range, or the interaction of limit/offset. It instead references a `next` token that does not appear in the schema at all, which can confuse an agent trying to page.

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 Propertyware contacts"), which is clearly distinguishable from the sibling propertyware_get_contact (single record) and the type-specific listers like propertyware_list_vendors or propertyware_list_prospects. It stops short of explicitly naming those alternatives, but the scope 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?

Provides real usage guidance for pagination: one page per call, then follow the `next` token, which preserves filters. It also states the CONTACTS read permission prerequisite. However, it gives no guidance on when to use this versus propertyware_get_contact or the other list tools, and doesn't say the filters can be combined.

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