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

Beyond the readOnlyHint annotation, the description discloses the return shape (name, primary email, full email list, next_page_token), pagination mechanics ('pass that back as page_token to fetch the next page, and stop once it's null'), and account scoping rules ('Only ONE account per call (pagination is per-account)'). This gives the agent the operational context needed to call and paginate correctly, well above what annotations alone 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 description is front-loaded with purpose and differentiator, then return values, pagination, and account handling—each sentence adds necessary detail. Despite its length, every sentence earns its place, and the structure (em-dashes, semicolons) keeps related points together without waste.

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 output schema, the description fully compensates by explaining the returned fields and pagination token. It covers account prerequisites (call list_accounts for labels), pagination stopping condition, and multi-account resolution. Combined with the readOnlyHint annotation, an agent has everything needed to invoke and paginate correctly.

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, but the description adds meaningful semantics beyond the schema: it clarifies that pagination is per-account, that page_token should be passed until next_page_token is null, and that `account` auto-resolves when only one Contacts-enabled Google account is connected. These details go beyond the schema's descriptions, justifying a 4.

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 (Browse/List) and resource (SAVED Google Contacts) with clear scope (all contacts, one account, one page at a time). It explicitly distinguishes itself from the sibling search_contacts: 'unlike search_contacts, no query is needed'—so an agent can tell them apart without opening either schema. It also uses 'SAVED' to implicitly differentiate from list_other_contacts.

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?

It provides explicit when-to-use guidance: 'this is how to see the whole address book (or find someone when a name search comes up empty/ambiguous).' It names the alternative (search_contacts) and the condition that selects it (no query needed here). It also gives precise account-handling instructions: pass `account` when multiple Contacts-enabled accounts exist, call list_accounts to learn labels, and it auto-resolves when only one is connected.

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