What changed in an address book

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

Beyond the readOnlyHint and idempotentHint annotations, the description explains the sync-token protocol, the initial-sync behavior, and the server-support caveat. It also names the underlying standard (RFC 6578), giving the agent a clear model of what the call does and what could go wrong.

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 well-ordered sentences convey the core behavior, the call sequence, and an important limitation with no filler. The most important information is front-loaded in the first clause.

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 read-only sync operation, the description covers the essential protocol, the initial vs. subsequent call, and the prerequisite capability check. The presence of an output schema means return values need not be described, and the input schema covers parameters.

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 for sync_token: leaving it out returns the current token and every card as the initial sync. This enriches the bare parameter description with the exact call pattern. It does not add much for limit or address_book, but that is acceptable given the schema already documents them.

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 identifies the operation: returning cards created, changed, or deleted since a sync token. This is specific enough to distinguish list_changes from siblings like list_contacts or search_contacts, which return current card data rather than a change set.

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 gives explicit procedural guidance: call once without a token to get the current token, then call again later with it. It also warns that not every server implements RFC 6578 and routes the agent to get_server_info for capability detection, which is valuable decision support.

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