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

The safety profile is already covered by readOnlyHint/idempotentHint/non-destructive annotations. The description adds real context beyond that: sensitive account fields are redacted, and approval requirements are organization-configurable with business workflow approvals always applying. However, the approval sentence is vague boilerplate for a read-only list call and does not say what gets redacted or how results are ordered/paged.

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 sentences with no padding, and the purpose is front-loaded. The third sentence about configurable MCP approvals is unclear in this context and does not clearly earn its place for a read-only listing call.

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?

An output schema exists, so return values need not be described. Still, for a paginated, searchable list tool with zero schema coverage, the description should say how paging and search behave and whether a total count is returned; the redaction note is the main completeness win here.

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% and the description mentions none of the three parameters. It never explains that limit/offset provide pagination (with a 100 max) or that search filters users, so the description fails to compensate for the undocumented schema. Only the parameter names themselves give any hint.

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 gives a clear verb and resource ("Read organization users") and a hint of scope ("for assignments"). It does not name or contrast with nearby siblings like list_team_invitations, so an agent must infer the boundary, but the core purpose is unambiguous.

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?

"For assignments" implies a use case but there is no explicit when-to-use guidance, no when-not, and no named alternative (e.g., list_team_invitations for pending invites). The agent is left to infer selection criteria from the name alone.

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