meta get business assets

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds a permission-dependent availability caveat ('when permissions allow') and the notion of 'accessible' assets, which is useful context beyond the annotation flags.

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 a single, tightly packed sentence that front-loads the key facts: read-only discovery, the asset categories, and the permission caveat. There is no filler or repetition of schema details.

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 tool's complexity—six parameters, nested outputs, and pagination semantics—the description is minimal, but the input schema, annotations, and output schema carry most of the necessary detail. It is complete enough for an agent to understand the tool's core role, though it would be stronger with explicit guidance on pagination strategy and sibling-tool selection.

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%, and each of the six parameters already has rich semantic documentation including defaults, bounds, and contextual usage notes for cursor, cursors, businessId, and adAccountId. The description does not add parameter-level detail, so the baseline of 3 is appropriate.

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 uses a specific action ('Discover') and a concrete resource scope ('Meta Business assets') with the asset types enumerated: businesses, pages, Instagram accounts, pixels, and datasets. This makes the tool's purpose clear and distinguishes it from the more granular sibling getters, though it does not explicitly name or differentiate from those siblings.

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?

The list of multiple asset types implies this is a broad discovery tool, but the description never states when to prefer it over sibling tools like meta_get_pages or meta_get_pixels, nor does it mention any exclusions. Usage context is only implicit through the 'assets' aggregation language.

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