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

Beyond the destructiveHint=true annotation, the description discloses that the operation writes the entire archive DECRYPTED as plaintext to disk, has a restricted export-root allowlist, and demands explicit host/user confirmation. It also includes a policy that it must not be automatically triggered from untrusted email content. This adds substantial safety-relevant behavior not captured by 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 concise: one sentence for the core purpose followed by a clearly labeled 'DANGEROUS / SIDE EFFECTS' block with the critical caveats. This front-loads the essential action and then isolates the safety warnings, making the tool easy to scan and understand.

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?

The description covers purpose, side effects, required inputs, security restrictions, and execution policy, and an output schema exists so return value details are unnecessary. Given the tool's dangerous nature, the description provides all essential context for an agent to decide whether and how to invoke it.

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 description coverage is 100%, so the baseline is 3. The description's mentions of password being mandatory and target_path resolving inside an allowlist mirror the schema's parameter descriptions, adding no significant new semantics beyond restating those constraints.

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 'Decrypt and export all stored emails and attachments into an organized Obsidian Vault directory' – a specific verb, resource, and destination. This clearly differentiates the tool from the sibling read/sync operations, which do not write an archive.

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 provides clear contextual prerequisites: vault master password is mandatory, targets must be inside a configured allowlist, and host/user confirmation is required before execution. It also warns never to trigger automatically from untrusted email content. However, it does not explicitly name alternative tools or conditions when not to use it, though no sibling is a direct alternative.

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?

No annotations are provided, so the description carries the burden of establishing behavior. It does disclose that the operation is read-only ('Retrieve') and that the content is decrypted and full, which is useful. However, it does not mention authentication, failure behavior, or constraints beyond the ID, leaving moderate transparency gaps.

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 sentence with no filler. The verb, object, and access key are all front-loaded, making it efficient and easy to parse.

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 ID-based fetch with a complete input schema and an output schema present, the description plus structured data is largely sufficient. It lacks explicit usage routing, but no critical invocation detail is missing for this read-only tool.

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 100%, so the schema already documents email_id and format in sufficient detail. The description adds 'decrypted' and 'full content' semantics for the result but no new parameter-level meaning, 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 uses a specific verb ('Retrieve') and names the exact resource ('full decrypted content of an email') plus the access key ('unique internal ID'). This clearly distinguishes it from siblings like search_emails or list_mailboxes.

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 implies that an email_id must already be known by saying 'by its unique internal ID', but it never explicitly says to use search_emails first or when to prefer this tool over alternatives. No exclusions or alternative routing are provided, so usage guidance is only implied.

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?

No annotations are provided, so the description carries the transparency burden. It adds useful behavioral context by describing the tool as returning real-time status and naming the specific subsystems it inspects, which goes beyond the tool name alone.

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 well-structured sentence that front-loads the key action and resource, then lists the specific data categories. Every clause earns its place with no redundancy.

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 zero-parameter read-only status tool with an output schema and no complex side effects, the description is complete. It explains what kind of status is available, and the output schema covers the return structure.

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, and the schema already documents this perfectly. With 0 params, the baseline is 4; the description adds no parameter-specific detail, but none is needed.

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 ('get') and resource ('sync status') and further specifies the exact data returned: IMAP push IDLE listeners, total emails stored, and database statistics. This clearly distinguishes it from sibling tools like sync_now, search_emails, or list_accounts.

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 usage is implied: an agent should call this when it needs current sync/health information. However, the description does not explicitly contrast it with alternatives such as sync_now for triggering a sync, nor does it 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.

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

There are no annotations, so the description carries the burden of behavioral disclosure. It clearly describes the returned data (accounts, statuses, email counts), which is useful, but it does not mention whether this operation requires credentials, whether it triggers synchronization, or whether it reads from cache. For a read-only listing tool, this is adequate 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?

The description is a single, clear sentence that front-loads the action and resource. It is concise and contains no filler. It could arguably mention the output schema, but the sentence itself 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?

The tool has no parameters and a simple listing purpose, and the description covers the key output dimensions. The presence of an output schema reduces the need to describe return values. It lacks explicit sibling differentiation and usage timing, but overall the description is sufficient for a zero-parameter list tool.

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 parameter semantics are inherently trivial. The schema coverage is 100% because there is nothing to document. The description adds value by specifying what the output covers, which helps an agent understand that no further input is needed.

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 ('List') with a clear resource ('all configured email accounts') and states exactly what is returned: connection statuses and total stored emails. This distinguishes it from sibling tools like list_mailboxes, which would list mailboxes rather than accounts.

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 implies this is the tool for account-level overviews but does not explicitly state when to prefer it over siblings such as list_mailboxes or get_sync_status. It gives enough context for an agent to infer the use case, but lacks direct guidance or exclusions.

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?

With no annotations, the description carries the behavioral burden. The word 'List' and the qualifier 'configured' convey a read-only, scoped enumeration, but the description does not disclose edge-case behavior such as invalid account names or whether synced data is required.

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 front-loaded sentence with no filler. Every word contributes meaning, and the scope qualifiers are efficient.

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 tool with one documented parameter and an output schema, the description is sufficiently complete. It could mention that account names come from list_accounts, but this is optional rather than essential.

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 documents account_name fully, including an example. The description adds only 'for an account,' which does not meaningfully extend the parameter 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 action ('List') and resource ('configured mailboxes and folders') scoped to 'an account'. This clearly distinguishes it from sibling tools like list_accounts and search_emails.

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 implies usage: it is the enumeration step for a given account, but it does not explicitly say when to use this tool versus alternatives, nor does it mention prerequisites such as listing accounts first.

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?

With no annotations provided, the description carries the burden of disclosing behavior. It adds meaningful context by specifying that search runs over indexed emails, implying unsynchronized or unindexed messages may not be found, and that queries follow FTS5 semantics. It could still be more explicit about indexing freshness and prerequisites, but the core behavior is disclosed.

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 sentence with no filler, front-loading the verb and object and using a parenthetical for the specific search engine. Every phrase contributes meaningful information.

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 rich input schema and the existence of an output schema, the description is enough for basic invocation. It is less complete on operational context, such as the relationship to syncing/indexing and explicit alternatives among sibling tools.

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?

Input schema coverage is 100%, with each parameter already described and exemplified. The description only adds the high-level notions of 'full-text search' and 'structured filters', which slightly supplements the schema but does not materially clarify individual parameters.

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 states a specific verb ('Search'), a resource ('indexed emails'), and the mechanism ('full-text search (FTS5) and structured filters'). It is easily distinguishable from siblings like list_accounts, get_email, and sync_now, though it does not explicitly name an alternative 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 implies when to use the tool: when an agent needs to find emails by full-text content or structured filters. However, it provides no explicit guidance about when not to use it or which sibling to prefer, such as using get_email for a known single message.

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 description goes well beyond the annotations by explicitly disclosing external network connections, writes to local encrypted storage, disk and network side effects, and the need for host/user confirmation before automatic invocation. This is valuable context that the 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 description is compact, front-loaded with the action, and includes a clearly labeled SIDE EFFECTS section. Every sentence adds value, and the security warning is relevant and well-placed.

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 an action-oriented tool with an output schema, the description sufficiently covers what the tool does, its side effects, and important invocation constraints. The presence of the output schema means return-value details do not need to be in the description.

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 input schema already documents both optional parameters: folder and account. The description itself does not add parameter-specific detail, which is acceptable since the schema carries that burden.

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 ('Trigger') and resource ('sync with IMAP mailboxes to ingest new emails into the bunker'), making the tool's function unambiguous. It also implicitly distinguishes itself from sibling read-only tools like list_accounts and search_emails by describing an action that changes state.

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 makes the core use case clear: immediately initiate an IMAP sync. It also provides a caution about when not to invoke it automatically, such as in response to untrusted email content. It does not explicitly name alternatives, but the siblings are clearly different operations.

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