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

No annotations are provided, so the description carries the full burden. It discloses that the Telegram chat id is captured later via the enrollment deep link, and mentions authentication requirements. It does not explicitly state side effects (e.g., creates a pending record) or idempotency, but the flow is clear enough. A slight gap is lack of detail on failure modes or return behavior, but the description goes beyond the bare minimum.

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 well-structured with a main sentence, an agent usage note, and an ACCESS block. It front-loads the core purpose and provides necessary operational context. It is not overly verbose, though the ACCESS note could be slightly more concise. Overall, it earns its place without redundancy.

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?

Given 3 parameters, no output schema, and no annotations, the description covers the tool's role, the follow-up step, and prerequisites. It doesn't detail error handling or idempotency, but for a simple add operation, this is sufficient. The flow is explained, and the agent knows exactly what to do after calling it. A small gap is not specifying what the response contains, but since there's no output schema, this is acceptable.

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 coverage is 100%, so the schema already describes each parameter (id, name, whatsapp_phone). The description adds only a minor nuance: 'by name' and 'optional pre-declared WhatsApp phone,' which aligns with the schema but doesn't add new semantic value. Given full schema coverage, the baseline of 3 is appropriate.

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?

Description clearly states the action: 'Add a pending member to a Circle by name, with an optional pre-declared WhatsApp phone.' It specifies the verb (add), the resource (Circle member), and the parameters. It also distinguishes from siblings like add_challenger and add_circle_member_channel by focusing on membership and the follow-up enrollment link.

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?

Provides explicit sequential guidance: 'after adding a member, call invite_circle_member to mint the single-use enrollment link the member taps to bind their messenger identity.' Also states access prerequisites: 'needs a Proof account. Authenticate this client... then call this tool again. start_login does NOT open this tool.' This tells the agent exactly when and how to use it, including what not to do.

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