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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false). The description adds real behavioral context beyond that: titles are free to read but prompt bodies require a key, which signals a gated/paywalled workflow. It stops short of explaining return format or pagination, but for a zero-arg list tool this is meaningful added value.

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?

Two sentences, front-loaded with what the tool returns before the usage cue. Slightly verbose in its domain framing but every clause carries information an agent needs (library name, domain, gating, when to call).

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, zero-argument listing tool with annotations carrying the safety profile, the description covers what it returns ('with what each one is for'), the gating condition, and the usage context. Only the follow-up path to get_build_prompt is left implicit.

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 tool takes zero parameters, so the baseline is 4. Nothing about argument syntax needs explaining, and the description correctly does not invent any.

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?

States a specific verb (List) and resource (prompts in the NativeExpress library), plus the domain (React Native with an agent). It distinguishes the listing from fetching bodies by noting 'titles are free; the prompt bodies need a key', but it never names get_build_prompt explicitly.

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?

Gives clear context: 'Use this when someone is working in a mobile app codebase with an agent and wants a tested prompt rather than writing one.' It does not state when *not* to use it or name get_build_prompt as the follow-up alternative.

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