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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about default values (e.g., 'after' defaults to 24h ago) and constraints (e.g., 'limit' max 200), which are behavioral traits not covered by annotations. However, it doesn't mention pagination, rate limits, or authentication needs.

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 well-structured with a clear purpose statement followed by a bullet-point list of parameters. Every sentence earns its place by providing essential information without redundancy. It's appropriately sized and front-loaded with the core functionality.

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

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

Given the tool's complexity (5 parameters, 0% schema coverage) and the presence of annotations and an output schema, the description is mostly complete. It covers key usage aspects and parameter semantics. However, it could benefit from more explicit guidance on when to use versus siblings, and some behavioral details like pagination are missing.

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 0%, so the description carries the full burden. It effectively explains all 5 parameters: chat_jid (with sources), after/before (datetime format and defaults), limit (max constraint), and search_text (optional filtering). This adds significant meaning beyond the bare schema, though it could detail JID format or ISO 8601 examples.

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 verb 'Get' and resource 'messages from a specific WhatsApp chat', which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'whatsapp_search_messages' or 'whatsapp_unread', which likely have overlapping functionality.

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 by specifying 'from a specific WhatsApp chat' and references sibling tools for obtaining the chat_jid, but it doesn't explicitly state when to use this tool versus alternatives like 'whatsapp_search_messages'. The context is clear but lacks explicit comparison 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the real-time nature and source (live connection vs. database), which goes beyond the annotations. However, it doesn't describe behavioral aspects like rate limits, authentication requirements, or response format, leaving room for improvement.

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 efficiently structured: a clear purpose statement, context about real-time vs. database, usage guidance, and parameter details in a labeled 'Args' section. Every sentence adds value without redundancy, and it's front-loaded with the core functionality. No wasted words or 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?

Given the tool's moderate complexity (one parameter, read-only operation), the description is quite complete. It covers purpose, usage, and parameter semantics effectively. Since there's an output schema (per context signals), the description doesn't need to explain return values. However, it could improve by mentioning sibling tools or potential errors, keeping it from a perfect score.

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

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

The schema has 0% description coverage, so the description carries the full burden. It explains the 'since_minutes' parameter clearly: 'Look back N minutes (default 5, max 60).' This adds essential semantics beyond the schema's basic type and title. With only one parameter well-documented, it compensates adequately for the schema gap, though a perfect score would require more detail on constraints or examples.

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 tool's purpose: 'Get recent incoming WhatsApp messages from the live connection.' It specifies the resource (WhatsApp messages) and verb (get), and distinguishes it from database-stored messages. However, it doesn't explicitly differentiate from sibling tools like 'whatsapp_get_messages' or 'whatsapp_search_messages', which prevents a perfect score.

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

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

The description provides clear usage context: 'These are real-time messages, not from the local database. Useful for checking new messages that just arrived.' This tells the agent when to use this tool (for real-time, recent messages) versus alternatives that might access stored data. However, it doesn't explicitly name alternative tools or specify when NOT to use it, keeping it from a score of 5.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful behavioral context about ordering ('ordered by last message time') and filtering capabilities, but doesn't mention pagination, rate limits, or authentication requirements. With annotations covering safety, this adds moderate value.

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 efficiently structured with a clear purpose statement followed by parameter explanations in a bullet-like format. Every sentence adds value without redundancy, and it's appropriately sized for a simple list 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?

Given the tool's low complexity (2 simple parameters), rich annotations (readOnlyHint, destructiveHint), and existence of an output schema, the description is reasonably complete. It covers purpose and parameters adequately, though it could benefit from more explicit usage guidance relative to 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 0%, so the description carries full burden. It clearly explains both parameters: 'limit' specifies number of chats with a max constraint, and 'chat_type' defines filter options with enum values. This adds meaningful semantics beyond the bare schema, though it doesn't cover default values or format details.

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 specific action ('List recent WhatsApp chats') and resource ('WhatsApp chats'), with explicit ordering ('ordered by last message time'). It distinguishes from siblings like whatsapp_search_contacts or whatsapp_get_messages by focusing on chat listing rather than contact search or message retrieval.

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 retrieving chat lists but provides no explicit guidance on when to use this tool versus alternatives like whatsapp_search_contacts or whatsapp_get_messages. No exclusions or prerequisites are mentioned, leaving usage context 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds valuable behavioral context beyond annotations: it specifies that partial matching is supported and describes the return format (JID, display name, phone number). However, it doesn't mention rate limits or authentication requirements, leaving some behavioral aspects uncovered.

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 efficiently structured with a purpose statement, return value explanation, usage guideline, and parameter details in four concise sentences. Every sentence adds value without redundancy, and key information is front-loaded for quick comprehension.

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

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

Given the tool's simplicity (1 parameter, read-only operation), the description is complete: it covers purpose, usage, return values, and parameter semantics. With an output schema present, the description appropriately focuses on context rather than return value details, making it fully adequate for agent decision-making.

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?

With 0% schema description coverage, the description fully compensates by explaining the 'query' parameter's purpose ('Name or phone number to search for') and behavior ('partial match supported'). This adds essential meaning beyond the bare schema, though it doesn't detail format constraints like phone number patterns.

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 tool's purpose with a specific verb ('Search') and resource ('WhatsApp contacts'), and distinguishes it from siblings like 'whatsapp_search_messages' by focusing on contacts rather than messages. It explicitly mentions searching by name or phone number, providing clear differentiation.

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 explicitly states when to use this tool: 'Use this to find a contact before reading their messages or sending them a message.' This provides clear guidance on its purpose relative to siblings like 'whatsapp_get_messages' and 'whatsapp_send', making it easy for an agent to choose this tool appropriately.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds useful behavioral context beyond annotations: it specifies that the search is case-insensitive and has a max limit of 50 results. However, it does not disclose other potential traits like rate limits, authentication needs, or pagination behavior.

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 appropriately sized and front-loaded: the first sentence states the core purpose clearly, followed by a structured Args section that efficiently explains each parameter without unnecessary details. Every sentence earns its place, and there is no wasted text.

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

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

Given the tool's moderate complexity (search with filtering), annotations cover safety, and an output schema exists (so return values need not be explained), the description is mostly complete. It covers purpose, parameters, and key behavioral aspects like case-insensitivity and limits. However, it lacks explicit guidance on alternatives or error handling, leaving minor gaps.

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 0%, so the description carries the full burden. It adds meaningful semantics for all three parameters: query is described as 'Text to search for (case-insensitive)', chat_jid as 'Optional - restrict search to a specific chat', and limit as 'Max results (max 50)' with a default implied. This compensates well for the lack of schema descriptions.

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 specific action ('Search for messages containing specific text') and resource ('across all chats'), distinguishing it from siblings like whatsapp_get_messages (which likely retrieves messages without searching) and whatsapp_search_contacts (which searches contacts instead of messages). It explicitly mentions the scope 'across all chats' unless restricted by chat_jid.

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

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

The description provides clear context for usage by specifying that searches can be across all chats or restricted to a specific chat using chat_jid. However, it does not explicitly state when to use this tool versus alternatives like whatsapp_get_messages or whatsapp_search_contacts, nor does it mention exclusions (e.g., when not to use it).

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, confirming this is a write operation but not destructive. The description adds valuable context beyond annotations: it requires WhatsApp connectivity (via whatsapp_status), needs a JID from another tool, and mandates user confirmation. No contradiction with annotations exists.

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 well-structured and front-loaded: the core purpose is stated first, followed by a clear IMPORTANT section with bullet points, then parameter explanations. Every sentence earns its place with no wasted words.

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

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

Given the tool has an output schema (which handles return values), annotations covering safety, and the description providing thorough usage guidelines and parameter semantics, this is complete for a messaging tool. It addresses prerequisites, user confirmation, and parameter sourcing effectively.

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?

With 0% schema description coverage, the description compensates by explaining both parameters: recipient_jid is 'The JID from whatsapp_search_contacts' and message is 'The text message to send.' This adds essential meaning beyond the bare schema, though it could specify JID format or message length limits.

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 specific action ('Send a WhatsApp message') and resource ('WhatsApp'), distinguishing it from siblings like whatsapp_get_messages (retrieval) or whatsapp_status (connection check). The verb 'send' is precise 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?

The description explicitly provides when-to-use guidance in the IMPORTANT section: first use whatsapp_status to ensure connectivity, then use whatsapp_search_contacts to get the JID, and always confirm with the user. It names specific alternative tools (whatsapp_status, whatsapp_search_contacts) for prerequisites.

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?

Annotations already indicate read-only and non-destructive behavior, but the description adds valuable context beyond that: it specifies the exact status values returned ('connected', 'qr_pending', etc.) and explains that if a QR code is needed, it returns a data URL for browser scanning. This provides practical behavioral details not covered by annotations.

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

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

The description is efficiently structured in three short paragraphs: first states the purpose, second details the return values, third provides usage guidance. Every sentence earns its place with no wasted words, and key information is front-loaded.

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

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

Given the tool's simplicity (0 parameters, annotations present, output schema exists), the description is complete: it explains what the tool does, what it returns, and when to use it. The output schema likely covers return values, so the description doesn't need to duplicate that, making this well-rounded for the context.

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?

With 0 parameters and 100% schema description coverage, the baseline is 4. The description appropriately doesn't discuss parameters, as none exist, and instead focuses on the tool's output and usage context, which adds semantic value without redundancy.

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 tool's purpose with a specific verb ('Check') and resource ('WhatsApp connection status'), distinguishing it from sibling tools that handle messaging, chats, contacts, etc. It explicitly defines what it does rather than just restating the name.

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

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

The description provides explicit guidance on when to use this tool: 'Call this before sending messages to ensure WhatsApp is connected.' This directly contrasts with sibling tools like 'whatsapp_send' and gives a clear prerequisite context for usage.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about the return format ('chats with unread messages and recent message previews'), but doesn't specify behavioral details like whether it includes archived chats, group vs. individual chats, or pagination. With annotations covering safety, a 3 is appropriate—the description adds some value but not rich 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.

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

The description is front-loaded with the core purpose in the first sentence, followed by return details and usage examples in two additional concise sentences. Every sentence adds value without repetition or fluff, making it efficient and well-structured.

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

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

Given the tool's simplicity (0 parameters, read-only operation), annotations covering safety, and the presence of an output schema (which handles return value documentation), the description is complete. It clearly states the purpose, usage context, and return format, leaving no gaps for an AI agent to understand and invoke the tool correctly.

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?

There are 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate. Baseline for 0 parameters is 4, as it avoids unnecessary clutter while being complete for this tool's structure.

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 specific action ('Get a summary') and resource ('all unread WhatsApp messages'), distinguishing it from siblings like 'whatsapp_get_messages' (general message retrieval) and 'whatsapp_list_chats' (listing chats regardless of read status). The phrase 'chats with unread messages and recent message previews' further clarifies the scope.

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 explicitly provides usage guidance with examples ('Great for "catch me up" or "what did I miss" requests'), indicating this tool is for catching up on missed activity rather than general message browsing or sending. This helps differentiate it from alternatives like 'whatsapp_get_messages' or 'whatsapp_send'.

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