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

Goes well beyond the annotations (readOnly=false, openWorld=true, idempotent=false, destructive=false): it discloses the 201 response with a usually-pending template, that only approved templates can be sent, the review lifecycle, the 422/409 error taxonomy with error codes, the specific trap that a retried create after a lost response meets 409 template_name_taken, and the 10 requests/minute per-key budget. The media_url fetch contract (no redirects, must answer 200 with Content-Type, public address, 16 MB cap, downloaded once) is behavioral detail an agent could not infer.

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?

Front-loaded with purpose and outcome, then organized by category/body, media, and error/rate-limit concerns — a sensible order for a 12-parameter nested tool. It is long, and the media_url rules restate almost exactly what the schema description already says, which is the main waste.

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?

No output schema exists, so the description must carry return-value semantics, and it does: the 201 shape, the pending/approved/rejected states, rejected_reason, and field-level 422 vs. template_rejected 422 vs. 409 name collision. Combined with the variable, media and rate-limit rules, nothing an agent needs to call this correctly is missing.

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 coverage is 83%, so the schema carries most parameter documentation; the description still adds meaning the schema does not, notably that Meta may re-file a category and the response shows where it went, the one-variable-style-for-the-whole-template rule, and the authentication-template shape (only `otp`, Meta writes the text). Much of the media_url explanation duplicates the schema verbatim, limiting it to a 4.

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 and resource and immediately scopes it: 'submits a new template on one of the agent's WhatsApp numbers for Meta's review,' with the explicit analogy to the dashboard. It routes the reader to the correct siblings by name (getWhatsAppTemplate for review status, sendWhatsAppTemplate for sending), so it is clearly distinguishable from list/get/update/send template tools.

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 concrete when-to-use context (creating in the dashboard vs. here) and explicit when-not guidance: location headers, carousels, limited-time offers, catalog and Flow buttons must be made in WhatsApp Manager because this endpoint cannot create them. It also tells the agent how to handle a retried create (read the list and carry on). It does not explicitly contrast against update_whatsapp_template, but the create-vs-edit boundary is implied by the media_url 'on an edit' note.

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