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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the description's leading "Read only" is largely redundant. What it does add is a field-level inventory of what the read surfaces (sender readiness, confirmed counts, month usage used/left, per-segment counts, firstHeard categories), which is genuinely useful since there is no output schema. It says nothing about permissions required, how fresh the counts are, or whether the numbers are cached, so behavior beyond safety is only partly covered.

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 content is mostly necessary, but it is delivered as one long comma-chained sentence that mixes the safety flag, the field inventory, and the usage instruction. The routing instruction ("Start here before drafting or scheduling") sits at the very end where it is easiest to miss, and phrasing like "a rough count" and "and so on" is loose for a definition an agent must act on.

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 and no parameters, the description carries the full burden of describing the return value, and it does so with a specific field inventory covering configuration, sender, audience counts, usage quota, segments, and firstHeard. Gaps remain on nesting/format of the segment list and the exact unit or scope of the monthly counter, but an agent can decide and call correctly from this.

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?

Zero input parameters, so the baseline of 4 applies; the description correctly spends no space on arguments and instead describes the result shape.

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 the resource (workspace email state) and enumerates concretely what the tool reports: whether email is on, whether sending is open, the sender line and readiness, confirmed-people counts, monthly usage, saved segments with id/name/counts, and the firstHeard breakdown. It is unambiguously a read of workspace-level email configuration and aggregate audience data, not a draft/schedule/automation tool. It stops short of a single crisp verb-resource sentence, burying the purpose inside a long enumeration, so it lands at 4 rather than 5.

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?

"Start here before drafting or scheduling an email" gives explicit ordering guidance relative to the drafting/scheduling siblings (create_draft, draft_campaign, postfjord_ai_compose). It does not name an alternative to use instead for the segment or signup-form data it summarizes, and offers no when-not-to-use condition, so it is clear context without full alternative routing.

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