meta_get_pages

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

No annotations are present, so the description carries the full disclosure burden. It does add two behavioral cues beyond the schema: results are filtered to 'accessible' Pages and Instagram references are returned only 'when available' (a conditional-field caveat). However, it never states pagination behavior, the /me/accounts vs businessId execution paths, or explicitly confirms a read-only safety profile.

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?

One sentence of roughly 20 words with zero filler. It leads with the action verb and resource, then packs the full return-field list and the conditional-Instagram caveat, giving maximum information per word.

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?

Adequate for a simple list endpoint: the schema documents two of three parameters including the critical businessId-vs-/me/accounts distinction, and the description enumerates all return fields in lieu of an output schema. Remaining gaps — pagination mechanics and empty/error behavior — are minor for a low-complexity tool, though the absence of annotations leaves the read-only profile implicit.

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 67% — cursor and businessId already carry descriptions, and limit's type/default/min/max make its semantics self-evident. The description adds no parameter meaning, but the gap is minor since the undocumented limit is inferable from its constraints.

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?

States a specific verb ('List'), a specific resource ('accessible Facebook Pages'), and enumerates the returned fields (id, name, category, tasks, picture, linked Instagram references). This resource is distinct from every sibling tool — none of the 33 siblings target Facebook Page enumeration, so an agent can tell it apart without opening schemas.

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 description implies the use case (enumerate Pages the authenticated identity can access) but gives no explicit when-to-use or when-not-to-use guidance. With 33 siblings including meta_get_business_assets and meta_get_account_details, which may overlap in asset-listing scope, the absence of alternative routing is a noticeable gap.

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