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

The annotations already establish safety: readOnly true, destructive false, openWorld false. The description adds behavior beyond the annotations: a 30-day validity window, a 2-badge creation cost, and per-item expiry and remaining-day reporting. It still does not say how expired digital humans appear in the results, nor whether the list is paginated, though the sibling tools and the limit parameter cover pagination.

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?

Two sentences: the first front-loads the listing scope and the returned fields, and the second carries the trigger rule. The business-rule clause about the 2-badge creation cost is mildly tangential to a read-only listing tool, but it supports the 'must call' claim.

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 tool is simple: one optional parameter, a read-only annotation set, and no output schema. The description compensates by listing the return fields and the business rules behind 'remaining days'. Only minor gaps remain: how expired records are represented and whether results are paged.

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?

The only parameter is limit, and the schema already documents it fully (default 20, max 50), so schema coverage is 100%. The description adds no meaning about paging or about whether this tool truncates the list. With the schema covering the whole surface, a 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?

The description opens with a specific verb plus resource plus scope: it lists the digital humans created by the currently connected account, and it enumerates the fields returned (expiry status, remaining days, location, conversation link). This clearly separates it from create_digital_human and delete_digital_human, but it never names get_digital_human, the sibling that presumably fetches a single record, so the sibling boundary is only implied.

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 an explicit trigger condition: to answer 'how much longer can my digital human be used' or 'when does it expire', you must call this tool first. That is a concrete when-to-use rule. It stops short of stating when NOT to use it, such as deferring to get_digital_human when you already know which ID to inspect.

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