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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is fully covered by structured data. The description does add one genuinely useful behavioral fact — the master API key authorization requirement — but says nothing about pagination defaults, rate limits, or result size, and an output schema exists so return shape is already covered.

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 tool-authored sentence is one line and front-loads the verb and the auth requirement. That said, the majority of the visible description text is an injected pricing block rather than content that helps an agent select or call the tool.

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?

For a simple 2-optional-parameter, read-only listing tool with an output schema and full annotation coverage, a short description is defensible. Still missing are any statement of what objects are returned, whether filters are supported, and how pagination terminates — gaps that matter given the crowded sibling namespace.

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%: both 'page' and 'per_page' are documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies — the schema carries the full load.

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 verb+resource ('Get a list of users') is stated, but it is generic and gives no sense of what a 'user' is in this API or how this differs from the ~30 sibling search endpoints (contacts, accounts, opportunities). Despite the name ending in '_search', the description never mentions searching, filtering, or querying, so an agent cannot tell how it is distinguished from the other list-style tools.

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?

'Requires a master API key' is a prerequisite, not usage guidance. There is no statement of when to call this versus the many sibling search tools, no exclusion conditions, and no mention of pagination strategy or result scope.

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