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

Annotations already mark it as read-only, idempotent, and non-destructive; the description adds detailed behavioral context by listing the specific checks performed and results returned, such as missing files, altered copy-verbatim files, absent packages, config merge status, and Xcode build viability. It does not specify exact output shape, but the enumerated checks are sufficient for an agent to know what to expect.

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?

Three sentences, each with a distinct job: statement of purpose, input/output mapping, and value. The list-heavy middle sentence is dense but not bloated, and the opening 'PAID' is a necessary cost disclosure. The description is well front-loaded.

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 no output schema, the description usefully enumerates the returned categories and states the required inputs at a conceptual level. It does not specify exact output formatting or error behavior, but the schema covers parameter constraints and the tool's scope is clear.

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 description groups the parameters into high-level categories ('file paths with byte sizes, package.json dependencies, project config, build toolchain'), but it adds little beyond the schema, which already documents details like byte sizes, relative paths, and installed versions. With 60% schema coverage, the prose only partially compensates and omits the appId parameter.

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 first sentence states a specific action and object: 'Checks that an emitted app was applied correctly, before it is built.' This clearly distinguishes verify_app from emit_app and the other sibling tools, and the description enumerates the concrete verification dimensions.

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 explicit timing ('before it is built') and intent ('applied correctly'), so an agent knows when to invoke it. It does not explicitly name an alternative or say when not to use it, so it stops short of a 5.

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