whatsapp

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 does disclose what information is returned (auth status, store size, last sync, plan, allowance), which is useful. However, it does not state whether this is a read-only operation, whether it makes network calls, or whether it could be slow or fail if the account is disconnected. The description is honest but incomplete on behavioral traits.

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

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

The description is a single, compact sentence that front-loads the core purpose ('Health of the linked WhatsApp account') and then lists the specific data points. Every word earns its place; no filler or repetition.

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

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

For a parameterless status tool with no output schema, the description covers the key return values well. It is missing a note on whether the operation is read-only or could have side effects, but given the tool's simple nature and the absence of parameters, the description is largely complete 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.

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

The tool has zero parameters, so the schema provides no parameter semantics to clarify. The description compensates by explaining what the tool reports, which is the relevant semantic content for a parameterless status tool. Baseline 4 for zero params is appropriate.

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

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

The description clearly states the tool reports on the health of the linked WhatsApp account, listing specific attributes (authentication, store size, last sync, plan, request allowance). This distinguishes it from sibling tools that operate on chats, groups, messages, or media. It could be slightly stronger by explicitly naming it as a status/read-only check, but the verb 'Health of' implies assessment.

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 this is a diagnostic/status tool to check account health and usage allowance, but it does not explicitly state when to use it versus alternatives. Given the sibling list contains no other account-level status tool, the usage context is reasonably clear, but there is no explicit guidance on when to prefer this over other tools.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It implies a read-only operation through 'Details' and enumerates the returned fields, but it does not explicitly state that no state changes occur, nor mention error cases or access requirements. For a simple getter this is a moderate but not severe gap.

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

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

The description is a single sentence that front-loads the resource and then lists the relevant fields. There is no filler or redundant wording.

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

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

For a one-parameter getter with no output schema, the description provides enough context about what is returned and makes the resource clear. Minor omissions like error behavior or auth requirements are not critical for this low-complexity read operation.

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 already fully describes the single parameter ('chat': 'Chat JID.'), so the description adds no extra parameter semantics. With 100% schema description coverage, the baseline of 3 applies.

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

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

The description clearly identifies the resource ('a single chat') and the kind of data returned (name, kind, unread count, mute and pin state). It does not explicitly contrast with sibling tools like list_chats or get_group, but 'single chat' communicates the scope well.

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 phrase 'Details of a single chat' implies the tool is for fetching one specific chat rather than listing chats, but there is no explicit guidance on when to choose get_chat over list_chats or get_group, nor any exclusions. This is implied usage rather than stated guidance.

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

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

With no annotations, the description carries the full burden. It discloses the return content but does not explicitly state it's a read-only operation, error conditions, or any side effects. For a simple get, this is minimal but acceptable.

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?

One concise sentence with no fluff. It front-loads the returned fields and scope, making it easy to scan.

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

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

For a simple read tool with one parameter and no output schema, the description adequately conveys what the agent needs to know: what it returns and that it targets a single group. Missing details like error handling are not critical for this simple use case.

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 fully documents the single parameter (group JID format), so the description adds no additional parameter meaning. Baseline of 3 applies since schema coverage is 100%.

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 resource (one group) and the specific fields returned (subject, description, participants, admins). It distinguishes from list_groups by specifying 'one group,' though it lacks an explicit verb like 'get' or 'retrieve.'

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

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

No guidance on when to use this tool versus alternatives like list_groups or get_chat. It doesn't mention conditions or exclusions, leaving the agent to infer usage from the name and description.

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

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

No annotations are provided, so the description carries the behavior burden. It does disclose the key behavioral distinction: images come back as images while other media types return metadata. It does not mention side effects, errors when no media exists, or access requirements, but the core behavior is clear enough for a read-style retrieval.

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

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

Two concise sentences with no filler. The primary action and result type are front-loaded, and the media-type distinction is stated efficiently.

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

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

For a tool with only two required simple parameters and no output schema, the description covers the purpose, inputs, and return behavior well. It could note what happens when the message has no media, but the provided information is sufficient for correct invocation in most cases.

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

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

Schema coverage is 100%, and both parameters are simple and clearly described in the schema itself: chat is the Chat JID and message_id is the message holding the media. The description adds no extra parameter nuance, which is acceptable given the straightforward inputs.

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

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

The description states a specific action and resource: 'Download the image attached to a message and return it.' It also crisply clarifies the return behavior for images versus other media types, which distinguishes it from siblings like get_message_context or list_messages.

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 when to use the tool: when you need media directly from a specific message. However, it gives no explicit guidance about alternatives or when not to use it, so the agent must infer the choice from the tool name and sibling names.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description only says it provides surrounding messages, but does not state whether it modifies state (it is likely a read, but not stated), whether it can fail (e.g., message not found), or any rate limits. It also does not mention the 'after' and 'before' parameters, which directly control the number of surrounding messages. This is a significant gap for a tool that expects to be called after search_messages.

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

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

The description is a single, concise sentence that gets straight to the point. It is front-loaded with the core purpose and immediately provides usage guidance. 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's moderate complexity (4 parameters, 2 optional with defaults), the description is incomplete. It does not explain the meaning of 'before' and 'after' (likely counts of messages) or their bounds. It does not describe the return format, which is important for an agent to know if it can use the response. No annotations or output schema exist to fill these gaps. The description is too short for an agent to confidently invoke it without guessing parameter semantics.

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 description coverage is 50%, meaning the 'chat' and 'message_id' parameters are already described in the schema. The description does not add any details for these parameters. It does not explain 'after' and 'before' parameters, which are not described in the schema. With 50% coverage, the description should compensate for the undocumented parameters but fails to do so. Baseline is 3, and it remains there because it does not add value beyond the schema.

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

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

The description clearly states the tool's purpose: fetching surrounding messages for a given message id. It specifies a distinct resource ('messages surrounding one message id') and differentiates it from sibling tools like search_messages by implying it is a follow-up to search results. It does not explicitly name the sibling it is not, so it loses a point against the highest standard.

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: after search_messages, to see what a hit was answering. This provides clear context of its place in a workflow. However, it does not mention alternatives or when not to use it, so it is not quite a 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It explains the tool's purpose but does not disclose output format, side effects (or lack thereof), error handling, pagination, or any limitations. This is a significant gap for an agent deciding whether and how to invoke it.

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

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

Two sentences, zero fluff, and the core purpose is front-loaded. The description is efficient and earns every word, with no redundant or tangential content.

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 absence of an output schema and annotations, the description is incomplete. It does not specify what the tool returns (e.g., a timestamp, a boolean, a list), how parameters affect results, or any behavioral nuances. An agent would have to infer too much to use it 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?

The description adds no parameter-level information. The schema describes 'chat' and 'query' but leaves 'limit' unexplained (67% coverage). The description does not compensate for the missing 'limit' semantics, nor does it clarify how the parameters relate to the coverage check. Baseline is not reached because coverage is below 80% and the description offers no parameter guidance.

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 what the tool does: it reports how far back synced history reaches per chat, and it frames this as a way to answer whether a conversation exists before searching. It distinguishes itself from sibling search/list tools by focusing on coverage depth, though it could be more explicit about the exact output (e.g., a date or boolean).

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

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

The description gives a clear use case: use this tool to check if you even have the conversation before searching it. This implies a pre-check step and tells the agent when to use it, but it does not explicitly name alternative tools or state 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only describes the output content and does not mention filtering behavior, ordering, pagination, default limit, read-only characteristics, or what happens when no matching calls exist.

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

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

The description is a single compact sentence with no fluff and the main noun phrase is front-loaded. It loses a point only because the brevity leaves out important behavioral and parameter context.

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

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

For a call listing tool with four parameters, no annotations, and no output schema, the description is incomplete. It communicates what data comes back but not how to invoke filtering options, what each parameter means, or any pagination behavior.

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 only 25%, with only 'after' documented. The description does not explain 'chat', 'before', or 'limit' at all, and the mention of caller and time refers to output fields rather than input parameters. This fails to compensate for the sparse schema.

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

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

The description identifies the resource as 'call events' and lists the key output fields: who called, when, and answered/missed status. The title supplies the 'List' verb徙, and the subject matter distinguishes it from message- and chat-focused siblings, though an explicit 'Lists call events' phrasing would have been stronger.

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

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

There is no guidance on when to use this tool versus alternatives such as list_messages or list_chats. It does not explain whether the chat/before/after parameters are filters, how the default limit applies, or any prerequisites for getting useful results.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose the sort order ('newest activity first') and scoping to the linked account, which is useful. However, it does not mention what fields are returned, pagination behavior, or account/session requirements.

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

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

The description is a single compact sentence with no filler. It front-loads the core action and resource, then adds the two most important qualifiers: account scope and ordering.

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

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

The tool is simple and all parameters are documented, but there is no output schema and no annotations. The description does not state what a chat object contains, how pagination works beyond limit, or how the linked account is determined. Enough for basic use, but with 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 100%, so all three parameters already have meaningful descriptions. The tool description adds no parameter-specific semantics beyond what the schema provides, 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.

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

The description clearly states the verb 'List' and the resource 'chats', and adds scope ('of the linked account') and ordering ('newest activity first'). It distinguishes the tool by resource name, though it does not explicitly call out sibling tools like list_groups or list_messages.

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

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

The description gives no guidance on when to prefer this tool over alternatives. There is no mention of list_groups, list_messages, or search tools, nor any exclusion criteria. The filtered-list intent is only implied by the parameter names, not stated in the description.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the resource is, not how the tool behaves—no mention of pagination, sorting, rate limits, or return format. This is a significant gap for a tool that returns a list.

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 extremely brief and contains no filler. It is front-loaded with the core information, but it is so sparse that it sacrifices necessary detail. Conciseness alone is good, but it borders on under-specification.

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

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

For a simple tool with two optional parameters and no output schema, the description is incomplete. It does not mention pagination, sorting, or the shape of the response. An agent would have to infer most behavior, making this insufficient for reliable invocation.

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

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

Schema coverage is 50% (query has a description, limit has constraints). The tool description adds no information about parameters or how they affect results. It does not compensate for the missing description of limit or explain how query filters work beyond the schema.

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

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

The description 'Groups the account belongs to' is a noun phrase that identifies the resource and scope but lacks an explicit verb. It does not clearly say 'list' or 'retrieve', and it does not distinguish from sibling tools like get_group or other list_* tools. It adds some context (account ownership) but remains vague.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention get_group for a single group, nor does it contrast with list_chats or list_messages. No exclusions or conditional usage is provided.

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

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

With no annotations, the description carries the full burden for behavioral disclosure. It only reveals scope and ordering; it does not mention default limit, pagination, return shape, permissions, or how time/filter parameters affect results.

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

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

The description is a single front-loaded sentence with no filler, stating scope and ordering efficiently. It is compact, though arguably too sparse for a tool with five optional parameters and no annotations.

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

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

For a tool with five optional parameters, no annotations, no output schema, and relevant siblings, the description is incomplete. It leaves out return format, pagination defaults, and the distinction between simple listing and searching or contextual retrieval.

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

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

Schema coverage is high at 80%, with descriptions for chat, after, before, and from_me, plus limit constraints. The description adds little beyond reinforcing the chat parameter, so the schema appropriately carries the parameter semantics.

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

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

The description states a specific verb and resource: list messages, scoped to one chat or all chats, with newest-first ordering. It is clear and distinguishable in intent, though it does not explicitly contrast with siblings like search_messages or get_message_context.

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 tool's purpose is implied, but there is no guidance on when to choose this over search_messages, list_starred, or get_message_context. No exclusions, prerequisites, or alternative routing are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the tool supports pagination, what the default limit is, whether results are sorted, or any other behavioral traits. The description only describes the concept of starred messages, not the tool's behavior. This is a significant gap for a tool with no structured 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 a single sentence and is concise, but it is not front-loaded with the action or purpose. It reads more like a definition of the data than a description of the operation. It earns its place in terms of length, but the content is not optimally structured for an agent scanning for purpose.

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 (2 parameters, no output schema, no annotations), the description is still incomplete. It does not state what the return value is, whether results are ordered, or how pagination works. The 'limit' parameter hints at pagination but the description is silent. An agent would need to inspect the schema and make assumptions to use this 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?

Schema description coverage is 50% — only 'chat' has a description. The description text adds no information about either parameter. It does not explain what 'limit' controls, nor does it clarify the format or semantics of 'chat' beyond the schema's 'Restrict to one chat JID.' With moderate coverage and no additional description, the tool fails to add value beyond the schema.

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

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

The description identifies the resource (starred messages) but lacks a clear verb. The title says 'List', but the description is a noun phrase: 'Messages the account owner starred — usually the things they wanted to keep.' It implies listing but doesn't state it explicitly. It does distinguish from siblings like list_messages by the 'starred' qualifier, but the action itself is only implied.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention that this is specifically for starred messages as opposed to regular messages, nor does it describe any exclusions or prerequisites. The agent must infer usage from the title and the parameter 'chat', which provides no context for when to choose this over list_messages.

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

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

No annotations are provided, so the description carries the full burden. It only states the purpose and does not disclose whether the operation is read-only, how results are returned, whether multiple matches are possible, or any side effects. It does not contradict annotations, but it is insufficient.

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

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

The description is a single short sentence with zero redundancy. It front-loads the core purpose efficiently, making it exemplary in conciseness.

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

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

For a tool with two parameters and no output schema, the description lacks essential details such as the meaning of the limit parameter, the return format, and handling of multiple matches. It is not complete enough for an agent to call correctly without further inference.

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 must compensate. It hints that the query parameter is a name or number but does not explain the limit parameter at all. It adds minimal value beyond the raw schema.

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

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

The description clearly states the tool finds a contact JID by name or number, specifying the verb and resource. It distinguishes from search_messages by resource type, though it doesn't explicitly name any sibling tools.

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 when a name or number is available but provides no explicit guidance on when to use this tool versus alternatives like search_messages. No prerequisites, exclusions, or alternative routing is mentioned.

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

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

With no annotations, the description carries full behavioral disclosure burden. It only mentions 'full-text search' without addressing pagination, result ordering, case sensitivity, or read-only nature. Critical operational details are absent, making the description insufficient for safe invocation.

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

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

The description is a single sentence with no redundant words, making it concise and front-loaded. However, it is too sparse to be fully useful, but that is a completeness issue rather than a conciseness one. It earns a high score for efficiency.

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

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

For a tool with 5 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain result format, pagination behavior, or the meaning of time-range parameters. An agent cannot confidently use this tool without additional assumptions.

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 only 40% (query and chat have descriptions), but the description adds nothing about parameters. The after, before, and limit parameters are undocumented in both schema and description, leaving the agent guessing about their semantics. The description does not compensate for the schema gap.

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 performs full-text search over synced message history, distinguishing it from search_contacts (contact search) and list_messages (listing messages). The verb 'search' plus resource 'message history' is specific and actionable.

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 no guidance on when to use this tool versus siblings like list_messages or get_message_context. It doesn't mention exclusions, prerequisites, or alternatives, leaving the agent to infer usage from the tool name alone.

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