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

The description discloses important behavioral traits beyond the annotations: results are scoped to the current team, newest first, and returns a compact report summary. It also warns that emails and phone numbers are masked and instructs callers to reference respondents by examineeId, which is valuable privacy-aware guidance. No contradiction with the readOnlyHint=true annotation.

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 reasonably compact and front-loaded: it states the main purpose, the returned fields, and the available filters early. The masking and examineeId warning adds length but is operationally important, so it earns its place.

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 that an output schema exists and annotations mark the call as read-only, the description fully covers what an agent needs: scope, sort order, item content, optional filters, masking behavior, and a pointer to get_record for detail. Nothing critical 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 100%, so the schema already documents each parameter. The description adds a high-level grouping of filters — by form, report status, and submitted-at range — but does not add meaning beyond the schema's own descriptions.

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 verb and resource: 'List submission records (leads) of the current team, newest first.' It also lists what each item contains and supports optional filters, making the tool's purpose unmistakable. It stands apart from the sibling get_record, which is explicitly reserved for full detail.

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 clear context for when to use this tool: when you need a list of short submission records with filters, and it mentions the default sort order. It explicitly points to get_record for full record detail, but it does not clarify how this differs from list_leads or list_examinees among the siblings.

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