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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds genuine behavioral context beyond that: saving an existing entry mutates its audience or label rather than erroring. However, it says nothing about the non-idempotent nature, retry behavior via idempotency_key, or which audience changes take effect on in-flight conversations.

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 purpose is front-loaded in the first sentence, and the closing sentence carries the non-obvious upsert rule. The middle sentence is somewhat verbose and marketing-flavored ("run on their own under the company policy instead of waiting as an unknown audience") but does explain the mechanism, so it earns most of its space.

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 7-parameter mutation with no output schema and only 29% schema coverage, the description is adequate but not complete: it never explains company/environment scoping, when to supply idempotency_key, or what happens on invalid values. The core semantic (upsert with audience/label mutation) is present, which is the most important piece.

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 only 29%, so the description carries real weight. It usefully maps the three `kind` values (email, email_domain, slack_channel) and clarifies that `audience` means partner vs. own team, plus that `label` is an editable attribute. But `company` and `environment` — both required with enums/formats — get no explanation at all, and precedence between `label` and `audience` on an existing entry is ambiguous.

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 names a specific verb and resource: naming an email address, email domain, or Slack channel as a partner or internal team. It also discloses the upsert behavior ("Saving an existing entry changes its audience or label"), which distinguishes it from the pure-delete sibling summer_partners_contacts_remove. It does not explicitly call out that sibling, so it stops short of full differentiation.

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 sentence about Summer knowing "who vendor mail and Slack replies reach" implies the usage context (routing/autonomy enrollment), which is useful but indirect. There is no explicit statement of when to use this versus summer_partners_contacts_remove, nor any prerequisites such as requiring a specific company ID, environment, or permission level. Usage is inferable but not guided.

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