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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description still adds real value by disclosing the pagination continuation token and, importantly, that contact details, photos and custom data are excluded from results — telling an agent this tool cannot supply emails or profile images.

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?

Three short, front-loaded sentences: what you get, how to continue, what is excluded. No filler, and the most actionable detail (pagination) appears before the caveats.

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?

No output schema exists, and the description partially compensates by describing excluded fields, so an agent knows roughly what a member record contains. It remains incomplete on the is_admin filter and on what 'the selected account' means operationally given siblings like smartplan_list_accounts and smartplan_get_account.

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 0% across three parameters. The description implies a page-size/offset model via 'one page' and 'next_offset', but it never explains the limit maximum of 50 or the offset parameter by name. The is_admin filter — a meaningful selection control — is not mentioned at all, leaving a third of the inputs undocumented in both schema and description.

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 (list members) plus scope ('one page ... for the selected account'), which clearly separates it from the singular smartplan_get_member sibling. It stops short of naming that sibling or saying what makes a member match, but the list-vs-get distinction is inferable.

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?

Pagination usage is explicit ('continue with next_offset'), which tells the agent how to iterate. However there is no guidance on when to use this versus smartplan_get_member for a single record, and no mention of how the is_admin filter affects which members come back.

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