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

Beyond the readOnly/idempotent/non-destructive annotations, the description discloses permission behavior ('Another person's private template is not_found'), canChangeVisibility semantics, how hidden/private usage is counted but not named, that dry runs are excluded, and how former members appear in createdBy. This is rich behavioral context that annotations alone do not provide.

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 key purpose is front-loaded, but the description is a single dense sentence packed with semicolon-separated clauses. Most clauses carry useful return-field semantics, so there is little pure filler, but the structure is hard to scan and could be more concise.

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 fully compensates by explaining the returned fields, tag behavior, labels vs template tags, project filing, usage counting rules, visibility, ownership, and edge cases like private templates returning not_found. An agent has enough context to call and interpret this tool correctly.

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?

There is only one parameter, and the input schema already documents it at 100% coverage with the 24-hex pattern and source tool. The description adds no extra syntax, format, or constraint details beyond what the schema provides, so the baseline 3 applies.

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 opens with a specific verb and resource: 'One email template by id', then enumerates the exact fields returned. It clearly distinguishes this from list operations by requiring an id and from private-template visibility by noting the not_found behavior.

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 schema and description both point the agent to lnkdrp_list_email_templates as the source of the id, giving clear context for when to use this tool. It does not explicitly name alternatives like lnkdrp_get_email_template_draft or lnkdrp_compare_email_template_versions, so it stops short of full when/when-not guidance.

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