datasets_facebook_pages_item

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

Annotations are absent, so the description carries the full burden of behavioral disclosure. It adds the scoping detail that the record comes from a specific dataset enum (`facebook-pages`) and that the lookup is by page id, but it does not state anything about response shape, error behavior, pagination, rate limits, or possible missing-record behavior. For a single-record retrieval tool this may be enough in context, but without annotations the transparency is shallow.

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 with no fluff: it states the operation, the resource, the lookup key, and the dataset source. The sentence is front-loaded with 'Get a Facebook Page' and immediately clarifies the dataset enum. Loses one point only because the same information could be even more compactly aligned with the parameter name, but nothing here is wasted.

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 single-parameter item-lookup tool, the essentials are present: resource, key, and dataset membership. However, with no output schema and no annotations, an agent gets no signal about the return record format, what fields are included, or how errors surface. The description is minimally complete for calling the tool, but leaves the agent blind to the result shape, which is a meaningful gap for a dataset-item endpoint.

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 schema already has 100% coverage: `page_id` is described as 'Facebook Page id, max 128 characters'. The description adds the contextual fact that this id resolves a record inside the `facebook-pages` dataset, which slightly extends meaning, but it adds no format or source detail beyond the schema. Baseline 3 is appropriate because the schema does the heavy lifting.

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 states a clear verb-resource pair ('Get a Facebook Page') and identifies the dataset context (`facebook-pages`), which is specific enough to distinguish it from generic page tools. It doesn't explicitly contrast with sibling tools like `facebook_page` or `datasets_facebook_pages_facets`/`search`, but the dataset-enum qualifier narrows the purpose. It could have named the sibling alternative, but as a standalone statement the purpose is clear.

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 says it returns one record 'by page id' from the dataset, which implies this is the single-record item endpoint for datasets_facebook_pages. It does not explicitly say when to use this over `facebook_page` vs `datasets_facebook_pages_search`, and no alternative is named. There is enough context to infer the usage—after you have a page_id from search/facets—but the guidance is implied, not explicit.

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