Server Quality Checklist

Tool Scores

• delete_messageA
  3.6/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the behavioral disclosure burden. It does state that a message is destroyed and that the inbox is not, which is useful scope awareness. However, it does not mention whether deletion is permanent, whether any other state changes occur, or whether any permissions or side conditions apply.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One tight sentence contains action, target, identification key, and scope exclusion. The parenthetical adds meaningful disambiguation without slowing down the reader. No filler or stylistic clutter.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple delete tool with no annotations and no output schema, the description covers the main action and scope, but it leaves parameter semantics incomplete and never connects the sibling tools context. The core operation is understandable, yet an agent may still guess about address and side effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0% and the description does not compensate. 'By its id' presumably maps to message_id, but the address parameter is entirely unexplained. The agent gets no help understanding what address means or how it relates to the inbox, leaving a required parameter ambiguous.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Delete'), a specific resource ('a single message in an inbox'), and an identifying mechanism ('by its id'). The parenthetical '(the inbox itself stays)' actively differentiates this tool from delete_inbox and burn_inbox, making purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use it by describing a single-message deletion scope, and the parenthetical clarifies what it does not do, but it never explicitly names alternatives or states when not to use it. An agent would not know whether to choose this over related sibling tools such as mark_read or delete_inbox from the description alone.

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

• mark_readA
  3.6/5.0
  Behavior3/5

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

  With no annotations provided, the description must carry the behavioral burden. It does disclose the persistent effect of setting the read flag and its impact on future polls. It does not describe error behavior, reversibility, or authorization requirements, but for a simple state mutation it provides reasonable transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One short, front-loaded sentence with no filler. The action and its purpose are both included, and every word contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with only two flat, required parameters, this is nearly adequate, but the description still lacks explanation of what valid values look like and what the call returns. No output schema or annotations exist to fill that gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It maps 'message' to message_id only and gives no additional meaning to 'address', leaving both parameter names to carry all the semantics. This is a clear gap.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific action ('mark one message as read') plus the consequence ('so later polls can skip it'). It is immediately distinguishable from siblings like read_messages or wait_for_message because it describes a state mutation rather than retrieval or waiting.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'so later polls can skip it' implies the tool is meant to be used before subsequent polling, giving contextual guidance. However, it does not explicitly say when to choose this tool over read_messages, wait_for_message, or delete_message, so alternatives are not named.

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

• wait_for_otpA
  3.6/5.0
  Behavior3/5

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

  The description communicates that the tool polls or blocks until an OTP arrives or a timeout occurs, and it gives the return shape. With no annotations available, this carries more weight; however, it leaves the timeout failure behavior unspecified and does not clarify whether the OTP email is merely read or consumed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler. It front-loads the core polling action and then states the return format, leaving no wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool, the description is minimally sufficient: it states when to call it, what happens, and what it returns. But because there are no annotations, no output schema, and no parameter descriptions, the inability to describe the address and timeout failure behavior is a notable gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema descriptions the required address parameter are not explained, nor is the timeout parameter's unit or exact behavior. The description only mentions 'timeout' loosely without adding what an agent needs to fill the required field correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific operation — polling the inbox until an OTP code arrives — and specifies the returned payload. It clearly distinguishes itself from generic sibling tools like wait_for_message through its OTP-specific behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended context is implied: use this when expecting an OTP in an inbox. However, the description does not explicitly state when to prefer this over wait_for_message or how it relates to read_messages, so guidance is only implied rather than explicit.

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

• replyA
  3.9/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the burden of behavioral disclosure. It usefully reveals that the tool fills in the recipient, adds Re: subject, and sets threading headers. However, it does not state the actual side effect of sending a message, possible error conditions, or response behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the most important concept. The second sentence earns its place by explicitly contrasting with send_email, and there is no redundant schema repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has 6 parameters, no annotations, no output schema, and 0% schema description coverage. The description explains the conversation threading intent but does not clarify how an agent should fill required parameters, what reply output is returned, or what happens when the reply cannot be sent. This is significantly incomplete for safe invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% description coverage, and the description does not enumerate or explain the parameters. It gives a partial hint about auto-filled recipient/subject behavior, but leaves address, message_id, cc, bcc, body, and html semantically unexplored. This is insufficient for six parameters with no schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource ('Reply to a message') and immediately defines the key scoping property: the reply stays in the SAME conversation. It also distinguishes itself from send_email by explaining the behavioral difference, so an agent can tell them apart.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says to prefer this tool over send_email when answering, and explains why send_email is inappropriate because it starts a new conversation. This gives the agent a clear when-to-use rule and names the alternative.

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

• delete_inboxA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the responsibility for behavioral disclosure. It explicitly warns that the operation is irreversible and that all messages in the inbox are destroyed. It does not address edge cases like nonexistent addresses or permission requirements, but the core behavioral impact is well stated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two tightly written sentences. Every clause adds value: what is deleted, the scope, the addressing mechanism, and irreversibility. No filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter destructive tool, the description is adequate: it names the target, defines the consequence, and warns about irreversibility. It could mention what happens when the inbox does not exist or whether this is the only way to permanently destroy an inbox, but nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema coverage is 0%, so the description must compensates. The phrase 'by address' gives useful meaning to the address parameter and indicates the inbox identifier, but it does not describe the expected format of the address or how to handle invalid values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the specific verb 'delete', the resource 'an inbox and all its messages', and the identifying key 'by address'. This clearly distinguishes it from related tools like delete_message or create_inbox.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The scope of the operation is clear: deleting an inbox and everything it contains. However, it does not explicitly tell the agent when to choose this over delete_message or burn_inbox, nor does it state any conditions or exclusions.

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

• list_inboxesA
  4/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden of behavioral explanation. The verb 'list' reasonably implies a read-only operation with no side effects, and the API key scoping adds a useful constraint. It does not disclose return format, pagination, or whether deleted/inaccessible inboxes are filtered out, but this is acceptable for a basic listing operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that immediately states the action and the scope, without any redundant words. It is appropriately minimal and well-structured for the tool's simplicity.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless list tool, the description is nearly complete: the agent knows what to invoke and what result to expect conceptually—a list of inboxes. The lack of an output schema means the exact response shape is not specified, but the description communicates enough for straightforward usage.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema already fully defines the input. The description adds meaningful scope context by stating that the result is limited to inboxes available to the API key, which helps the agent understand why no parameters are needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific verb ('List') and resource ('all inboxes') scoped by the API key. It is easily distinguishable from sibling tools like create_inbox or read_messages that target other operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys that this is the tool to use when the agent needs to list or enumerate available inboxes, since no sibling has a listing action. However, it does not explicitly mention when to prefer alternatives like read_messages or create_inbox, leaving some inference to the agent.

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

• create_inboxA
  4.1/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the full burden. It discloses key behaviors: the address is permanent until deletion, messages expire based on retention window, label requires a paid plan (reported in ignored_fields on free), and retention_hours are capped. This is meaningful, though it omits side effects like authentication or whether repeated calls create new inboxes each time.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and front-loaded: it opens with purpose and usage, then adds persistence and parameter notes. Every sentence adds value with no redundancy. It is well organized and easy to scan.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  While the description covers purpose, usage, and some parameter behavior, it leaves `prefix` unexplained and does not clarify whether each call creates a new inbox or returns an existing one. Given the tool has no output schema and no annotations, these omissions leave the agent with uncertain behavior on repeated calls and on an entire parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must explain parameters. It explains label (paid plan dependency) and retention_hours (optional, capped), but completely omits the `prefix` parameter. Without a description, an agent cannot know what prefix does. This is a significant gap for one of three parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the function ('Open an email inbox and return its address') and gives a specific use case ('when you need an address to sign up for a service or to receive a one-time code'). This sets it apart from sibling tools like list_inboxes or read_messages, which are about listing or reading, not creation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides explicit usage context ('Use this when you need an address to sign up for a service or to receive a one-time code'), but it does not mention when not to use it or name alternatives directly. The context is clear, but there are no exclusions or comparative routing.

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

• read_messagesA
  4.1/5.0
  Behavior3/5

  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 useful behavioral details: messages are returned newest-first and the default direction is 'in' for a specific reason. However, it does not clarify whether reading affects read state, what the response shape is, or whether there are any limits or pagination.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence earns its place: a short action-oriented first sentence, a parameter definition, and a rationale for the default. There is no redundant content or padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity read tool with only two parameters, the description has all the essential calling information: what to read, which inbox, ordering, and direction semantics. The main omission is what exactly is returned and whether there are any limits, but these were not be blocking for a basic read operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is only 0%, but the description compensates well. It fully explains the direction parameter with all three values ('in', 'out', 'all'), states the default, and explains the reasoning behind the default. The address parameter is also clear from the phrase 'given inbox address'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Read messages') and a specific resource ('the given inbox address'), plus the ordering ('newest first'). This is enough to distinguish read_messages from siblings like send_email, delete_message, or mark_read.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains the direction parameter and why the default is 'in' so that a sent message is not confused with an awaited reply. However, it does not explicitly say when to choose this tool over alternatives such as wait_for_message or list_inboxes; the guidance is implied rather than stated.

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

• wait_for_messageA
  4.1/5.0
  Behavior4/5

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

  Given no annotations are provided, the description carries the behavioral disclosure burden and does a generally good job. It discloses polling behavior, a timeout condition, and the critical filter that only received mail counts. It does not detail error behavior on timeout or side effects, but the core behavioral traits are conveyed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is only two sentences long, front-loads the main behavior, and each sentence adds genuine value. Decorations like 'ARRIVES' are minor and not harmful. There is no outdated not revenue data.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 2-parameter polling tool with no annotation or output schema, the description covers the main outcome: it polls, returns an email, waits until new mail arrives or times out, and filters out outgoing messages. The main gap is that the address parameter's relation to the inbox is left implicit, and timeout outcome is not fully specified.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description should compensate by explaining the parameters, but it only mentions 'timeout' in passing and never explicitly ties 'address' to the inbox being polled. It does not clarify timeout units, accepted formats, or what happens if the address is invalid. This leaves the agent with significant ambiguity for actually invoking the tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action, 'Poll the inbox until a new message ARRIVES', and adds 'or timeout' plus a returned result, which makes its function unmistakable. It also clarifies that only received mail is matched, differentiating it from waiting for outgoing messages or reading existing mail. This is more precise than the tool name alone.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a concrete use case: send to a peer and wait for their reply without matching your own outgoing message. This explains when the tool is intended to be used, but it does not explicitly name alternative siblings such as wait_for_otp, wait_until_sent, or read_messages, nor does it state when not to use them.

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

• burn_inboxA
  4.3/5.0
  Behavior4/5

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

  There are no annotations, so the description carries the behavioral transparency burden. It clearly discloses the destructive action (delete every message) and the preserved state (the address remains registered). It does not discuss reversibility or return values, but the key behavior is explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded. The core destructive action appears first, followed by the retention side-effect and usage timing. Every sentence adds value with no unnecessary padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with one required parameter, no output schema, and no nested structures, the description covers the essential facts: what is deleted, what is kept, and when it should be used. An agent has enough to invoke this correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, and the description only refers to 'the address' without formally explaining its format or origin. However, since the parameter is named 'address' and the text says it is the address already used in previous scenarios, the meaning is reasonably inferable for a single-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: 'Delete every message in an inbox but KEEP the address.' This is a specific verb and resource, and the emphasis on keeping the address distinguishes it from sibling tools like delete_message and delete_inbox.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says 'Use between scenarios', giving the agent a clear condition for when to invoke this tool. It does not explicitly name the alternative tools or state when not to use it, but the use case is clear enough from the scenario lifecycle context.

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

• send_emailA
  4.3/5.0
  Behavior5/5

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

  No annotations are present, so the description carries the full burden, and it delivers: it discloses accepted-vs-delivered asynchronous semantics, webhook or read-back completion, header visibility for cc, the guaranteed absence of bcc from headers, and the attachment limitation. This is unusually rich behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-ordered: primary action up front, then essential delivery semantics, then recipient visibility behavior, then the attachment limitation. Every sentence earns its place without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 7-parameter tool with no output schema and no annotations, the description provides enough about sending semantics, result timing, delivery confirmation, and parameter nuances. The missing detail on body and subject formatting is minor relative to the coverage provided.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has no parameter descriptions, and the description adds meaning to `address`, `html`, `cc`, and `bcc`, but `to`, `body`, and `subject` remain only name-implied. It compensates partially but does not fully document all seven parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a clear action and resource: sending an email from a specified inbox address, with DKIM signing mentioned. It positions the tool for replies and outbound automation but does not explicitly distinguish it from the sibling 'reply' tool, so it misses full sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when context with 'Use for replies or outbound automation' and points users to the SDK for attachments, which is a useful limitation. However, it does not explain when to prefer the sibling `reply` tool, so the guidance stops short of a full alternatives map.

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

• wait_until_sentA
  4.3/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral responsibility and handles it excellently. It discloses the async queue background, timeout semantics (timed_out does not mean failure), retry status states (`queued`, `retrying`, `failed`), error/message values, and the precaution to read `note` before resending. This fully covers the unusual and potentially dangerous behaviors of this tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively long but every sentence delivers legal behavior that would otherwise be invisible: timeout means retry is ongoing, failed is a hard failure, resending is forbidden. It is appropriately structured, beginning with a one-sentence summary and then expanding into details that are all essential. Slightly verbose for a tool description, but no sentence is wasted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool complexity (async delivery, timeout, retries, failure modes) and the absence of an output schema or annotations, the description does a lot of heavy lifting. It covers return values, flags, and error handling. The only real missing context is the meaning of `address` and a possible estimate or definition of timeout duration, which is significant enough to prevent a fully perfect score.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must compensate. It spells out that `message_id` is the ID returned by send_email, and timeout behavior is described through the “timeout elapses” line. However, the required `address` parameter is not explained and `timeout` is not explicitly defined in seconds or units, so there are still gaps in parameter understanding.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a clear action and resource: "Find out whether a mail you sent was actually delivered." It actively distinguishes this tool from send_email, stating that send_email only means "accepted for delivery," while this tool checks the actual outcome via the message_id. This makes the tool's unique role clear, especially in a sibling list full of email actions.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells when to invoke: after send_email returns a message_id, and it tells what to do if the message is still queued after timeout (do NOT resend). It also describes the persistent queue/rereadying behavior, which prevents a harmful resend action. It doesn't name alternative tools explicitly, but the separation from send_email is clear. A bit more explicit wording such as "use wait_for_message for incoming email" would have been stronger.

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