pillar_dca_invite

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

No annotations exist, so the description carries the full behavioral burden. It does disclose the reciprocal commitment (both parties must boost weekly to preserve the streak), which is real context an agent would not otherwise have. However, it omits whether the invite sends an email, whether the partner must accept, whether the call is idempotent or repeatable, and what happens on failure.

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 core action and the streak consequence are front-loaded in two tight sentences with zero filler. The trailing 'Tip' pointing at earning_opportunities is tangential promotion that doesn't help the agent invoke this tool, keeping it from a 5.

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 annotations and no output schema, the description should cover what a successful invite produces and what the caller needs in place first. It gives the social contract but not the operational outcome (pending invitation state, follow-up via pillar_dca_partners), leaving a gap for a mutation-style tool.

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?

One required parameter with 100% schema coverage, so the baseline is 3. The description repeats the schema's email-or-wallet duality without adding format rules, validation constraints, or resolution behavior beyond what the schema already states.

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?

States a specific verb and resource: 'Invite a DCA partner by email or wallet address.' That is clearly distinguishable from read siblings like pillar_dca_partners or pillar_dca_status, but the near-identical sibling pillar_direct_dca_invite is never mentioned, so the agent cannot tell which variant to pick from the description alone.

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?

Usage is only implied via the accountability mechanic ('both must boost each week to keep the streak alive'), which hints at the context in which a partnership makes sense. There is no explicit when-to-use versus when-not, no mention of prerequisites (connected pillar wallet), and no disambiguation from pillar_direct_dca_invite.

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