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

With readOnlyHint=true already declaring the safety profile, the description adds genuinely useful behavior: pages hold up to 100 items and next_cursor must be passed back as cursor, plus the auth requirement (Cotlet API key with access to this app). It does not cover rate limits or error behavior, but it exceeds what the annotations provide.

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?

The first two sentences are near-duplicates of each other ('Properties or units in your account with address, rent, showing status and assigned lockbox' restated as 'Lists the properties and units in your Rently account, with address, rent, showing status and the assigned lockbox'). The pagination and auth details are useful, but the opening redundancy costs space.

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 read-only list tool with full schema coverage and no output schema, the description supplies the returned fields, pagination mechanics, filtering options, and auth needs. Only the absence of any routing guidance against sibling tools keeps it short of complete.

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. The description mostly restates schema content (market filtering, search semantics identical to the schema text). Its one added value is clarifying that the returned next_cursor maps to the cursor parameter, but that is marginal.

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 states a specific verb and resource (lists the properties and units in your Rently account) and enumerates the returned fields (address, rent, showing status, assigned lockbox). This clearly separates it from siblings like rently_list_leads, rently_get_property_activity, or rently_get_dashboard without needing the schema.

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?

The description tells the agent how to narrow results (filter by market, search by address fragment or CRM tag), which implies when to use the filters. However, it never states when to call this tool versus a sibling (e.g. get_property_activity for a single property) or any preconditions beyond needing the API key.

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