list_contacts

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

With no annotations provided, the description carries the full behavioral burden. It does a good job disclosing the key behavior: returning all contacts with a warning about potentially thousands of results. However, it doesn't describe the return format or pagination, which would be useful for a 'list all' operation that could return large payloads.

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 two sentences with zero waste. The primary action is stated first, followed by a clear warning and the alternative tool specification. Every word earns its place, making it highly efficient and structured for an agent to parse quickly.

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, single-parameter tool with no output schema, the description is quite complete. It covers the core behavior, the scale of results, and the alternative path for filtered queries. It could elaborate on return values or error cases, but these are minor gaps given the tool's simplicity.

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 100%, so the schema documents the only parameter (addressbook_url). The description doesn't add parameter-specific syntax or format details beyond what the schema provides, but the baseline of 3 is appropriate since the schema does the heavy lifting for parameter documentation.

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 clearly states the exact purpose: 'List ALL contacts from an address book without filtering.' The verb 'list,' the resource 'contacts,' and the scope 'ALL' are explicit, and it distinguishes itself from the sibling addressbook_query by warning users to use that tool instead when searching. This differentiates it effectively from siblings.

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 explicitly names the alternative tool (addressbook_query), the condition for the alternative (searching by name, email, or organization), and the rationale (saving tokens). This directly tells the agent when to use this tool versus when to use a sibling, with the unfiltered 'list all' case clearly implied as the intended use case.

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