Server Quality Checklist

Tool Scores

• send_chat_messageA
  4/5.0
  Behavior5/5

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

  The description adds substantial behavior beyond the annotations: the message is handed to a background daemon, the call waits up to 15 seconds for delivery confirmation, and the message cannot be unsent because real people may read it immediately. This is exactly the type of context annotations alone do not provide.

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

  Conciseness5/5

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

  Three tight sentences convey the action, the precondition, the execution path, the timeout behavior, and the irreversibility. Every sentence earns its place, and the core action is front-loaded.

  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 tool, the description covers the key operational context: prerequisites, async handoff, delivery wait, and human impact. It does not describe the return value or failure behavior on timeout, which is a minor gap given there is no 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?

  Schema coverage is 100% and both required parameters are described in the schema. The description adds no new parameter-level detail beyond restating the allowlist/canPost condition already present in the jid schema description.

  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?

  The description clearly states the verb and resource: sends a text message to a chat, with the specific precondition that the chat must be allowlisted and have canPost enabled. It is clearly distinct from sibling tools like list_chats and read_chat_messages, but it does not explicitly name or contrast those alternatives.

  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 the tool by framing it as sending a message and requiring an allowlisted chat with canPost enabled. However, it does not explicitly state when to use this tool versus siblings, nor does it mention alternatives like read_chat_messages for reading conversations.

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

• poll_chatsA
  4.4/5.0
  Behavior4/5

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

  Annotations provided readOnlyHint=true, and the description adds valuable behavioral detail: it drains only new messages, groups them by chat jid, persists the read position, and guarantees each message is returned exactly once. This goes beyond the annotation without contradicting 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?

  Two sentences, no filler, with the core action and grouping front-loaded. The second sentence adds the important delivery guarantee without 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 no-parameter polling tool, the description covers purpose, grouping, and delivery semantics. It does not describe the exact response shape or empty-result behavior, but the absence of an output schema and simple tool complexity make this acceptable.

  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?

  Tool has zero parameters, so baseline is 4. Description confirms no input is needed and explains the semantics of the poll position, which is the only relevant 'parameter-like' state.

  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?

  Description uses a specific verb ('Drains') and resource ('messages that arrived since the last poll_chats call'), and specifies grouping by chat jid. It is clearly distinguishable from siblings list_chats, read_chat_messages, and send_chat_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?

  The description clearly establishes the polling pattern: it returns messages that arrived since the previous poll_chats call, and the persisted read position implies it is meant for repeated incremental fetching. It does not explicitly name alternatives or exclusions, but the usage context is clear.

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

• list_chatsA
  4.5/5.0
  Behavior4/5

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

  With readOnlyHint=true already covering the read-only nature, the description adds useful behavioral detail: the exact fields returned (including canPost) and a 'lightweight recent-activity count,' plus a guarantee about scope. This goes beyond the annotation without contradicting it. No side effects or caveats need disclosure for a read-only list 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 with no redundant words. The primary action and outcome come first, followed by a compact enumeration of returned fields. The final exclusion sentence earns its place by removing ambiguity about scope.

  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 parameterless read-only list operation, the description fully covers what an agent needs to know to call it correctly: what it returns (fields) and its scope (allowed chats only). No output schema exists, but the description compensates by naming all returned fields. Absent pagination or sorting requirements are not significant for such a lightweight operation.

  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 takes zero parameters and schema coverage is 100%, so there is no parameter information to add. The description does not need to explain inputs, and the baseline of 4 for a no-parameter tool 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 (Lists) and resource (WhatsApp chats this server may touch), and names the exact fields returned: jid, display name, canPost, and recent-activity count. The scope restriction 'Never lists any other chat' further distinguishes it from siblings like read_chat_messages or send_chat_message, which operate on individual chats.

  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 the tool: to discover which WhatsApp chats are available for interaction on this server. The phrase 'this server may touch' sets expectations about scoping, and 'Never lists any other chat' is an exclusion. However, it does not explicitly compare against sibling tools or state when not to use it, so it falls just short of a 5.

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

• read_chat_messagesA
  4.7/5.0
  Behavior5/5

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

  The description adds meaningful behavioral context beyond the readOnlyHint annotation: messages come from the local inbox log, are returned oldest first, and the tool works even when WhatsApp is unreachable. This is substantial, decision-relevant behavior that the agent could not infer from the schema or annotations alone.

  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 with no filler. The key operation and scope are front-loaded, and the behavioral caveat about the local log follows immediately.

  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 read-only tool with fully covered parameters, a readOnlyHint annotation, and no output schema, the description provides all essential context: what is read, from where, the ordering, and the offline capability. No critical information is missing.

  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?

  Schema coverage is 100%, so the baseline is 3, but the description adds value by clarifying that 'limit' means the last N messages and that output is ordered oldest first. This refines the semantics beyond the schema's simple 'Max messages, default 30' description.

  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: 'Reads the last N stored messages for one allowlisted chat, oldest first.' It also distinguishes itself from live-fetch tools by explicitly stating the messages come from the local inbox log, not a live WhatsApp fetch.

  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 clear context for when to use the tool: reading stored messages from the local log, and it explicitly notes this is not a live WhatsApp fetch, which implies it is not for live retrieval. It does not name sibling alternatives directly, but the behavioral distinction is enough.

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