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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a few useful behaviors: the tool reads Facebook Business Manager data and accepts business_ids for batched execution. It does not contradict the annotations, but it adds little beyond those basic traits.

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 not excessively long, but it spends most of its length listing unrelated actions that do not belong to a users-only flattened tool. The four non-user actions create noise and re-introduce ambiguity. A clear sentence such as 'Read users and system users for a Facebook Business Manager' would be far more concise and precise.

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 read-only listing tool, the description should identify the target resource, the accepted identifiers, and any batch behavior. It identifies the resource but leaves business_id and auth_account ambiguous, does not say what the response contains beyond users, and does not clarify what 'Flattened action: users' means operationally.

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%, so the description must explain the parameters, but it only mentions that business_ids is used for batched execution. The meaning of business_id and especially auth_account is not explained. An agent would have to infer these from their names and the surrounding tool context.

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 begins with 'Read Facebook Business Manager data' and the 'users' line mentions business users and system users, so the core purpose is recognizable. However, it lists five action types (list, accounts, pages, users, pixels) before the bracketed '[Flattened action: users]', which obscures the actual single action and blurs the distinction from sibling tools like meta_ads_business_pages and meta_ads_business_accounts.

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?

There is no explicit guidance about when to use this tool versus sibling tools such as meta_ads_business_accounts, meta_ads_business_pages, meta_ads_business_pixels, or meta_ads_business_list. The action list actually suggests this tool can be used for non-user actions, and the 'Flattened action: users' note is too implicit to serve as firm usage direction.

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