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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds the scope 'all pages', which implies no filtering, but does not elaborate on potential large result sets, pagination, or other behaviors. It is consistent with annotations but provides minimal extra context, so a 3 is appropriate.

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, concise sentence with no redundant words. It front-loads the key action and resource, and immediately states what is returned. It is perfectly sized for the tool's simplicity.

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 simple read-only tool with one parameter and no output schema, the description is nearly complete. It states what it returns (file paths and sizes) and covers the essence. The only minor gap is the lack of mention of pagination or result limits, but given the context and the explicit 'all pages', this is a minor omission. A 4 is justified.

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 covers the single parameter app_id completely (100% coverage), including a description. The tool description does not add any extra meaning about the parameter beyond saying 'in an app', which aligns with the schema. Thus, schema documentation carries the burden, and the description adds no additional value.

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 clearly states the action (Get) and resource (all pages in an app), and specifies return contents (file paths and sizes). This differentiates it from sibling tools like get_app_files or read_app_files by focusing specifically on pages. It is precise and unambiguous.

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 does not provide any guidance on when to use this tool versus alternatives. It only states what it does without mentioning scenarios where it should be preferred, such as when needing page-specific data versus app-level files. No exclusions or pointers to siblings are given.

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