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 reveals that the operation fails on linked devices, that the new device receives only future messages, and issues a security warning about not sharing the URI. This goes beyond the basic action and fully informs the agent of consequences.

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?

Every sentence serves a purpose: the core action and constraint are front-loaded, followed by the URI source, post-link behavior, verification, and security warning. No fluff—it is thorough without being verbose, appropriate for a tool with security implications.

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 single-parameter tool with no output schema, the description covers all necessary aspects: operation, failure conditions, URI acquisition, post-link behavior, and related tools. An agent has everything needed to decide when and how to call 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 schema already describes the 'uri' parameter with 100% coverage, so baseline is 3. The description adds valuable context about how to generate the URI (from signal-cli link output or QR scan) and emphasizes its security sensitivity, enhancing the semantic understanding 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 action ('Link a new secondary device'), the target ('your Signal account'), and the input mechanism ('using a device-link URI'). It also distinguishes itself from siblings by mentioning list_devices and remove_device as complementary operations, making its purpose 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?

Explicitly specifies when the tool works (only when signal-mcp is the primary device) and when it fails (if set up via signal-cli link), with the exact error message. It provides how to obtain the URI (signal-cli link or QR scan) and directs the agent to use list_devices to verify and remove_device to unlink, covering both context and alternatives.

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 states the return shape ({status, pack_id}), that pack_id is parsed from the URI, and that no separate list_sticker_packs call is needed. It could add more about error behavior or side effects, but for a simple install operation it is reasonably transparent.

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?

Three sentences with no filler. Each sentence earns its place: what the tool does, what it returns and how to use it downstream, and when to prefer a sibling tool. The most critical 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?

For a one-parameter tool with no output schema, the description covers everything needed to call it correctly: the required URI format, the return value, and the relationship to related sticker tools. No meaningful gap remains for correct 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 description coverage is 100%, so the baseline is 3. The description reinforces the required URI format and signal.art domain, but it largely repeats what the input schema already states rather than adding substantial new 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 opens with a specific verb and resource: "Install a Signal sticker pack from a signal.art URL." It clearly distinguishes this tool from siblings like list_sticker_packs and send_sticker by explaining that pack_id is parsed and ready for direct use.

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?

It explicitly tells the agent when to use list_sticker_packs instead: when browsing sticker_id/emoji contents is needed. It also explains how the output feeds directly into get_sticker or send_sticker/send_group_sticker, reducing ambiguity about when this tool is appropriate.

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 provided, so description carries full burden. It discloses immediate deletion for all participants, requires admin status, and works in groups. Lacks details on reversibility or error cases, but sufficient.

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, front-loaded with purpose, zero waste. Information is efficiently presented.

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 no output schema and no annotations, the description covers key behavior, prerequisites, and sibling differentiation. Could include potential failure modes, but does not detract from overall completeness.

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?

Input schema has 100% coverage with clear descriptions. The description adds context (e.g., group_id from list_groups) but does not provide substantial new meaning 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: deleting any message in a group as an admin, regardless of author. It distinguishes from sibling tools 'delete_message' and 'delete_group_message' by specifying admin-only 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?

Explicitly states when to use (as group admin wanting to delete others' messages) and when not to (for own messages use other tools). Also advises confirming admin status with list_groups.

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 fully discloses behavior: primary-device restriction, failure mode on linked devices, local application and network propagation, silent discard of messages, suppressed delivery receipts, no notification to blocked contact, preservation of history, persistence across restarts, and reversibility. This is exhaustive and leaves no surprises for the agent.

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 well-structured paragraph that front-loads the core purpose, then logically proceeds to limitations, effects, and usage guidance. While dense, every sentence contributes essential information; it could be slightly tightened but is far from verbose or redundant.

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 single-parameter tool with no output schema, the description covers all necessary context: prerequisites (primary device), side effects (silent discard, receipt suppression), persistence, reversibility, and clear boundaries with sibling tools. An agent can call this tool correctly with full knowledge of consequences.

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 single parameter 'number' is fully described in the schema with E.164 format and example. Since schema coverage is 100%, the description adds no further parameter-specific detail beyond what the schema already provides, which meets the baseline of 3.

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 action (block a Signal contact), the resource (a contact), and the effect (can no longer send messages or call). It also explicitly distinguishes from unblock_contact and remove_contact, making sibling differentiation immediate.

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?

Provides explicit when-to-use (permanently stop receiving messages), when-not-to-use (temporary mute, removing a contact), and names the alternative tools (unblock_contact, remove_contact). No ambiguity about appropriate contexts.

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 burden. It discloses the key error cases: already-sent messages and nonexistent IDs. It does not describe the success return value or permission requirements, but for a simple cancellation operation the main behavioral expectations are covered.

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 only: the first states the operation and key, the second explains how to find the ID and what errors to expect. Nothing is extraneous, and the most important detail 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?

For a single-parameter utility with no output schema or annotations, the description provides the essential inputs, ID source, and error behavior. It stops short of stating what a successful cancellation returns, but that is reasonably inferable from the clear cancel action.

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%, and the schema already defines job_id as 'Scheduled message job ID from list_scheduled_messages.' The description reinforces this source but adds no new semantic details beyond the schema, so the baseline score 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 uses a specific verb ('Cancel') with a precise resource ('pending scheduled message') and identifies the identifying key ('by its job ID'). This clearly differentiates the tool from siblings like schedule_message, list_scheduled_messages, and run_scheduled_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 direct guidance on how to obtain the job_id ('Use list_scheduled_messages to find the ID') and sets an expectation by noting that cancellation fails if the message was already sent. It does not explicitly name alternatives or state 'use when the message is pending,' but the intent is clear enough.

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 that the deletion is local-only and requires confirmation, but does not mention irreversibility or potential side effects like attachment deletion.

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: first states the action and scope, second clarifies it's local-only and the requirement. No fluff, front-loaded with key information.

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 one param and no output schema, the description covers purpose and constraint. Lacks mention of return value or confirmation of success, which would improve completeness.

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%, so baseline is 3. The description merely restates the requirement from the schema ('Requires confirm=true') without adding new 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?

Description clearly states the action (delete all locally stored messages) and resource (signal-mcp database), and explicitly distinguishes from deleting messages from Signal, which differentiates it from siblings like 'delete_local_messages' that delete specific 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 includes the requirement that confirm=true must be set, which is a usage guideline. However, it does not explicitly compare with similar tools like 'prune_store' or 'delete_local_messages' to guide selection.

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?

Despite no annotations, the description discloses key behavioral traits: the creator becomes admin, all listed members receive an invitation notification, and the tool returns the group's ID and invite link. It does not mention any potential limits or side effects, but overall adequately covers the immediate effects.

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 two sentences, concise and front-loaded with the primary action, then additional details. Every sentence adds value without redundancy.

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 there are three simple parameters (no nested objects, no enums) and no output schema, the description adequately covers the tool's complete behavior: creation, admin assignment, notifications, return values, and references to related tools. No 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%, and the description adds minimal semantic value beyond the schema. The schema already describes 'name', 'members' (with phone numbers), and 'description' as optional. The description reiterates these in natural language but does not add new meaning.

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: 'Create a new Signal group with specified members.' It also specifies that the creator is automatically admin, members receive invitations, and returns the new group's ID and invite link. Distinguishes from siblings like update_group and send_group_message by mentioning their specific use cases after creation.

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 guides when to use this tool (creating a group) and when to use alternatives: 'Use update_group to modify the group after creation... Use send_group_message to post messages to the group.' This provides clear context and prevents misuse.

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 are absent, so the description bears full responsibility. It discloses that the tool returns 'the poll timestamp needed for vote_poll and terminate_poll', and that multi_select defaults to false. However, it does not mention error handling or behavior when invalid parameters are provided, which would improve transparency.

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 concise with four sentences, each adding essential information: core action, option requirement, multi_select behavior, recipient/group choice, return value, and reference to terminate_poll. No unnecessary words, and the most important info 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 complexity (5 parameters, 2 required, no output schema), the description covers all necessary aspects: what it does, how to configure it, required parameters, optional behavior (multi_select), and how the return value is used by other tools. It is complete for the intended 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?

Schema coverage is 100%, but the description adds meaningful guidance beyond the schema: it clarifies the mutual exclusivity of recipient and group_id (not enforced in schema), and explains the effect of multi_select (allow multiple answers). This goes beyond the schema's descriptions, earning a score above baseline.

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 'Create a poll and send it to a Signal contact or group.' This is a specific verb (Create) and resource (poll) with a clear target (Signal). It also distinguishes itself from sibling tools like vote_poll and terminate_poll by referencing them.

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 when-to-use guidance: 'Provide at least 2 options', 'Set multi_select=true to allow voters to pick multiple answers', 'Provide either recipient (DM) or group_id (group) — exactly one is required', and recommends using terminate_poll to close the poll. This gives clear usage conditions and alternatives.

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 fully carries the burden: discloses that deletion sends a request to group members, works on Signal 5.0+, may fail on older clients, and does not remove the message from local store. Also notes only own messages can be deleted.

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?

Concise, front-loaded with purpose, then provides usage guidelines, alternatives, caveats, and limitations. Every sentence serves a purpose with no redundancy.

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 2 parameters, no output schema, and no annotations, the description covers all necessary behavioral context: purpose, constraints, source of timestamp, failure modes, and local vs remote effects. It also distinguishes relevant siblings.

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 covers both parameters with descriptions, but the description adds value by explaining that target_timestamp is the sent_at timestamp from get_conversation, which aids correct parameter usage.

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?

States specific verb and resource ('Remote-delete a message you previously sent to a Signal group') and distinguishes from sibling tools by explicitly naming admin_delete_message for admin deletion and delete_message for direct 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?

Explicitly states when to use ('when you want to retract a message you sent in a group') and when not to use ('Do NOT use for direct messages — use delete_message instead'), plus provides source for target_timestamp.

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, description carries full burden. It discloses key behavioral trait: only local deletion, no unsend. This is sufficient for a simple operation, though it omits any mention of reversibility or permission 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?

Two sentences, front-loaded with action, no wasted words. Every part adds value: what it does, scope, and what it does not do.

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 one parameter and no output schema, description fully covers purpose, scope, and limitation. No gaps given complexity.

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% for the single parameter 'recipient', which is described as 'Phone number or group ID whose messages to delete'. The tool description does not add meaning beyond the schema, meeting baseline.

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?

Description clearly states 'Delete locally stored messages for one contact or group', specifying the verb (delete) and resource (locally stored messages). It distinguishes from siblings like delete_message by noting it does not unsend.

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?

Explicitly states 'Does NOT unsend from Signal — only removes from local store', informing when to use (local deletion) and when not to (if unsend needed). Does not name specific alternative tools but context is clear.

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 provided, so description carries full burden. Discloses that deletion sends request to recipient, requires Signal 5.0+, only works for own sent messages, may fail silently, and does not remove from local store (pointing to delete_local_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?

Single paragraph with multiple sentences, each serving a purpose. Slightly long but well-organized. Could be broken into bullet points for readability, but overall efficient.

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 deletion tool with no output schema, description covers behavior, constraints, parameter details, and alternatives. Missing return value information, but not critical for this type of tool.

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%, but description adds context: target_timestamp is described as 'sent_at timestamp from get_conversation', and recipient is clarified as phone number. Provides meaning beyond 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?

Description states specific action: remote-delete (unsend) a message you sent to a Signal contact. Clearly distinguishes from sibling tools by naming alternatives like delete_local_messages, delete_group_message, and admin_delete_message.

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?

Explicitly states when to use ('retract a sent message from recipient's device') and when not to ('Do NOT use for group messages, use delete_group_message instead; Do NOT use to delete a message you received'). Also notes silent failure on older clients.

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?

Discloses editing behavior: sends via signal-cli, recipients see '(edited)' label, only text modifiable, must reference exact timestamp, only own messages, no time limit but Signal may ignore old edits. With no annotations, description fully covers 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?

Description is concise and front-loaded: first sentence states core purpose. Subsequent sentences add necessary constraints without redundancy. Every sentence adds value.

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?

No output schema, but description covers usage context, constraints, and behavioral details like Signal ignoring old edits. Missing explicit return value info, but overall complete for a mutation tool.

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%, so baseline is 3. Description adds value by explaining target_timestamp must be exact, recipient vs group_id usage, and that exactly one is required. This clarifies parameter semantics beyond 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?

Clearly states the tool edits the text of a previously sent message. Distinguishes from send_message, delete_message, and other siblings by specifying that only text is modifiable, not attachments or other elements.

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?

Explicitly says when to use: 'Use when correcting a typo or updating information.' Also states when not to use: 'Do NOT use to change who a message was sent to — send a new message instead.' Provides context on editing only own messages and requiring exact timestamp.

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?

Discloses that only messages already in the local store are included, and that messages never received on this device are absent. Does not explicitly state read-only nature, but operation is clearly non-destructive. No annotations present to contradict.

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 main purpose and includes necessary details. Slightly verbose but every sentence serves a purpose. Could be tightened slightly without losing clarity.

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 no output schema, the description adequately covers return value characteristics (JSON vs CSV format, field preservation). All three parameters are explained with practical usage context. No gaps in understanding for an agent.

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% (baseline 3). The description adds value by explaining that recipient restricts to one conversation, since uses ISO 8601, and that JSON preserves all fields while CSV is flat. This goes beyond the bare 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 tool exports locally stored messages as JSON/CSV for archiving, analysis, or migration. It distinguishes itself from siblings like get_conversation and search_messages by specifying its batch export use case.

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?

Explicitly says when to use ('full or filtered dump of conversation history in machine-readable form') and when not to use ('Do NOT use to read individual messages interactively'), naming specific alternatives (get_conversation, search_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?

With no annotations, the description carries the behavioral burden. It discloses that matching is case-insensitive substring containment, that the query can match name or number, and that all matching contacts are returned. This goes beyond a simple one-line summary, though it omits details like result ordering, pagination, or empty-result 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?

Two sentences deliver the core action, matching behavior, and practical use cases without filler. The most important behavioral details are front-loaded, and every sentence contributes meaning.

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 search tool with no output schema, the description is nearly sufficient: it explains what is searched, how matching works, and what is returned. The main gap is not mentioning the alternative list_contacts or the shape of returned contact objects, which would round out 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?

The single parameter already has a clear schema description: 'Name or phone number fragment to search for.' The tool description adds value by specifying case-insensitive contains semantics and that both name and number are searched. With 100% schema coverage, this extra context justifies a score above baseline.

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 specifies a clear verb and resource: 'Search contacts by name or phone number fragment,' and clarifies that it returns matching contacts via substring matching. It is clearly distinct from list_contacts in function, though it does not explicitly name or contrast a sibling tool, so it stops short of full 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 gives explicit use cases: 'look up a phone number when you only know a name' and 'verify a contact exists.' It provides clear context for when to use the tool, but it does not mention alternatives or when not to use it, such as choosing list_contacts for unfiltered contact listing.

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 linked-device failure, the permanent migration on success, the updating of linked devices, and the pin condition. It does not mention failure scenarios (e.g., wrong code) but is otherwise thorough.

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 paragraph but logically ordered: purpose, condition, prerequisite, parameter details, success effect, and a final warning. Every sentence contributes essential information, with the most critical constraints placed early.

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 two-step process with device restrictions and conditional pin, the description covers all necessary context: the prerequisite call, the device limitation, the success outcome, and explicit guidance on when to use. No output schema exists, but the description suffices for correct 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 100%, so the schema already describes parameters. The description adds extra context: number in E.164 format, 6-digit code, and the conditional nature of pin, which enriches the schema definitions.

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 explicitly states the tool's purpose: completing the second step of a Signal number change by submitting the verification code. It clearly distinguishes from the sibling start_change_number by naming the step and the prerequisite.

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?

Provides explicit usage guidance: must be called after start_change_number, warns not to call without it, explains the primary-device requirement, and specifies when to include the pin. This fully addresses when-to-use vs alternatives.

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 provided, but the description fully discloses that only locally downloaded attachments are accessible, the 30-day server expiration, and the returned data (MIME type, file size, local path, base64 content). This is comprehensive behavioral disclosure.

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

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

Four sentences with clear front-loading of the main action, followed by constraints, usage guidance, and exclusions. No unnecessary words, each sentence adds value.

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 description covers prerequisites (local download, expiration), return value contents, and usage relative to sibling tools. For a single-parameter tool with no output schema, this is maximally complete.

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 single parameter 'filename' is described in the schema with 'get from list_attachments', and the description adds important context about local storage and expiration. While schema coverage is 100%, the description adds meaningful extra info.

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 'Retrieve metadata and the base64-encoded content of a locally saved Signal attachment by filename.' This specifies the exact action and resource, and distinguishes from sibling tools like list_attachments and send_attachment.

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?

Explicitly states when to use ('when you need to read, display, or forward the contents of a received file or image'), what to do before ('Use list_attachments to discover available filenames'), and what not to do ('Do NOT use to send an attachment') with alternative tools named.

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 provided, but description discloses return format (base64-encoded bytes, decode to JPEG/PNG) and error behavior. For a read-only operation, 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.

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

Four concise sentences, each serving a purpose: purpose, identifier types, return format, error and alternatives. 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?

Complete for a 1-parameter, no-output-schema tool. Covers input, output, error, and sibling comparison. No missing information.

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?

Adds meaning beyond schema by explaining that 'identifier' can be a phone number (E.164) for contacts or a group ID from list_groups. Schema only says 'string', so description adds crucial context.

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?

Description uses specific verb 'Retrieve' and resource 'profile photo' for contacts/groups. Clearly distinguishes from siblings get_profile and update_profile.

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?

Explicitly states when to use this tool vs alternatives: 'Use get_profile to also read name and about text alongside the avatar. Use update_profile ... to set your own profile photo.' Also notes error condition.

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?

Despite no annotations, the description reveals a key behavioral trait: it automatically marks messages as read in the local store but does not send a read receipt. This adds value beyond what the input schema provides.

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 concise with two sentences. The first sentence states the primary action, and the second provides a critical behavioral note. No extraneous information.

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 description covers the main purpose and a key behavior. It does not mention the return format or ordering, but the parameters are well-documented in the schema. Slightly more detail could improve completeness, but it is adequate.

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 input schema has 100% description coverage for all 4 parameters. The tool description does not add additional meaning beyond the schema descriptions, so it meets the baseline expectation.

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 retrieves recent message history from the local store, specifying the verb 'Get', resource 'message history', and scope 'with a contact or group'. It distinguishes itself from the sibling 'send_read_receipt' by explicitly noting that it does not send a Signal read receipt.

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 includes a clear alternative: 'call send_read_receipt for that' if a read receipt is needed. However, it does not provide guidance on when to use this tool versus other message retrieval tools like 'receive_messages', 'export_messages', or 'get_unread'.

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?

Despite no annotations, the description implies a read-only operation via the verb 'Get', and for a simple getter with no side effects, this level of disclosure is adequate. However, it could explicitly state it is non-destructive.

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 of 12 words, front-loaded with the verb, and contains no superfluous information.

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 with no parameters and no output schema; the description sufficiently conveys its purpose and return value (the phone number). It is complete enough for an AI agent to use 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?

With no parameters, schema coverage is 100%, and the baseline for 0 parameters is 4. The description does not need to add parameter details since none exist.

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 verb 'Get' and the resource 'own Signal phone number', and it distinguishes itself from siblings like 'list_accounts' which list all accounts, making its purpose 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 implies usage when needing the server's own number, but it does not explicitly provide when-to-use vs alternatives or any context for exclusion, leaving it implied rather than explicit.

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

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

Discloses that data is fetched live from the Signal network (not cache), which is important behavioral context. No annotations, so description carries the burden; it adds value but doesn't mention error handling or rate limits.

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?

Three concise sentences covering purpose, behavioral nuance, and usage guidance. No redundancy, front-loaded with main action.

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?

Lists returned data fields but lacks output schema. No mention of error cases or invalid numbers. Adequate for a simple tool but could be more complete.

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% with description for 'number' (E.164 format). Description does not add additional meaning beyond the schema, thus baseline score.

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?

Clear verb ('Fetch') and resource ('Signal profile') with specific data fields listed. Distinguishes from sibling by mentioning update_profile for updates.

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?

Explicitly states use cases: verify contact's name or check profile setup. Directs to update_profile for own profile updates, providing clear when-to-use and alternatives.

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 implicitly indicates a read-only operation by stating 'retrieve'. It does not mention side effects, permissions, or error conditions, but for a simple retrieval tool, the disclosure is adequate.

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: first states the purpose and output format, second provides usage guidance. No unnecessary words, all information is relevant and 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?

For a simple retrieval tool with two parameters and no output schema, the description is complete. It explains what the tool does, how to get the required parameters, and the format of the result (base64). No 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?

The input schema already fully describes both parameters (pack_id and sticker_id) with types and explanations. The description adds a hint to use list_sticker_packs to find values, which is helpful but does not add meaning beyond the schema. With 100% schema coverage, baseline score is 3.

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 retrieves a single sticker image as base64. It specifies the action (retrieve), resource (sticker image), and output format (base64). This distinguishes it from sibling tools like send_sticker or list_sticker_packs.

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 instructs the agent to use list_sticker_packs to find the required IDs, providing a clear prerequisite step. However, it does not explicitly state when to use this tool versus alternatives like send_sticker or send_group_sticker, though the context makes it obvious.

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 and handles it well. It discloses that messages are marked as read after retrieval, that behavior depends on whether a background service is running, and that the tool may poll signal-cli as a fallback. It also exposes the has_more continuation behavior, which is essential for correct 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 front-loaded with the core purpose and every clause contributes necessary behavioral or usage information. It is somewhat long and dense, but not wasteful. It earns a high score for efficiency while leaving a little room for tighter organization.

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 one-optional-parameter tool with no output schema, the description covers everything needed: how to invoke it, what happens after retrieval, and how to handle pagination. It even explains the background-service vs polling behavior, which is important operational context. No critical information is 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 coverage is 100%, so the schema already documents the limit parameter. The description adds meaning by explaining that 'limit' controls the batch size and that callers should reuse the same limit when continuing with has_more=true. This gives the parameter practical usage context beyond the schema's 'Max messages to return'.

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: 'Get new unread messages.' It also adds the directive 'Always use this to check for new messages,' which positions the tool as the primary entry point. However, it does not explicitly contrast itself with siblings like receive_direct or receive_messages, so it stops short of full sibling differentiation.

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

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: it should always be used to check for new messages, and it explains the batching pattern with has_more. It does not explicitly state when not to use it or name alternative tools, so it lacks full when-not 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?

Describes that it queries Signal servers, returns status, and accepts batches. Discloses limitation about privacy-mode. Without annotations, the description carries the full burden and does so effectively, though it could explicitly state that it's read-only.

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?

Concise, with 4 sentences. The main purpose is front-loaded, and each sentence adds value without redundancy.

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 one parameter and no output schema, the description is complete: covers purpose, usage, limitations, and sibling tool distinction.

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 has 100% coverage but description adds context: batching multiple numbers and what the return value is (registered/unregistered status). This adds meaning beyond the schema description.

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 it checks whether phone numbers are registered Signal users, using a specific verb 'check' and resource. It distinguishes itself from sibling tools like 'get_profile', making its purpose 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?

Explicitly tells when to use (before sending to unknown numbers) and when not to use (not for profile details, use 'get_profile' instead). Also notes limitation about privacy-mode accounts, providing clear usage 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 provided, the description carries the full burden. It does disclose the key behavior—returning null when no webhook is configured—and the read-oriented verb 'Return' implies no side effects, but it does not explicitly state read-only status, permissions, or any other behavioral constraints.

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. Every word adds meaning, covering the operation, the resource, and the null edge case.

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?

This is a simple, parameterless getter, and the description fully covers its behavior: it returns the current webhook URL or null if unset. No output schema exists, but the return semantics are adequately described for an agent to invoke and interpret the result 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 takes zero parameters, so the input schema is already complete and there is nothing for the description to add. This matches the baseline of 4 for a parameterless tool.

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 opens with a specific verb ('Return') and identifies the exact resource ('currently configured webhook URL'), including the null case when none is set. This clearly distinguishes it from the sibling set_webhook as the retrieving counterpart.

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 'currently configured' implies this tool is for reading the active webhook rather than modifying it, but the description never explicitly names alternatives or states when not to use it. It leaves the agent to infer usage from context rather than giving direct 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?

No annotations exist, so description carries full burden. It reveals platform-specific auth (Keychain on macOS, libsecret on Linux) and prerequisite (sqlcipher). Does not specify whether import merges or overwrites existing data, but overall good disclosure for a non-destructive import operation.

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?

Three efficient sentences. First sentence states purpose, second adds prerequisites and auth context, third directs to sibling. Every sentence earns its place with no redundancy.

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 zero parameters and no output schema, description fully covers what the tool does, prerequisites, platform specifics, and alternative tool. Completely adequate for an agent to decide when to invoke.

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?

No parameters in schema; description does not need to explain parameters. Baseline for zero params is 4. No additional param info is needed.

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?

Clearly states it is a one-time import of all historical messages from Signal Desktop, specifying platform (macOS/Linux). Differentiates from sibling sync_desktop by saying 'for ongoing sync use sync_desktop instead.' Verb+resource+scope are precise.

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?

Explicitly gives guidance: use for one-time import, use sync_desktop for ongoing sync. Mentions prerequisite (sqlcipher) and platform-specific authentication behaviors, which are clear when-to-use/not-use signals.

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 provided, so the description carries the full burden. It discloses that joining may require admin approval and that the request can be pending, which is useful. However, it does not mention other behavioral aspects such as visibility of the user's profile or any rate limits.

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 concise with two sentences, no redundancy, and front-loads the primary action. Every sentence adds value.

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 one parameter and no output schema, the description adequately covers the joining process, potential pending state, and subsequent steps. It is complete enough for the intended use.

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 covers the single parameter 'uri' with 100% description coverage. The description reiterates the purpose of the parameter (invite link with format) but does not add substantial meaning beyond what the schema already states.

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 action 'Join a Signal group' using a specific resource type 'invite link' and provides the URL format. It distinguishes from sibling tools like create_group and leave_group.

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 explains when to use the tool (having an invite link) and mentions admin approval as a conditional outcome. It suggests a follow-up action (list_groups) but does not explicitly exclude scenarios where alternative tools would be better.

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 provided, so the description fully informs about behavioral traits: no longer receiving messages, removal from member list, notification to others, and irreversibility without re-invite.

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 four sentences, each providing essential information: action, consequences, irreversibility, and how to obtain the required parameter. 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?

For a simple mutation tool with one parameter, the description covers all necessary context: what happens, side effects, and parameter source. No output schema is needed given the simplicity.

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 input schema already has high coverage (100%) and includes the same guidance ('Group ID to leave (get from list_groups)'). The description adds no new parameter information beyond the schema, so baseline score 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 states 'Leave a Signal group' clearly, specifying the action and resource. It distinguishes from other group-related tools like 'delete_group_message' or 'join_group'.

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 explains when to use (to leave a group) and provides guidance to use list_groups to find the group_id. It does not explicitly mention when not to use, but the context is clear.

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?

The description explains what the tool returns (E.164 phone number and registration status) and implies it is a read-only operation. No annotations are present, so the description carries the full burden; it is transparent enough for a simple list tool, though it could explicitly state it is read-only.

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 concise, consisting of three sentences that sequentially cover the action, the return format, and usage guidance. Every sentence adds value, and the structure is efficient.

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 has no parameters and no output schema, so the description sufficiently covers its functionality, return values, and typical usage context. It explains the common scenario (single account) and purpose, making it fully 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.

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

The input schema has zero parameters, so the baseline is 4 per the rubric. The description does not need to add parameter information; it instead describes the output, which is appropriate for a parameterless tool.

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: to list all Signal accounts with their phone numbers and registration status. It distinguishes from the sibling tool 'get_own_number' by noting that the latter is for single-account setups, ensuring the agent knows which tool to use.

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 advises when to use this tool ('when you need to confirm which accounts are available before sending or receiving messages') and when to use an alternative ('Use get_own_number to get the active account's number in single-account setups'), providing clear usage 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?

No annotations provided, so description carries full burden. It explains that only explicitly downloaded attachments are listed, not those unfetched. It also specifies return fields. However, it does not explicitly state that the operation is read-only, though implied. No contradictions with annotations (none 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?

Three sentences, front-loaded with purpose. Each sentence adds value: purpose, return details, 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 no parameters and no output schema, description is complete: explains purpose, return contents, and usage context. Covers what an agent needs to decide when to call it and what to expect.

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?

Input schema has no parameters (100% coverage trivially). Description adds meaning by explaining what the tool returns and the condition for listing (downloaded only). Baseline for 0 params is 4, and description meets it well.

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?

Description clearly states 'List all Signal attachments that have been downloaded and saved to the local store' with a specific verb and resource. It distinguishes from siblings like get_attachment (retrieves file content) and receive_messages (downloads new attachments).

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?

Explicitly states when to use ('discover what media files are available locally before reading them') and when not to use ('Do NOT use to download new attachments from Signal servers — use receive_messages for that'). Also clarifies that only downloaded attachments appear.

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. It discloses that the tool returns contacts from the local store (no network calls), includes names and phone numbers, and supports substring filtering. While it does not mention potential limits or error cases, for a simple read operation this is sufficiently transparent.

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 three concise sentences. The first explains the core action, the second describes the optional parameter, and the third points to a related sibling tool. Every sentence adds value, with no redundancy or fluff.

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 one-parameter tool with no output schema, the description is complete. It tells the agent what the tool returns (contacts with names and numbers), how to filter, and where to go for more detailed profile information. No gaps remain for effective use.

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 input schema already covers the search parameter with a case-insensitive substring match description. The description adds minimal extra meaning ('by name or number substring'), which is consistent but not significantly enhancing beyond the schema. Given 100% schema coverage, a baseline 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 tool lists all Signal contacts known to the account, specifies what is included (names and phone numbers), and distinguishes it by mentioning the local store. It also contrasts with the sibling tool get_profile, providing clarity on its unique purpose.

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 explains when to use the optional search parameter (to filter by name or number substring) and directs users to get_profile for fetching Signal profiles. However, it does not explicitly differentiate from other listing tools like list_conversations or list_groups, though the context implies contact-specific 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?

No annotations provided; description discloses return fields and name resolution from local contacts. Does not explicitly state read-only nature but it is implied. Adequate but could mention side effects (none) or auth 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?

Concise with multiple sentences each adding value. Front-loaded with purpose, then return fields, usage guidance, and alternatives. No unnecessary 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 no output schema, description explains all return fields adequately. Covers ordering, returned data, name resolution. Complete for a simple list tool.

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?

Input schema has zero parameters, so baseline is 4. Description does not add param info because none exist. 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?

Clearly states it lists all conversations ordered by most recent message and specifies the returned fields. Explicitly differentiates from sibling tools like get_conversation and get_unread.

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?

Provides explicit usage context: use for inbox overview before reading specific conversations, and warns not to use for reading message history. Names alternative tools get_unread and get_conversation.

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 burden. It explains output fields and notes device ID 1 is primary. For a read-only list operation, it is sufficiently transparent, though it could mention authentication implicitly assumed.

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?

Three sentences: first states purpose and output, second adds detail about primary device, third gives usage context. No wasted words, 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 no parameters and no output schema, the description fully explains what the tool returns and when to use it, making it complete for an agent to decide and invoke.

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?

Input schema has zero parameters, so baseline is 4. The description adds value by explaining the return fields, which is beyond schema requirements.

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 it lists all devices linked to a Signal account, specifies return fields (ID, name, last-seen timestamp), and distinguishes from sibling tools like update_device and remove_device.

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?

Explicitly states when to use: 'when auditing which devices have access ... or to find the ID of a device you want to rename or remove.' Also references sibling tools for further actions.

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?

Without annotations, the description carries the full burden of behavioral disclosure. It accurately describes the read-only nature and what fields are returned, but does not mention pagination, performance, or access restrictions. Still, for a simple list tool it is sufficiently transparent.

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 two sentences with no wasted words. The first sentence fronts the core function, and the second adds contextual usage. Every sentence adds value.

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 (no parameters, simple list), the description covers purpose, usage relationship to other tools, and what to expect in return (group details). It is complete for its scope.

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 input schema has zero parameters (100% coverage). The description does not need to add parameter details. According to the rule, 0 parameters yields a baseline of 4, which 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 lists all Signal groups the account belongs to, specifying included fields (name, ID, members, admin list). It distinguishes from sibling tools like create_group, update_group, and leave_group.

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?

Explicitly explains that the returned group_id is required for send_group_message, send_group_attachment, and update_group, and mentions update_group for modification and leave_group for exiting. Provides clear guidance on when to use this tool versus alternatives.

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?

Despite no annotations, the description fully discloses behavior: returns identity keys and trust levels, explains trust level meanings, and clarifies scope (all vs. filtered). Since no annotations exist, the description carries the full burden and meets it completely.

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 concise, well-structured, and front-loaded. Every sentence adds value without redundancy, covering purpose, explanation, usage conditions, and exclusions 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?

Given the simplicity of the tool (one optional parameter, no output schema), the description is complete: explains what is returned, trust level meanings, and usage scenarios. No gaps remain.

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 single optional parameter 'number' has a schema description, but the tool description adds usage context: omitting returns all, providing filters. This adds meaningful guidance beyond the schema alone.

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 lists Signal identity keys and trust levels for one or all contacts, distinguishes from sibling trust_identity by explicitly stating what not to use it for, and explains trust levels, making purpose and differentiation clear.

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?

Provides explicit when-to-use guidance: before calling trust_identity and when Signal reports safety number change. Also states what not to use it for (trust or change trust levels), directing to sibling tool trust_identity.

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 behavioral burden. It discloses that the tool returns scheduled jobs by default (pending only) and enumerates the returned fields. This gives an agent a concrete sense of the tool's read-only, listing behavior and output shape.

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 carry all essential information: what the tool does, what it returns, and where to go for cancellation. The most important part is front-loaded and there is no redundancy.

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 list tool with one optional parameter and no output schema, the description is largely complete: it states the default scope (pending), the return fields, and the related cancellation tool. The behavior of include_done is left to the schema, which fully explains it, so nothing critical is 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?

The schema already describes the only parameter (include_done) with 100% coverage. The description does not need to repeat it, so the baseline of 3 is appropriate; no additional parameter meaning is added 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 verb and resource: 'List pending scheduled messages,' and adds the returned fields (ID, recipient, send time, status). This distinguishes it from sibling tools like cancel_scheduled_message and run_scheduled_messages without ambiguity.

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 the tool is for viewing pending scheduled messages and explicitly routes cancellation to cancel_scheduled_message. It does not explicitly contrast with schedule_message or run_scheduled_messages, but the use case is clear enough for an agent to decide when listing is appropriate.

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 provided, so the description bears full responsibility. It discloses the return values (pack_id, sticker_id) and their purpose, which is sufficient for a simple read-only list operation. No hidden behaviors or side effects are indicated.

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 that front-load the core purpose and immediate action. Every sentence earns its place: the first explains what the tool does and returns, the second provides an alternative tool for installation.

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 no parameters and no output schema, the description fully covers its behavior: listing all sticker packs, returning needed IDs, and connecting to relevant sibling tools. No gaps for this simple 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?

Input schema has zero parameters, so schema coverage is 100% by definition. With no parameters to describe, the description adds value by explaining the output and usage context, meeting the baseline for trivial parameter sets.

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?

Description clearly states the verb 'List' and resource 'sticker packs installed on this Signal account', and specifies the return values (pack_id, sticker_id) that are needed for send_sticker/send_group_sticker, distinguishing it from sibling tools like add_sticker_pack.

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?

Explicitly tells when to use this tool (to get IDs before sending stickers) and directs to add_sticker_pack for installing new packs, providing clear alternatives and context.

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 and discloses key traits: only local update, no impact on read receipts or other devices, IDs come from specific tools, and marked messages appear in get_unread.

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 four sentences, well-structured and front-loaded. It covers purpose, scope, parameter source, and effect without redundancy.

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 one parameter and no output schema, the description is complete. It explains local scope, ID source, and the resulting effect on get_unread, leaving no critical 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?

The input schema describes message_ids as a list of string IDs. The description adds value by explaining that these are internal IDs from get_conversation or search_messages, and that marking them unread affects get_unread.

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 marks messages as unread in the local store, distinguishing it from siblings like delete_message or send_read_receipt. It specifies the scope (local only) and the effect.

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 a clear use case: 'flag a message for follow-up later.' It also explains the local-only nature and what it does not affect, giving implicit guidance on when not to use.

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?

Without annotations, the description discloses side effects (system notification, replacement of previous pin), permissions (any participant), and the fact that only one pin exists per conversation. Could mention reversibility, but overall good.

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 informative with 9 sentences, each adding value. It is front-loaded with the main purpose. Could be slightly trimmed but still efficient.

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 mutation tool with 4 parameters and no output schema, the description covers purpose, side effects, prerequisites, and usage guidance. Leaves no major 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 covers all parameters (100%), so baseline is 3. The description adds value by specifying mutual exclusivity of recipient/group_id and sourcing target_author and target_timestamp from get_conversation.

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 pins a message in a DM or group conversation, making it prominent. It distinguishes from the sibling tool 'unpin_message' by explicitly mentioning it for removal.

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?

Provides explicit when-to-use ('highlight an important message for all participants') and when-not-to-use ('do NOT use if you only want to bookmark for yourself'), plus prerequisites (get target_author and target_timestamp from get_conversation).

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. It transparently discloses that the operation is local-only and that it deletes based on age. It does not cover potential side effects like irreversibility or confirmation prompts, but the core behavior is well-explained.

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 concise, consisting of two sentences. The first sentence states the action and default, the second clarifies scope and purpose. No extraneous information. Front-loaded with the action verb.

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 low complexity of the tool (one parameter, no output schema, no nested objects), the description is complete. It explains what it does, its scope, and its purpose, which is sufficient 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 input schema covers the single parameter (days) with full description and default. The description repeats the default value (180) but adds no additional semantic meaning beyond what the schema provides. Baseline 3 is appropriate given 100% schema coverage.

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 action (delete), the resource (locally stored messages), and the condition (older than given days). It explicitly distinguishes from server-side deletion by noting that it only affects local history. This differentiates it from sibling tools like clear_local_store or delete_local_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 provides a clear use case ('keeping the store from growing unbounded') and specifies that it only affects local storage. However, it does not explicitly compare with alternatives such as clear_local_store or delete_local_messages, nor does it state when not to use this tool. The guidance is good but not exhaustive.

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?

Discloses that each account can have at most one reaction per message, calling again replaces the previous one, and setting remove=true retracts an existing reaction. No annotations provided, so full burden is on description.

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?

Single paragraph starting with main action, then parameter rules, then usage guidance. Every sentence adds value with no redundancy.

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 complexity of the tool (6 parameters, 3 required, conditional logic), the description covers all behavioral aspects, parameter constraints, and usage context. No output schema, but description is self-contained.

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?

Adds meaning beyond schema by explaining that exactly one of recipient/group_id is required, that emoji is still required for removal, and clarifies the roles of target_author and target_timestamp. Schema coverage is 100%, but description adds significant context.

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 uses specific verbs 'add or remove' and resource 'emoji reaction', and explicitly distinguishes from sending text replies by naming alternatives send_message and send_group_message.

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?

Clearly states when to use (reacting without sending a reply), when not to use (for text replies), and gives exact alternative tools. Also notes the requirement of exactly one of recipient or group_id.

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, and it does so well. It discloses the critical side effect: 'it stops the daemon, calls signal-cli receive directly, then lets the daemon restart.' The agent is warned that this tool is disruptive and not a simple read operation.

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 three concise sentences that front-load the core behavior, then provide context and the preferred alternative. Every sentence earns its place, and there is no fluff 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 tool with one simple parameter and no output schema, the description fully covers what the tool does, when to use it, how it behaves, and how it relates to the sibling tool. An agent has everything needed to invoke it correctly and safely.

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%, and the single timeout parameter is already described in the schema. The description does not add extra meaning about the parameter beyond what the schema provides, so 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 states a specific verb and resource ('Receive messages by calling signal-cli directly, bypassing the daemon') and clearly differentiates it from the sibling receive_messages by framing it as the direct, non-daemon mode. An agent can immediately understand what this tool does and how it differs from the normal receive path.

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 explicit when-to-use guidance: 'Use this as a fallback when the daemon is stuck or unresponsive' and 'Prefer receive_messages (daemon mode) for normal use; use this only for troubleshooting.' This clearly states the condition and names the preferred alternative, leaving no ambiguity.

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 provided, but the description discloses that the tool polls manually and stores messages, implying side effects. Could mention authorization or rate limits, but sufficient for a simple polling tool.

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 front-loaded action and zero 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?

For a tool with one parameter and no output schema, the description covers purpose, usage, and behavior. A brief note on return value or side effects could improve completeness, but it's largely adequate.

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 for timeout is 100% with its own description and default. Description adds no additional parameter-level detail, so baseline 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 tool polls for new messages and stores them, and explicitly distinguishes it from the sibling get_unread.

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?

Explicitly advises preferring get_unread for automatic polling with results, and reserves receive_messages for cases where polling without reading is desired.

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 provided, so description carries full burden. It clearly states behavioral traits: only removes local record, does not block, delete history, or affect messaging. No contradictions.

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, front-loaded with action, no wasted words. Efficiently conveys key information.

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 (one parameter, no output schema, no annotations), the description is complete: explains action, constraints, and alternatives.

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 already describes the parameter with 100% coverage (E.164 format). Description adds no further parameter details, so 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?

Clearly states the action: removing a contact from the local list. Distinguishes from siblings like block_contact and update_contact by explaining what it does not do.

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?

Explicitly tells when to use this tool and when to use alternatives: 'To prevent incoming messages, use block_contact instead. Use update_contact to set a local display name without removing.'

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 fully carries the burden. It discloses the immediate loss of access, that the removed device is not notified, the irreversibility, and the failure mode for linked devices. This is comprehensive for a destructive action.

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 dense but every sentence adds necessary information. It opens with the core purpose, then logically covers conditions, effects, irreversibility, and alternatives. No fluff.

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 single-parameter tool with no output schema, the description covers all needed context: prerequisites, failure conditions, behavioral impact, and alternative tools. Nothing an agent needs to decide whether to use it or how to use it correctly is 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?

The schema's param description is minimal ('get from list_devices'), but the tool description adds critical semantic constraints: device_id must be ≥2 and cannot be the primary device. This goes beyond the schema and is essential for correct invocation.

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 ('unlink') and resource ('secondary device from your Signal account'), and immediately differentiates from siblings by specifying it's for secondary devices only. It clearly distinguishes from add_device, update_device, and list_devices by its irreversible nature.

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?

Explicitly states when it works (primary device only) and when it fails, and names alternatives: 'Use list_devices to find the device_id' and 'Use update_device to rename a device without removing it.' It also warns about the ID requirement (≥2) and the re-link path via add_device.

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, so description carries full burden. It discloses the primary-device-only constraint and the exact error message on linked devices. It also warns about the security consequence (anyone with phone number can re-register) and the SIM-swap risk, which is critical behavioral information.

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 four sentences, but each conveys essential information: the action, the constraint, the security warning, and the alternative. It is front-loaded with the core purpose and avoids redundancy.

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 tool with no output schema, the description is fully complete. It covers what the tool does, when to use it, when not to, what happens on failure, and the consequences. An agent has all information needed to call 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?

There are zero parameters, so schema is empty and coverage is trivially 100%. Baseline for zero params is 4, and the description doesn't need to explain any parameters. No additional parameter semantics required.

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?

States the specific verb 'Remove' and resource 'Signal Registration Lock PIN', and explains the effect (disabling re-registration protection). It also distinguishes from set_pin by explicitly recommending set_pin for setting a new PIN, making it clear this is for removal only.

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?

Explicitly states when to use: 'Use only if you intentionally want to disable the registration lock.' It also provides the alternative: 'Use set_pin to set a new PIN instead of removing the existing one,' and warns against removal if relying on it for SIM-swap protection. This gives clear decision 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?

With no annotations, the description carries the full burden and does so well: it reveals that the background service normally calls it, that manual invocation is supported, that nothing-due returns processed=0, and that each due job yields a per-job result with status 'sent' or 'failed' plus timestamp or error. This fully discloses the tool's behavior and return semantics.

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 compact yet information-dense: purpose, invocation method, safety, and return format are each covered in a single front-loaded passage with no filler. Every sentence earns its place.

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 tool with no output schema, the description fully explains input (none needed), trigger conditions, side effects, and the exact returned shape. It also links to list_scheduled_messages for ID provenance, making the tool self-sufficient for an agent.

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 and the schema is empty, so there are no parameter semantics to clarify. The description adds context about what the tool operates on (due scheduled messages) and what the result shape means, which is the useful equivalent for a parameterless action.

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 opens with a specific verb and resource: 'Process and send any scheduled messages that are currently due.' It clearly distinguishes itself from the scheduling, listing, and canceling siblings by focusing on execution of due jobs, and it references list_scheduled_messages for the job IDs it consumes.

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?

It explicitly states when to call manually — to deliver messages immediately without waiting for the next background service run — and reassures that calling when nothing is due is safe. It does not explicitly list sibling tools to avoid, but the automatic-vs-manual context makes the intended trigger clear.

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 meaningfully reveals that delivery is not immediate or guaranteed at the exact timestamp, but depends on a background service or manual invocation, and that the tool returns a job ID useful for cancellation.

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?

Three short sentences, each serving a purpose: the action, the delivery behavior, and the return value with cancellation path. No filler or repetition of schema details.

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 description covers the tool's core purpose, the asynchronous delivery model, the returned job ID, and how to cancel. While there is no output schema, the return value is described adequately. It does not cover edge cases like past send_at values, but these are not critical for basic 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 description coverage is 100%, so the schema already documents all parameters including the ISO datetime format and group/recipient mutual exclusivity. The description adds no extra parameter-level meaning, matching the baseline for full schema coverage.

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 schedules a message for a future time, using a specific verb and resource. It distinguishes itself from immediate-send siblings like send_message and from the related cancel_scheduled_message and run_scheduled_messages 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 explains when delivery will occur: when the background service runs or when run_scheduled_messages is called manually. It also directs cancellation to cancel_scheduled_message, though it does not explicitly contrast with immediate sending via send_message.

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?

Discloses that search uses SQLite FTS, results are relevance-ranked, only locally stored messages are searched, and pagination is available. No annotations provided, but description covers behavioral traits thoroughly.

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?

Six sentences, front-loaded with core purpose, then technical details, then usage guidance. No redundant or unclear statements.

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?

Covers purpose, constraints, parameters, and usage thoroughly. Lacks output format details but is essentially complete for a standard search tool.

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% with good descriptions; description adds context like E.164 format for sender and pagination usage, exceeding minimal baseline.

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 across locally stored messages by keyword or phrase, and distinguishes itself from chronological browsing via get_conversation.

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?

Explicitly states when to use (searching for specific messages/topics across conversations) and when not to (use get_conversation for chronological browsing), with parameters like sender, limit, offset explained.

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 provided, so description carries full burden. Covers sending types and view_once, but lacks details on file size limits, network requirements, or error handling. Adequate but not thorough.

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?

Three sentences, front-loaded with main purpose, no redundancy. Efficient communication.

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 send operation, description covers purpose, parameter selection, and sibling differentiation. Lacks return value description (no output schema), but overall sufficient for 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 100%, baseline is 3. Description adds minimal value beyond schema: explains path vs paths and view_once behavior. Does not add depth to recipient or caption.

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?

Description clearly states 'Send one or more files or images to a Signal contact' and lists supported types. It distinguishes from sibling send_group_attachment by explicitly noting to use that for groups.

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?

Provides explicit guidance on when to use path vs paths and view_once option. Tells to use send_group_attachment for groups. Lacks explicit 'do not use when' but context is clear.

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 must convey behavior. It states 'push' and 'one-way sync,' indicating mutation. However, it does not detail merge behavior, idempotence, or potential conflicts. Adequate but not exhaustive.

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?

Three concise sentences: action, use case, directionality. No fluff, every sentence adds value. Front-loaded with the core 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 no parameters and no output schema, the description covers the essential behavior. It explains what the tool does, when to use it, and its directionality. Complete for a simple sync 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?

No parameters exist; schema coverage is 100%. Description adds no param details, but none needed. Baseline 4 is appropriate as the schema fully covers parameters.

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 action: 'Push your local contacts list to all linked Signal devices.' This distinguishes it from sibling tools like list_contacts (read-only) and update_contact (individual contact update).

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?

Provides a specific use case: 'Useful when contacts added via signal-cli are not showing up on other devices.' Also clarifies directionality: 'one-way sync from this device outward.' Lacks explicit when-not-to-use, but sufficient for a simple tool.

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 provided, so description carries the burden. It discloses that files must exist locally, non-existent paths return an error, and view_once does not apply to documents. However, it does not mention rate limits, size limits, or what happens if group_id is invalid. Additional behavioral details could improve transparency.

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?

Description is concise with 5 sentences, front-loaded with key purpose and functionality. Every sentence adds value without redundancy. 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?

No output schema, but description covers the main aspects of the tool: supported file types, delivery method, view_once behavior, and parameter usage. Missing details on failure modes or size limits, but adequate for a send operation with 5 parameters. Could mention return values briefly.

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 baseline is 3. The description adds value by clarifying that view_once does not apply to document types (not in schema) and explaining the path vs paths distinction. This extra context justifies a higher score.

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 sends files (photos, videos, documents, audio) to a Signal group in a single message. It explicitly distinguishes from siblings by directing to use send_attachment for direct messages and send_group_message for text-only messages, providing a specific verb and resource.

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?

Provides explicit when to use: sharing files with a group chat. Also gives when not to use: direct messages or text-only. Mentions using list_groups to obtain group_id. Does not explicitly clarify when to use single path vs multiple paths, but the description and schema imply both are valid.

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 burden and does well: it discloses end-to-end encryption, delivery to all members, the return value semantics, the UTF-16 code unit pitfall for mentions, and the prerequisite for quoting. It stops short of failure modes or side effects, but for a send operation the disclosed traits are substantial.

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 dense but every sentence earns its place: purpose, return-value usage, mention encoding caveat, quote requirements, ID provenance, and sibling exclusions. It is front-loaded and logically ordered, with no filler.

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 and no output schema, the description covers everything an agent needs: how to construct mentions, the encoding gotcha, how to reply/quote, where to get identifiers, what the return value is for, and which sibling to use instead. Nothing essential is 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 coverage is 100%, so the baseline is 3. The description adds value by explaining the mention encoding with an emoji example, tying the return timestamp to react/edit operations, and clarifying the source of quote_timestamp and group_id. Some redundancy exists with the schema, but the added context pushes it above baseline.

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 opens with a specific verb+resource: 'Send a text message to a Signal group.' It distinguishes itself from siblings by explicitly contrasting with send_message (direct messages) and send_group_attachment (files/images), so an agent can select it correctly.

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 when-to-use guidance: use list_groups to obtain group_id, use send_group_attachment for files, and do NOT use for direct messages (use send_message instead). It also tells when the returned timestamp is useful (for react_to_message or edit_message). This is fully actionable routing.

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 exist, so description carries full burden. It explains that sticker is rendered as a distinct message type, not file attachment, and that invalid pack/sticker returns error. Could additionally mention lack of side effects or permissions, but the existing disclosure is strong.

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?

Description is adequately concise with front-loaded purpose. Every sentence adds value, though it could be slightly tightened. No extraneous information.

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 3 required parameters, no annotations, and no output schema, the description covers purpose, usage, parameter semantics, prerequisites, and alternatives. An agent can correctly select and invoke the tool without 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 descriptions cover 100% of parameters, and the description adds value by explaining that pack_id is a hex string, sticker_id is 0-based, and both must match an installed pack. Also explains how to obtain them via list_sticker_packs, going beyond 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 it sends a sticker to a Signal group, distinguishes it from sending images (use send_group_attachment instead) and from direct messages (use send_sticker). It uses specific verb+resource and identifies the unique action.

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?

Provides explicit when-to-use (expressive image reaction in group), when-not-to-use (for regular images or DMs), and prerequisites (list_groups, list_sticker_packs, add_sticker_pack if needed). Directly names alternative 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?

Discloses end-to-end encryption, return value (timestamp) for reactions/edits, and quoting behavior. No annotations provided, but description adds useful behavioral context beyond schema.

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?

Three concise sentences, front-loaded with purpose and encryption, then return value and usage tips, then alternatives. No unnecessary 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?

For a simple parameter set with full schema coverage and no output schema, the description covers purpose, usage, return value, and relationship to siblings. Adequate for effective agent 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 100% so baseline is 3. Description adds value by explaining the usage of quote_author and quote_timestamp (for quoting) and the return timestamp usage.

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 'Send' and resource 'text message to a Signal contact', and distinguishes from siblings by mentioning send_group_message and send_attachment for alternatives.

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?

Explicitly states when to use this tool vs alternatives: for group chats use send_group_message, for attachments use send_attachment. Also explains how to reply/quote using quote parameters.

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. It states what the tool does but does not disclose side effects (e.g., whether declining blocks the contact, if notifications are sent, or if there are rate limits). The behavior of accepting vs. declining is implied but not fully detailed. For a simple tool, this is adequate.

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 wasted words. It is front-loaded with the action and provides essential context. Perfectly concise for a simple 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 simplicity (2 parameters, no output schema), the description is complete enough for an agent to use correctly. It explains purpose, usage context, and the two possible actions. It does not specify return values, but for a mutation tool like this, success/failure is typically inferred. A minor gap is lacking what happens after decline (e.g., is the contact blocked?), but overall it's sufficient.

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%, so the baseline is 3. The description adds minimal additional meaning beyond the schema. The schema already explains 'sender' as phone number and 'accept' as boolean for accept/decline. The description's context that this is a prerequisite for replying is helpful but does not significantly enhance parameter understanding.

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