meta get page posts

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds meaningful context on top: it resolves a Page token from the connected user, returns only core post fields, and explicitly notes that no advertising eligibility is established. No contradiction exists, and the added behavioral context is valuable.

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 compact and front-loaded: the core read action appears first, followed by return contents, then the key parameter use case, then scoping exclusions. Every sentence contributes information without redundancy or filler.

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 paginated tool with a fully documented input schema and output schema, the description covers the functional purpose, token resolution, return fields, parameter-specific behavior, and exclusions. Nothing an agent needs to correctly select and call this tool is missing.

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%, so the baseline is 3. The description adds beyond the schema by explaining that postId switches the call from the recent-post list to an exact existing post and ties it to the ad preflight scenario. This semantic clarity goes beyond the raw schema field definitions.

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 verb-resource pair ('Read published Facebook Page posts') and clearly delimits its scope by stating what it returns (PageID_PostID, message, permalink, media attachments) and what it does not request (Instagram media, comments, likes, insights). This distinguishes it from the many sibling tools focused on insights, ad accounts, or creative assets.

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 gives an explicit use case ('Use postId for an exact existing-post ad preflight') and clarifies that this read alone does not establish advertising eligibility, setting expectations about what the tool can and cannot accomplish. It does not explicitly name alternative sibling tools for insights or other data, but the exclusions are sufficient for practical routing.

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