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

Beyond the readOnlyHint annotation, the description explicitly states that the tool creates nothing, turns nothing on, and is safe to call as soon as the request is clear. It also discloses edge-case behavior, like still drafting with an empty trigger.from when no address exists, which gives the agent a clear mental model of side effects and limits.

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 dense but every sentence earns its place. It front-loads the core action and scope, then provides conditional guidance without tangents. Despite its length, it remains tightly organized and directly actionable.

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?

The description is complete for a draft-creating tool without an output schema. It covers scope, safety, trigger conditions, parameter overrides, address handling, and conflict resolution with the user. An agent has enough information to select and invoke the tool correctly in the described scenarios.

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?

Although schema coverage is 100%, the description adds significant parameter-level guidance: when to pass schedule/trigger overrides, how to populate trigger.from from address lookup, and what to do if no address is on record. This goes well beyond the schema's structural descriptions and directly informs correct invocation.

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: drafting a standing errand in the YouSpot chat so the user can enable it with one tap. It also distinguishes the tool's behavior from merely sending reminders by clarifying it creates nothing and turns nothing on, making its purpose unambiguous relative to sibling tools.

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 gives explicit trigger conditions with concrete examples ('tell me when...', 'every morning...', 'notify me...'). It also names alternative actions when appropriate, such as using search_graph_objects or search_connections for address lookup, or asking the user with ask_user when two people match. This is strong when-to-use guidance.

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