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 that it returns record counts, which is a behavioral detail not in the schema, and mentions 'fields, types, and relationships', giving a sense of the payload. However, it doesn't disclose potential large response sizes or pagination behavior, which might be relevant for an app with many entities, but given the annotation coverage, the bar is lowered.

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 concise: two sentences with no fluff. It front-loads the main action ('Get all entity schemas') and adds a useful detail (record counts) and content aspects. It's efficient, though it could have been slightly more specific about the output shape without adding much length.

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 simplicity of the tool (one parameter, no output schema, no nested objects), the description covers the core purpose and content. With annotations covering safety and idempotency, the description is adequate for correct invocation. It might be slightly incomplete regarding potential pagination or large result sets, but that's not critical for basic usage. The result format is not described, but since there's no output schema, a brief hint about the return structure could help, but it's not blocking.

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 only parameter 'app_id' is fully described in the schema with 'The app ID', giving 100% coverage. The description does not add clarity beyond what the schema provides; it repeats that it is for an app. Baseline is 3, and the description adds no special value here.

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 tool retrieves all entity schemas for an app and includes record counts, adding detail about content ('fields, types, and relationships'). However, it could be more specific about the exact scope (e.g., whether it includes computed or related entities) and does not distinguish itself from sibling tools like 'create_entity_schema', 'update_entity_schema', or 'query_entity', though the read-only retrieval intent is clear from context.

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 usage for retrieving entity schemas and counts but provides no explicit when-to-use or when-not-to-use guidance. It doesn't name alternatives like 'query_entity' (to fetch actual records) or 'get_entity_schema' (if it existed), leaving the agent to infer that this is a high-level metadata listing. The instruction 'for an app' gives some context, but there's no explicit exclusion of record-level operations.

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