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

Annotations already declare read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description contributes real behavioral context beyond that: results are ranked rather than exhaustive, and there is no cursor/offset pagination — meaning limit is a hard cap and the agent cannot page deeper. It does not say how ranking is determined or what a contact record contains.

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?

Two short sentences, both front-loaded with the distinguishing facts (ranked, not exhaustive, no pagination). Nothing is padded and no sentence is redundant with the name or title.

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 simple two-parameter read tool with full safety annotations, this is roughly adequate: it tells the agent what the set is and that it can't be paged. Missing are the default limit and what a contact object looks like (no output schema exists), so an agent still can't predict the response shape.

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 50%: account_id is well documented in-schema, but limit has no description at all. The "no cursor/offset pagination" line does add meaning for limit by implying it caps a ranked, non-paged result set — useful, but it never states a default or that extra results are unreachable. Baseline 3 for a partially documented 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?

States a specific verb+resource (list ranked Messenger contacts) and immediately bounds it against the wrong mental model ("not an exhaustive address book"). It does not distinguish itself from near siblings like facebook_list_friends or messaging_list_chats, which is the only thing keeping it from a 5.

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 "not an exhaustive address book" line implicitly tells the agent this is for ranked/recent contacts rather than full roster enumeration, which hints at when to prefer it over a friends list. But no sibling is named and there is no explicit when-to-use / when-not-to-use statement.

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