get_user_groups_that_user_is_member

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

Beyond the annotations, the description discloses that the operation is read-only against the live school, creates/changes/deletes nothing, uses server-side auth injection, throttles to LearnWorlds' 30-per-10s cap, retries on 429/5xx, and explains the return/error format. This is rich behavioral context that goes well beyond the annotation hints.

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 labeled sections for behavior, returns, and usage, and the key information is front-loaded. The first two sentences are slightly redundant, but the rest is dense and purposeful.

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 the simple one-parameter schema and no output schema, the description covers everything needed: what the call does, auth handling, rate limiting, retry behavior, response format, error semantics, and safe use cases. An agent can invoke this tool correctly without needing additional context.

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?

There is only one parameter, id, and the schema already describes it as 'User Id or email (encoded string)' with 100% coverage. The description reinforces the role of the user in the lookup but does not add meaningful new semantics beyond what the schema already provides.

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: 'Get user groups that a user is member of' and further clarifies it returns a list for the specified user. The user-scoped phrasing distinguishes it from sibling tools like get_user_groups and get_users_user_group even without naming them explicitly.

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?

It explicitly says when to use it: 'safe to call speculatively for lookups and reporting.' It also gives a clear exclusion by saying it is not for changing anything and points toward a matching write tool. However, it does not name the exact alternative write tool or directly compare against get_user_groups, so the guidance is clear but not fully exhaustive.

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