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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), and the description adds genuine context beyond them: the not-found contract ('complete=true, found=false, status=not_found as a normal read — it does not authorize a write') and the returned key families. It loses a point because the create-preparation/music-verification paragraph describes downstream behavior that isn't this tool's own contract. No contradiction with annotations.

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 required-selector rule and examples are front-loaded and efficient, but the definition sprawls into return-key enumeration and create-preparation/music-verification detail that belongs to sibling flows. Those sentences inflate length without helping the agent select or invoke this read tool.

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?

With no output schema, the description usefully names the returned structures (adset_params, adgroup_params, effective_creation_defaults), and the not-found semantics close the main gap for a read tool. The undocumented connection_context and the tangential music-approval paragraph keep it from being fully complete.

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 0%, so the description must carry the parameter burden and it partly does — it explains that template_name is preferred and exact, and that either selector satisfies the requirement. However, connection_context (an mctx_v1_ pattern param) is never explained, and format expectations for template_name casing/matching are left implicit.

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 — 'Get one saved template owned by the authenticated user' — and the exact single-record scope immediately distinguishes it from templates_list, templates_create, and templates_update. It even names the upstream analog it mirrors ('Mirrors Meta templates_get'), so the agent knows the semantics without opening the schema.

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 selector guidance is explicit: 'by exact template_name (preferred, Meta-portable) or template_id', with two concrete call examples. It gives clear context for how to invoke, but never states when to reach for this tool versus templates_list or when a template lookup should happen before a create — no explicit alternatives or exclusions.

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