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

Annotations already convey that this is a write, non-idempotent, non-destructive operation. The description adds useful behavioral context beyond those hints: the agentKey must come from a fresh list call, server writes must be enabled, and confirm=true is required. No contradiction with annotations exists.

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 description is a single dense sentence with no filler. It front-loads the action and immediately states the most important prerequisites and safety requirements. Every clause earns its place.

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 mutating tool with no output schema and sparse parameter documentation, the description includes the critical preconditions to avoid mis-keying an Agent. However, it omits any guidance on the remaining parameters, expected response behavior, or duplicate-template handling, so it is only minimally 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 only 13%, so the description must compensate. It does helpfully explain agentKey, expectedAgentName, and confirm usage, but leaves templateName, subject, htmlBody, textBody, and templateAlias entirely to name-based inference. This is adequate but not thorough for an 8-parameter tool.

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 states a clear verb-resource pair: create a template, and identifies the target scope as a specific ZeptoMail Agent. It is distinguishable from the list/get/update/delete siblings, though the phrase 'one explicit Agent' is slightly awkward and could be clearer.

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 description gives concrete invocation prerequisites: obtain agentKey and expectedAgentName from a fresh zeptomail_list_agents call, ensure server writes are enabled, and set confirm=true. It does not explicitly contrast this with zeptomail_update_template, but the prerequisites and confirmation gate provide strong usage direction.

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

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

Annotations already indicate destructive and non-read-only behavior. The description adds valuable context: deletion is permanent, expected values must come from fresh reads to prevent stale operations, and confirm=true is required. This goes meaningfully beyond the structured 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?

Three short sentences with no filler. The destructive action, freshness requirement, and confirmation gate are all stated efficiently and front-loaded.

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 destructive tool with six parameters and no output schema, the description covers the critical preconditions: fresh reads, writes enabled, confirm=true, and explicit agent scope. It doesn't describe behavior when confirm=false or when expected values mismatch, but the essentials for safe invocation are present.

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 only 17%, so the description must compensate. It does explain that expectedAgentName, expectedTemplateName, and expectedModifiedTime must come from fresh reads, and that confirm must be true. However, templateKey is left undocumented in both schema and description, so coverage is not complete.

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 clearly identifies the action ('Permanently delete'), the resource ('a template'), and the scope ('from one explicit Agent'). This distinguishes it from listing, getting, creating, and updating templates, even without naming a sibling.

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 description gives clear usage context: the tool should only be used after fresh reads, with writes enabled, and with confirm=true. It doesn't explicitly contrast with sibling tools, but the destructive delete semantics and prerequisites make the appropriate use case clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description reinforces these by saying 'Read-only' and adding valuable clarification that the tool does not write to disk—the caller handles file writing. This goes beyond the annotations by explicitly addressing side-effect expectations.

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 deliver both the functional scope and the usage context with no wasted words. The key behavior is front-loaded, and the clarifying 'does not write to disk' earns its place in the same sentence.

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 simple one-parameter, read-only export tool, the description covers what is returned, the scope, the caller's responsibility, and the primary use case. It does not describe output size or pagination, but the absence of an output schema and the straightforward nature of the operation make this adequate.

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% and the sole parameter agentKey is already well documented as an exact mailagent_key/alias returned by zeptomail_list_agents. The description mentions 'one explicit Agent' but adds no new parameter-level meaning beyond the schema.

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 uses a specific verb 'Fetch' with a precise resource: every full template from one explicit Agent, returned as a single JSON dump. It lists the exact fields included, which clearly distinguishes it from sibling list/find/get tools even without naming them.

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 description explicitly states the intended use case: backing up an Agent's templates to local files, and clarifies that the caller writes files while this tool only returns data. It does not explicitly name alternatives or say when not to use it, but the use-case framing provides clear directional guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context beyond that: the scope of the search with and without agentKey, and that results always include the owning Agent.

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?

Three sentences, each earning its place: the search action, the scoping behavior, and the guaranteed result field. No redundancy or filler.

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?

Given the safe annotations and simple parameter set, the description covers the essential behavior: what is searched, how to scope the search, and what results always include. The absence of an output schema is partially mitigated by the 'owning Agent' note, though full result shape is still not described.

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 only 33%, but the description compensates by explaining that query searches name, alias, and subject, and by clarifying agentKey's optionality. maxResults is not mentioned, though its schema defaults, min, and max make its behavior reasonably inferable.

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: 'Search template name, alias and subject.' It clearly separates this search-oriented tool from sibling list/get/create/update/delete operations, and the agentKey scoping further sharpens its purpose.

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 description gives clear context for use: omit agentKey to search all accessible Agents, or provide it to restrict to one Agent. It does not explicitly name alternatives or state when not to use the tool, but the search scope guidance is straightforward.

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

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds a workflow rule ('before updating or deleting') and indicates the return is a 'complete template', but does not describe error conditions, auth, or pagination. This is adequate given annotation coverage, but not richly transparent.

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 with no fluff. The primary action is front-loaded, and the workflow requirement is stated immediately after. Every word earns its place.

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 simple read-only fetch with two required parameters and no output schema, the description covers what is returned ('complete template'), the key inputs, and when to call it. It does not enumerate the template fields or failure modes, but that level of detail is not essential for invoking it 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?

The schema already gives a thorough description for agentKey, but templateKey is only a bare string. The description adds that both keys must be 'exact' and that agentKey comes from zeptomail_list_agents, but it does not say where templateKey originates (e.g., zeptomail_list_templates). With 50% schema coverage, the description partially compensates but leaves a meaningful gap.

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 states a specific verb ('Fetch'), a clear resource ('one complete template'), and the selection criteria ('from one explicit Agent by exact template key'). It clearly distinguishes this tool from siblings like list_templates or find_templates by emphasizing exactness and a single full template, and from update/delete by explicitly positioning it as a prerequisite before those operations.

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 directive 'Always call this before updating or deleting' provides explicit when-to-use guidance and places this tool in a workflow. It does not explicitly state when not to use it or name alternatives for searching/listing, but the context is clear enough for an agent to select this over mutation or search tools.

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

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

Annotations already declare this as read-only and idempotent. The description adds meaningful behavioral context by explaining that the tool returns exact mailagent_key values and warning against guessing identifiers, which goes beyond the annotation baseline.

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 description is two sentences with no filler. It front-loads the primary action, then provides the essential output detail and a practical warning.

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?

Given that there is no output schema, the description adequately explains the return contents: Agent name and exact mailagent_key. It also explains why this matters for subsequent template tools, making it complete for a simple list operation.

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 has zero parameters, so no parameter documentation is needed. The description correctly focuses on what the tool returns rather than input semantics.

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 states a specific verb and resource: 'List accessible Agents in the ZeptoMail account.' It also clarifies the exact output value, the mailagent_key (Agent alias), and distinguishes this tool from the template-focused siblings.

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 description gives a clear usage directive: always use the returned key for template tools and do not guess Agent identifiers. It doesn't name explicit alternatives or exclusion conditions, but the context makes the intended workflow clear.

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

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

Annotations already communicate readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds that the tool is scoped to one explicit Agent and depends on the prior agent lookup. It does not disclose pagination, ordering, or return format, but these are minor given the 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 description is two tight sentences with no filler. The core action and the most important usage note are front-loaded, and every word contributes to correct invocation.

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 listing tool, the critical dependency on zeptomail_list_agents is explicit and the schema covers pagination bounds. The absence of an output schema means the return shape is not described, which is a minor gap but not a blocker since the resource and listing behavior are clear.

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 only 33%, and the description mostly restates what the agentKey schema field already says: pass the exact mailagent_key returned by zeptomail_list_agents. It adds little meaning for limit and offset, which rely on names and numeric constraints rather than explanatory descriptions.

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 states a specific verb and resource: 'List templates in one explicit ZeptoMail Agent.' It also conveys the agent-scoped nature, which separates it from listing agents or cross-agent template operations. However, it does not explicitly distinguish itself from sibling tools like zeptomail_find_templates or zeptomail_export_templates.

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?

It gives a clear prerequisite: use zeptomail_list_agents first and pass the exact returned mailagent_key. This is strong contextual guidance for when this tool should be called. It does not, however, state when to prefer alternatives such as zeptomail_find_templates instead.

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

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

Annotations already mark this as non-read-only and destructive. The description adds meaningful guardrail context beyond annotations: stale or wrong-Agent edits are rejected, confirmation is mandatory, and writes must be enabled. This goes beyond what the schema or annotations alone convey.

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 description is two dense sentences with no filler. The core action is front-loaded, and the critical requirements are stated immediately after, making it easy for an agent to parse and act on.

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 destructive, mutation-focused tool with 10 parameters and no output schema, the description covers the key invocation requirements: partial update, single Agent, fresh expected values, writes enabled, and confirmation. It does not describe return values or detailed error behavior, but the lack of an output schema lowers that burden.

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 only 10%, so the description must compensate. It usefully explains expectedAgentName and expectedModifiedTime as optimistic-concurrency guards and mentions confirm=true, but it does not clarify the semantics of subject, htmlBody, textBody, templateName, or templateAlias beyond their raw string types.

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 uses a specific verb and resource: 'Partially update a template in one explicit Agent.' It distinguishes this from create, delete, get, and export sibling tools by emphasizing partial update and single-Agent scope, so an agent can tell what the tool is for 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 description clearly states preconditions: expectedAgentName and expectedModifiedTime must come from fresh reads, writes must be enabled, and confirm=true. It shows when to use the tool but does not explicitly contrast it with related tools or state when not to use it.

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