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

readOnlyHint=true already declares the safety profile, so the description's burden is lower. It still earns credit for disclosing pagination behavior that annotations do not cover: results come with vendor pagination metadata and represent a single page, which materially changes how an agent should call it. It stops short of noting rate limits, auth, or default page size, keeping it off a 5.

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 tight sentences with no filler, and the pagination caveat lands early enough to shape the call. The opening fragment is slightly clipped but not wasteful. Every sentence contributes.

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 14-parameter list tool with no output schema, the description covers the resource and the pagination contract but leaves the entire filter surface and the returned record shape unaddressed. An agent knows what it gets and that it is one page, but not how to narrow results or what fields come back.

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 79%, so the schema carries most parameter meaning and baseline 3 applies. The description adds nothing about the 14 filters — notably _q, status, and full_address, which have no schema description at all and are left entirely unexplained. It does not compensate for the residual coverage gap.

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 names the resource and enumerates what each record carries (status, dates, unit and rent details), which is more than a restatement of the title. But it opens with a bare noun phrase and never supplies a verb, and it does nothing to separate this from the very similar sibling arthur_list_tenants or arthur_get_tenancy. An agent can infer it lists tenancies, but must reason about the tenancy-vs-tenant distinction unaided.

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 closing clause 'this is one page, not the whole portfolio' gives real guidance on how to consume results and implies you must page through rather than expect a full dump. However, there is no statement of when to choose this over arthur_get_tenancy (single record) or arthur_list_tenants, and no prerequisites or filter-selection guidance. Usage is implied rather than stated.

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