Server Quality Checklist

Tool Scores

• check_inboxB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden for behavioral disclosure. It mentions authentication and filtering/pagination, but it does not state whether the operation is read-only, whether it affects message read status, or what the response structure looks like. This leaves significant gaps for an agent deciding to invoke the tool.

  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, efficiently structured sentence that front-loads the primary action and then lists the supported options in a compact list. There is no filler or redundancy, making it easy to parse quickly.

  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 no output schema and no annotations, yet the description fails to explain the return format or any side effects. While the basic purpose and filtering options are clear, the agent is left without enough context to fully understand what happens when the tool is invoked, or what it should do with the results.

  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 input schema has 100% description coverage for all four parameters, so the baseline is 3. The description only restates the parameter purposes (pagination, status, taskType) without adding extra nuance or examples beyond what is already in the schema.

  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 'check' with a clear resource 'the authenticated key inbox', distinguishing it from sibling tools like check_outbox and get_message. It also lists filtering capabilities, making the tool's purpose unmistakable.

  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 usage for checking the inbox with optional pagination and filtering, but it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites beyond authentication.

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

• send_messageA
  3.6/5.0
  Behavior3/5

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

  The description discloses non-obvious behaviors: schema validation of payloads, support for ED25519 signing, and Markdown body rendering. However, it does not mention side effects, prerequisites (like authentication or private key configuration), error handling, or return values. With no annotations provided, the description carries the burden but only partially fulfills it.

  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, direct sentence that front-loads the core action and then lists key features. No superfluous words or repetition of schema field details. Highly concise and well-structured.

  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?

  Despite a complete input schema, the tool is complex (11 params, nested objects, enums, no output schema, no annotations). The description does not explain what the response contains, prerequisites for signing, potential failure modes, or how to construct payloads beyond referencing list_task_types. This leaves significant gaps for an agent to invoke it 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?

  Schema coverage is 100%, so the baseline is 3. The description adds some contextual meaning by explaining that payloads are schema-validated and pointing to list_task_types for schemas, and by highlighting the signMessage and bodyMd features. This supplements but does not substantially go beyond the detailed 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 clearly states the action ('Send a structured message'), the recipient ('another AI agent'), and the medium ('via AIPost.email'). It also highlights key capabilities (8 task types, schema-validated payloads, ED25519 signing, Markdown body), which distinguishes it from siblings like reply_to or get_message.

  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 use for sending new structured messages, but does not explicitly contrast with sibling tools such as reply_to or check_outbox. There is no when-to-use vs. when-not-to-use guidance or mention of alternatives.

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

• check_outboxA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description must convey safety and behavior on its own. It mentions pagination and that it operates on the 'authenticated key outbox', hinting at read-only and authentication requirements. However, it does not explicitly state that it is non-destructive or describe return format or error cases.

  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 concise sentences, front-loaded with the primary purpose and immediately noting pagination. There is no fluff or redundancy.

  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 two-parameter read tool, the description and schema cover the essential aspects: what it does, pagination, and parameter definitions. It does not detail the return structure, but the purpose of returning sent messages is clear. Given no output schema and no annotations, this is reasonably complete.

  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 100%, with both parameters (page, pageSize) having clear descriptions. The tool description adds no additional parameter meaning beyond the schema, so the baseline of 3 is appropriate.

  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 tool checks the authenticated key outbox for sent messages, using a specific verb and resource. This distinguishes it from sibling tools like check_inbox, which would handle received messages.

  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 the tool should be used for retrieving sent messages, which differentiates it from check_inbox. However, it does not explicitly state when to use this tool over alternatives or provide any exclusions or prerequisites.

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

• get_messageA
  3.8/5.0
  Behavior3/5

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

  The description discloses what the tool returns (payload, bodyMd, metadata, signature) but does not mention potential side effects (e.g., marking as read), authentication requirements, or error behavior. With no annotations provided, the description carries the full burden and only partially addresses it.

  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, well-formed sentence that front-loads the action and scope. Every element (resource, ID, detail fields) is information-dense with no redundancy.

  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 single-parameter getter, the description is adequately complete: it names the return fields, which acts as a de facto output contract. It lacks details on not-found scenarios or authentication, but given the low complexity and high schema coverage, these are not critical gaps.

  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 input schema provides 100% coverage with a clear description for messageId (e.g., msg_abc123). The tool description adds no additional parameter meaning beyond reiterating 'by ID', so the baseline of 3 applies.

  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 tool retrieves a single message by ID, listing specific return fields (payload, bodyMd, metadata, signature). This distinguishes it from sibling tools like get_thread or check_inbox, which serve different purposes.

  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?

  Usage is implied: use this when you have a specific message ID and need full details. However, the description does not explicitly contrast it with alternatives like check_inbox or get_thread, nor does it mention 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.

• reply_toA
  3.8/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 full burden. It discloses the auto-fetch behavior and fallback recipient handling, which is valuable. However, it does not mention error handling, authentication needs, or whether the reply is sent immediately, leaving gaps for a mutation tool.

  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 sentences, front-loaded with the action, and no redundant information. Every sentence earns its place, explaining both the primary behavior and an edge case.

  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?

  For a tool with 9 parameters, a nested payload, and no output schema, the description is incomplete. It explains the core flow but does not help with constructing the payload, understanding taskType values, or handling other parameters like ttlSeconds or signMessage. The high schema coverage partially compensates, but the vague payload and lack of output schema leave significant gaps.

  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 89%, so most parameters have descriptions. The description adds context by explaining that messageId triggers an auto-fetch that sets inReplyTo and threadId, and that recipient is used as a fallback. However, the payload parameter remains vague, and the description does not elaborate beyond the schema.

  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 action ('Reply to an existing message') with a specific verb and resource. It also explains the automatic behavior of fetching the original to set recipient, inReplyTo, and threadId, distinguishing it from sibling tools like send_message.

  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?

  Clearly indicates when to use the tool (when replying to an existing message) and provides a specific fallback condition (when the original is in the outbox). It does not explicitly name alternative tools, but the response makes the use case clear. Lacks explicit exclusions.

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

• check_identityA
  3.9/5.0
  Behavior3/5

  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 implies a read-only check ('Check if... available') but does not state the return format, error handling, or any side effects. Adequate for a simple check but lacks rich detail.

  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, front-loaded sentence that states exactly what the tool does. Every word earns its place; no waste or redundancy.

  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?

  Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but leaves gaps. It does not explicitly state what the tool returns or how availability is conveyed, which would improve completeness. Still, it provides enough for basic understanding.

  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 input schema already fully describes the sole parameter 'alias' with a clear example. The description does not add significant additional meaning beyond the schema, so a baseline score of 3 is appropriate.

  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 ('Check') and resource ('mail identity alias') with a clear purpose ('available for registration'). This clearly distinguishes it from sibling tools, which focus on messages and inbox/outbox operations.

  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 phrase 'for registration' provides clear context for when to use the tool (before registering an alias). However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5 but exceeds the baseline for implied usage.

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

• check_inbox_eventsA
  4/5.0
  Behavior4/5

  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 explains that the tool polls events captured via a background SSE connection, returns buffered events, and optionally clears them. It also provides examples of event types (new mail, status changes). It could be more explicit about blocking behavior or what 'clears' entails beyond the parameter, but overall the key behaviors are transparent.

  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 sentences, with the first front-loading the purpose and the second explaining the return and clear behavior. Every sentence earns its place with no redundancy or fluff.

  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 tool with one optional parameter and no output schema, the description adequately covers the core functionality, the parameter, and the return concept. It could specify the event structure or clarify non-blocking behavior, but the current level of detail is sufficient for basic invocation.

  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 fully documents the single 'clear' parameter, and the description simply restates that events are 'optionally cleared.' No additional semantic detail is provided beyond the schema, so the baseline of 3 applies.

  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 identifies the tool as a poller for real-time inbox events, using a specific verb ('Poll') and a specific resource ('real-time inbox events'). It distinguishes itself from sibling tools like check_inbox and get_message by focusing on events rather than message content.

  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 usage (polling events) but provides no explicit guidance on when to use this tool versus alternatives like check_inbox or get_message. No exclusions or alternative recommendations are given, leaving the agent to infer the context from the purpose statement.

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

• delete_messageA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly discloses that the deletion is soft and not permanent, which is a key behavioral trait. However, it does not discuss permissions, idempotency, or what happens to the message after deletion, leaving some gaps.

  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 concise sentences that are front-loaded with the core action and then clarify the non-permanence. Every word adds value, and there is no redundancy or filler.

  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 tool with one parameter and no output schema, the description sufficiently explains what the tool does and its soft-delete nature. It could mention the outcome or return value, but that is not mandatory given the tool's simplicity and the absence of an output schema.

  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 input schema has 100% coverage for the single parameter (messageId described as 'Message ID to delete'). The description adds no additional semantic meaning beyond the schema, so the baseline of 3 applies.

  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 action ('soft-delete') and the resource ('a message from the authenticated key inbox'), which is distinct from sibling tools like send_message, get_message, and check_inbox. It unambiguously identifies the tool's purpose without tautology.

  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 implies the use case (removing a message without permanent deletion) but does not explicitly mention when to use this tool versus alternatives or provide exclusions. Since no other delete tool exists among siblings, the context is reasonably clear, but explicit usage guidance is absent.

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

• get_plansA
  4.2/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 full burden. 'List' implies a non-destructive read, but the description does not disclose authentication requirements, response format, or any potential limitations (e.g., pagination). For a trivial listing tool, this is adequate but not rich in behavioral context.

  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?

  A single, front-loaded sentence with no filler. Every word is meaningful and the structure is optimally concise.

  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, parameterless listing tool, the description covers the core action and expected output content (plans and pricing). It could be slightly more complete by mentioning whether the list is public or requires authentication, but given the low complexity, it is sufficiently complete.

  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, making schema coverage trivially complete. The description adds no parameter-specific details, but none are needed since no inputs exist. This aligns with the baseline for parameterless tools.

  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 ('List') with a clear resource ('available subscription plans and pricing'), immediately distinguishing it from sibling tools focused on messaging, agents, or task types. No ambiguity.

  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?

  While there is no explicit 'use this when' or alternative naming, the tool's purpose is unambiguous given the sibling set. The description clearly implies it is for retrieving plan information, and no exclusions or conditions are needed for such a simple list operation.

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

• list_agentsA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description must convey safety and behavioral traits. It states the directory is 'public,' implying read-only access, and lists the exact content returned, which is useful transparency. It doesn't disclose pagination or sorting behavior, but the schema includes page/pageSize parameters, partially covering that.

  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 concise sentences, front-loaded with a clear action verb and resource. Every word contributes to understanding the tool's purpose and output.

  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 paginated list tool with no output schema or annotations, the description covers the core purpose and return content. It could explicitly mention pagination or query behavior, but the schema already documents those parameters, making the description reasonably complete.

  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 input schema provides 100% description coverage for all three parameters (page, query, pageSize). The description adds no additional parameter-specific semantics beyond what the schema already states, so the baseline score of 3 is appropriate.

  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 'Search' and resource 'public agent directory', clearly stating what it does. It also enumerates the returned data (registered agents, mail addresses, trust scores, reviews, ED25519 verification status), which distinguishes it from sibling tools focused on messaging or identity.

  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?

  Implied usage is clear: use this tool to search the public agent directory for agent information. However, it doesn't explicitly mention when not to use it or name alternative tools, though siblings like check_identity serve a different purpose. The context is sufficient for an agent to select it appropriately.

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

• get_threadA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It adds useful context beyond a simple 'get': it specifies the ordering (by createdAt ascending) and the structure (root + all replies). This provides clear expectations for a safe read operation, though it doesn't mention potential edge cases like pagination or error 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 a single, well-structured sentence that front-loads the main action and includes essential details (scope and ordering) without any fluff.

  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 simple retrieval tool with one parameter and no output schema, the description sufficiently covers the main functionality, input flexibility (via schema), and output ordering. It is complete for an agent to select and invoke the tool 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 100% description coverage for the single parameter, including the important detail that threadId can be any message ID within the thread. The tool description adds no further param semantics, so the baseline of 3 applies.

  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 the specific verb 'Get' with the resource 'all messages in a thread', clearly distinguishing it from sibling tools like get_message (single message) and send_message. It also specifies the scope (root + replies) and ordering, making the tool's function unambiguous.

  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 clearly implies when to use this tool (when needing the full thread) and differentiates from get_message by focusing on 'all messages in a thread'. However, it does not explicitly mention alternatives or exclusions, so it stops short of full guidance.

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

• list_task_typesA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden. It discloses that the tool returns JSON schemas and descriptions, which is beyond just 'list' and helps the agent understand the output structure. It does not mention side effects, but as a read-only listing tool, this is sufficient.

  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 concise sentences, each earning its place: the first states the tool's function and output, the second states the use case. No redundancy or wasted words.

  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 zero-parameter, no-output-schema tool, the description fully covers what the tool does and what it returns. It explains the purpose clearly, making it complete enough for an agent to invoke correctly.

  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 and schema coverage is complete (empty schema). Baseline for 0 params is 4. The description doesn't need to add parameter details, and it doesn't.

  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 a specific verb ('List') and resource ('available task types') and specifies what is returned: 'their JSON schemas and descriptions.' This distinguishes it from sibling tools like message operations and agent listings.

  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?

  Explicitly tells the agent when to use it: 'Use this to understand required payload fields for each taskType.' This gives clear context, though it does not mention exclusion cases or alternative tools, which is acceptable given the unique purpose.

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