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

With no annotations, the description carries the full burden of behavioral disclosure. It states the core behavior and reversibility through 'unflag', but omits side effects, idempotency, return value, account/auth requirements, and behavior when the flag is already in the requested state.

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 zero filler. The verb and resource are front-loaded, and every word contributes meaning; the parenthetical 'star' clarifies the terminology without adding bulk.

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?

All parameters are documented in the schema, and the operation is simple, so the description covers most of what an agent needs. However, the absence of an output schema, annotations, and usage guidance leaves minor gaps around return behavior, idempotency, and when to choose this over 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?

Schema description coverage is 100%, so the schema already documents id, account, and flagged clearly. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 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 ('flag') and resource ('email'), and explicitly covers both directions ('flag/star' and 'unflag'). This clearly distinguishes it from sibling tools like set_read_status or move_email based on the operation name and semantics.

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?

No guidance is provided about when to use this tool versus alternatives such as set_read_status. There are no exclusions, prerequisites, or scenario descriptions. The usage is only implicit from the operation name.

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. 'List' implies a read-only operation, and 'server is configured to access' adds useful scoping, but it does not disclose the shape of the returned data, access failures, pagination, or any permission requirements.

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, front-loaded sentence with no filler. It immediately states the action and the resource being listed, making it 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?

Although the tool has no parameters and is simple, the description leaves a critical ambiguity with the sibling list_mailboxes and does not explain what the returned list contains or how 'configured to access' behaves. An agent cannot reliably distinguish this tool from list_mailboxes based on the description alone.

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 input schema has zero parameters and schema description coverage is 100%, so there are no parameter semantics for the description to clarify. This meets the baseline for a no-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 clearly uses the verb 'List' with a specific resource, 'Lettio mailboxes', and adds a scope: 'this server is configured to access.' However, the tool name is list_accounts and a sibling list_mailboxes exists, so the description does not explicitly differentiate accounts from 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?

There is no guidance about when to use this tool versus list_mailboxes or any of the other sibling tools. The description states what the tool does but not when it should be selected over alternatives.

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 is transparent about the read-only nature and return contents (counts), but with no annotations it does not disclose behavior when the optional account parameter is omitted, nor any implications for configured accounts. It adds minimal behavioral context beyond the stated purpose.

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 phrase adds information about the returned data.

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?

Adequate for a simple one-parameter, read-only list operation; the description states both the resource and the included counts. However, it omits the relationship to list_accounts and behavior when account is not supplied, leaving some inference to the agent.

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 input schema already provides 100% description coverage for the single 'account' parameter, so the description adds no new semantic detail. It does not clarify optionality or default behavior beyond the schema's required list.

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 action ('List') on a specific resource ('folders (mailboxes) in a Lettio account') and includes the output detail of message/unread counts. This differentiates it clearly from sibling tools like list_accounts and list_recent_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?

Provides no guidance on when to choose this tool over siblings such as list_accounts or search_emails. No mention of prerequisites, alternatives, or exclusion criteria.

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 burden of behavioral disclosure. 'List' implies a read-only operation and 'most recent' implies ordering, but the description does not explicitly state side effects, return characteristics, or account/mailbox resolution behavior beyond what the schema already documents.

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, information-dense sentence with no filler or repetition. The key action and default scope are front-loaded, making it easy to scan.

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 list operation with fully documented parameters, the description is largely sufficient. It lacks an explicit description of the return payload (no output schema exists), but the core invocation details are covered by the description plus the input schema.

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 parameters are already well documented. The description adds little beyond the schema, except for the default-to-inbox behavior, which the schema also states. This matches the baseline for complete schema coverage.

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 names a specific verb ('List') and resource ('most recent emails in a Lettio mailbox') and clarifies the default scope ('defaults to the inbox'). This makes it easy to distinguish from siblings like search_emails, read_email, and 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 clearly implies its use case—retrieving a recent list of emails—but it does not explicitly mention when to prefer this over alternatives like search_emails or read_email. No exclusions or alternative routing are provided, leaving usage partly to inference.

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 burden of disclosing side effects. It does disclose that moving to 'trash' is reversible, which is useful behavioral context. However, it does not specify whether moving to a custom folder is reversible, whether the email is removed from the source folder, or any permission/auth requirements. The coverage is partial.

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 one sentence, front-loaded with the core action, and then gives concrete examples. It is concise and to the point, though it slightly repeats the schema's mailbox description. No filler or unnecessary detail.

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 is a mutation with no output schema and no annotations. The description covers the main action and special folder values but omits important context: what happens on success (return value), how errors are handled, whether the operation is idempotent, and under what conditions the 'account' parameter is required. An agent might be uncertain about expected behavior after calling the 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 description coverage is 100%, so the schema already documents each parameter. The description adds a bit of nuance by clarifying that 'archive' and 'trash' are special roles and that trash is reversible, but this mostly mirrors the schema's mailbox description. It does not introduce new parameter semantics beyond what the schema provides, so a baseline of 3 is appropriate.

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 the action: 'Move an email to another folder' – a specific verb and resource. It differentiates from siblings by its unique purpose, and the examples of special folder names ('archive', 'trash') add precision. No ambiguity about what the tool does.

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 (moving an email to a folder) but does not explicitly contrast with alternatives like set_read_status or search_emails. It gives concrete value choices for the 'mailbox' parameter but does not state when not to use this tool or when a sibling is more appropriate.

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 behavioral disclosure burden. 'Read the full content' clearly signals a read-only operation, but it does not clarify whether reading affects read/unread state, what happens with attachments, or whether the account parameter is needed for a specific mailbox.

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 that states the operation, the scope, and the prerequisite workflow. Every word earns its place and there is no redundant 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?

For a simple two-parameter read tool with full schema coverage and no nested objects, the description gives enough to invoke it correctly. It could mention the return format or whether the account parameter is required, but those are minor gaps given the low complexity.

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 input schema already documents both parameters. The description adds only that the id comes from list/search, which is helpful but does not add meaningful semantic detail 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 ('Read'), a concrete resource ('one email'), and a clear access mechanism ('by its id'). It also tells the agent to obtain ids from list/search first, which distinguishes this tool from the metadata-list 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 clear workflow context: use list/search first to get the email id, then call this tool. It does not explicitly contrast with sibling tools like search_emails or set_read_status, but the intended placement in a fetch-by-id flow is 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does reveal two important behaviors: the reply is threaded, and the sender is the mailbox only. However, it does not mention permissions, irreversibility of sending, response/return behavior, or potential side effects beyond the act of sending.

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 short sentences with no filler or redundancy. The core purpose is front-loaded, and the sender constraint is stated in the second sentence without unnecessary elaboration.

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 full schema coverage and clear sibling context, the description gives an agent enough to invoke it correctly. The main gap is the lack of any return-value or error-behavior guidance, which matters slightly more because there is no output schema and no annotations.

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 input schema already documents all four parameters with complete descriptions, so the baseline is 3. The description adds no extra parameter-level detail beyond what the schema provides.

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 ('Reply') with a clear resource ('an email') and adds two distinguishing details: it stays in the same conversation thread and sends as the mailbox only. This makes it easy to tell apart from sibling tools like send_email and read_email.

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 clearly conveys when to use the tool: when the user wants to reply to an existing email within the same thread. It does not explicitly name an alternative such as send_email for new emails, but the context is unambiguous enough for an agent to select correctly.

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. It discloses the matching scope (sender, subject, body) and that it searches a mailbox, but it does not mention pagination, result ordering, or whether the search is case-insensitive. It also doesn't clarify what happens with the 'account' parameter when multiple accounts exist. This is adequate but not rich.

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 that states the action, resource, and matching scope with zero waste. 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 search tool with 3 parameters and no output schema, the description is reasonably complete. However, it lacks guidance on the 'account' parameter (which configured account to use) and doesn't describe the result format or ordering. Given the sibling set includes list_recent_emails, a note on when to use search vs. list would improve completeness.

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 schema already documents all three parameters. The description adds the context that the query matches sender, subject, and body, which is useful, but it doesn't add meaning beyond the schema for 'limit' or 'account'. Baseline 3 is appropriate.

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 ('Search'), a resource ('Lettio mailbox'), and the matching scope ('sender, subject and body'). This clearly distinguishes it from siblings like list_recent_emails and read_email, which have different purposes.

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 for free-text search across a mailbox, but it does not explicitly state when to use this tool versus alternatives like list_recent_emails or list_mailboxes. There is no exclusion or alternative guidance, so the agent must infer the appropriate context from the sibling names.

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 behavioral burden. It adds a meaningful side-effect warning: 'this really sends' indicates the operation is a real, consequential action. However, it does not disclose other behavioral details such as account selection, failure behavior, or confirmation of delivery.

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 short sentences with no filler. The core purpose comes first, and the consequential warning is front-loaded and purposeful.

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 send operation, the description plus full schema coverage is mostly sufficient. However, there is no output schema and no annotation, so the description could usefully mention what happens after sending or what the tool returns, which is currently absent.

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 all five parameters. The description adds no additional parameter-level meaning, which matches the baseline for fully covered schemas.

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 and resource: 'Send an email from a Lettio mailbox.' It is specific enough to identify the action, but it does not explicitly differentiate from siblings like reply_email or set_read_status beyond the obvious verb choice.

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 no guidance on when to use this tool versus alternatives such as reply_email or search_emails. The warning 'Use deliberately — this really sends' cautions about consequences but does not provide usage context 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?

No annotations are present, so the description bears the full burden of behavioral disclosure. It only states the action ('mark as read or unread') without mentioning side effects, idempotency, permission requirements, or whether the change is reversible. For a mutating operation this is a meaningful gap.

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, front-loaded sentence with no filler. Every word is informative and the core action is stated immediately. It is appropriately concise for a simple 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?

The tool is simple and the schema covers all parameters, but the description lacks any statement about return behavior, scope (e.g., only emails in the current account), or effects of omitting the optional `account` parameter. With no annotations or output schema, a bit more behavioral context would improve completeness.

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 input schema already fully documents all three parameters with descriptions (id, read, account), so the description adds no additional parameter-level meaning. Per the high schema coverage baseline, a score of 3 is appropriate.

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 'Mark an email as read or unread' uses a specific verb and resource, immediately distinguishing it from siblings like read_email (fetch content) and flag_email (set a flag). It conveys exactly what state change occurs. This is fully specific and unambiguous.

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?

There is no guidance on when to use this tool versus alternatives such as read_email or flag_email. No prerequisites, exclusions, or routing conditions are mentioned. The intended usage is only implied by the tool name and description, so an agent must infer it.

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