other_contacts_list

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

No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation and 'Paginated like contacts_list' discloses pagination behavior, but the agent is left to check a sibling for how pagination actually works, and nothing is said about auth/account scope, rate limits, or result ordering.

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 resource definition before the value proposition and pagination note. The CRM framing is mild marketing padding but takes only one clause, so little 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 no annotations, no output schema, and zero parameter documentation, the description must cover more than it does. It explains the resource concept well but leaves the required account argument, return shape, and pagination mechanics unspecified.

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 three parameters. The description mentions pagination only by reference to contacts_list, adding no meaning to page_size or page_token, and says nothing about the required 'account' parameter (whose account, what format). With no schema documentation to lean on, this is a clear 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?

States a specific verb ('List') and a precisely defined resource: people you've corresponded with but never saved to Google Contacts. The definition itself separates it from contacts_list (saved contacts), so an agent can distinguish the two without opening either 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 line about being 'high-value for a CRM' and surfacing ties 'missing from the address book' implies the use case, but there is no explicit when-to-use versus contacts_list or contacts_search, and no exclusions. Guidance is inferable rather than stated.

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