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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so "Read only; no spend" mostly echoes structured data, though the explicit "no spend" is a useful, distinct assurance in a tool family heavily oriented around spend confirmation. Nothing is said about whether the listing is paginated, scoped to the connection, or what a confirm parameter even means for a read operation.

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?

It is short and front-loaded, which is good, but the third fragment ("Fields: soclo://tools/...") is pure noise that occupies a third of an already minimal description and consumes space that could have explained the two required parameters.

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?

Six parameters including a nested object, no output schema, and a confirm/requestId pair that implies a confirmation workflow this read-only tool seemingly does not need — none of that is addressed. For a nested-parameter tool with half its schema undocumented, the description leaves the agent unable to call it confidently.

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?

The only parameter-adjacent text is "Fields: soclo://tools/soclo_ads_list_page_users," a self-referential URI that tells the agent nothing about pageId, businessId, platform, or accountId. With schema description coverage at 50% and a nested parameters object, the description needed to compensate for the undocumented fields and does not.

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 is essentially the title restated with a vendor prefix: "Page users of a business." It conveys a list-like operation only through the tool name, and "Page users" is ambiguous (users of a Facebook Page? a paged listing?). It does nothing to separate it from nearby siblings such as soclo_ads_list_ad_account_users, soclo_ads_list_meta_business_users, or soclo_ads_assign_page_user.

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?

"Read only; no spend" is a safety characterization, not usage guidance. There is no statement of when to reach for this tool versus the ad-account-users or meta-business-users listers, nor any mention of what prerequisite context (account, page, business) the caller must already have.

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