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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful behavioral hint that results carry approval status, but says nothing about pagination, result volume, or rate limits for a call that could return many templates.

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?

A single short sentence with the resource front-loaded and zero filler. It is terse to the point of terseness being the only risk, but nothing 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 one-parameter read tool with a fully described schema and read-only annotations, most of the burden is already carried elsewhere. However, with no output schema, the description could say more about what a returned template record contains (id, name, language, category) beyond the single mention of approval status.

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?

Schema description coverage is 100%, so the waba_id parameter is already fully documented, including a pointer to bridge_list_numbers. The description adds no format or sourcing detail beyond the schema and slightly blurs things by calling the scope "a number."

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 gives a specific verb and resource ("List the message templates") and adds the key returned attribute (approval status), which tells an agent this is a status-inspection call rather than a send. It does not distinguish itself from siblings such as bridge_send_template, and it says "of a number" even though the required parameter is a WABA ID, leaving a small terminology mismatch.

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?

There is no explicit when-to-use guidance, no prerequisite or ordering advice (e.g., call this before bridge_send_template to check approval), and no named alternative. The intended usage is only loosely inferable from the verb "List".

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