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

Annotations only convey non-read-only and non-idempotent. The description adds critical beyond-annotation behavior: the double opt-in flow (nothing starts until the confirmation link is clicked), the morning delivery cadence, and free one-click unsubscribe. These are exactly the behavioral traits an agent must know before invoking a subscription tool and are not derivable from the hints.

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?

Four short sentences, front-loaded with the core action first, then the opt-in mechanism, unsubscribe, and invocation condition. Every sentence earns its place with no redundancy or padding; the most safety-critical guidance (consent) is positioned at the end as a guardrail.

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?

Despite six parameters and no output schema, the description covers the essential agent-facing aspects: the action, the delivery cadence, the opt-in gate, the unsubscribe path, and when to call it. The subscription flow is fully disclosed, and with no output schema and clear sibling differentiation, nothing an agent needs to invoke this correctly is missing.

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 67%, and the schema already documents email, titles, locations, and remote_ok. The description adds mild reinforcement — 'for the given titles and locations' clarifies those act as match filters, and 'email the person' confirms email is the recipient — but adds no new meaning for the two uncovered parameters exclude_titles and exclude_locations, which have no schema descriptions either. Adequate but not strongly compensating for the coverage gap.

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 action ('email the person new job matches every morning') on a clear resource (daily job subscriptions), with a stated mechanism (double opt-in) and scope (given titles and locations). It clearly distinguishes from siblings get_job, search_jobs, and list_coverage, which are all read-oriented; this is the only write/subscription action among them.

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 final sentence gives explicit invocation conditions: 'Only call this when the person explicitly asked for daily emails and gave their own address.' This tells the agent when to trigger the tool and implicitly when not to (unsolicited, or using someone else's address), which is exactly the consent boundary this subscription action needs to respect.

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