Signal MCP
Server Quality Checklist
Latest release: v1.36.0
- Disambiguation4/5
Tools are generally well-differentiated with clear descriptions. A few overlaps exist (e.g., receive_messages vs get_unread, delete_message vs delete_group_message) but descriptions explain when to use each, so ambiguity is minimal.
Naming Consistency5/5Tool names consistently follow a verb_noun pattern (e.g., add_device, block_contact, create_group). There are rare exceptions like store_stats, but they do not disrupt the overall pattern.
Tool Count3/572 tools is high for a single MCP server. While Signal has many features, the count feels slightly bloated; some tools (e.g., separate send_sticker and send_group_sticker) could be merged without loss of clarity.
Completeness5/5The toolset covers nearly every aspect of Signal: messaging, groups, contacts, profiles, devices, stickers, polls, attachments, configuration, identity management, and more. No obvious gaps for a Signal client.
Average 4.5/5 across 71 of 72 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 23 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It earns credit for disclosing partial-update semantics ('only provide the settings you want to change') and explaining setting behaviors. But as a mutation tool it omits side effects (e.g., conflict between username and delete_username set together), propagation to linked devices, permission requirements, and success/return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, properly front-loaded: purpose first, then usage guidance, then param semantics, then sibling routing. The param explanations partially duplicate schema descriptions, which costs a point, but no sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a write tool with zero annotations, no output schema, and ~77 siblings, the description covers the primary routing and partial-update behavior but leaves gaps: no return-value/confirmation info, no error/conflict behavior, and no mention of two of six parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline 3 applies. The description adds minor framing (the '@username alias' format, delete_username semantics, grouping as privacy/identity settings) but largely restates schema text and omits two params entirely: device_name and unrestricted_unidentified_sender, the latter being the most jargon-heavy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Update Signal account-level privacy and identity settings.' The concrete param explanations (discoverable_by_number, number_sharing, username, delete_username) make the scope tangible and distinguish it from siblings like update_configuration, update_profile, and update_contact, reinforced by the explicit routing sentence.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'All parameters are optional — only provide the settings you want to change' tells the agent this is a partial-update tool, and 'Use update_configuration for messaging settings (read receipts, typing indicators)' names the alternative and the condition. However, it never disambiguates device_name from the sibling update_device, and doesn't route to update_profile/set_pin for adjacent account surfaces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Accept or decline a message request from an unknown contact'. It specifies the resource (message request) and the two possible outcomes (accept or decline). This distinguishes it from sibling tools like 'send_message' and 'block_contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes usage guidance: 'required before replying to strangers'. This tells the agent when the tool must be used. While no explicit when-not-to-use is given, the context is clear for a simple two-option tool. It could be improved by mentioning alternatives like directly blocking, but it's sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines3/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It reveals the tool unblocks the account by submitting a token and captcha, but omits details like error handling or side effects. Minimal but sufficient for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second lists inputs. No extraneous information, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with two params and no output schema, description adequately covers what the agent needs: purpose, input sources. Sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with descriptions. The description adds value by specifying the exact source for the captcha (Signal captcha page URL), which is beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool unblocks the account after a rate limit, with specific verb 'unblock' and resource 'account'. It is distinct from sibling tools, which do not involve rate limiting challenges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool 'after Signal applies a rate limit' and provides instructions for obtaining inputs. It does not mention when not to use, but no sibling alternatives exist for this purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It covers the incremental nature, speed on repeat calls, first-call equivalence to import, and a prerequisite (sqlcipher). However, it does not specify side effects (e.g., whether local data is modified) or discuss safety/read-only aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each conveying essential information: incremental sync, performance on repeat calls, first-call behavior, and a prerequisite. No unnecessary words, front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, behavior, and prerequisites adequately for a simple tool with no parameters and no output schema. It lacks details about what the tool returns after a sync, but given the low complexity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. The description adds no parameter information, but none is needed since there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an incremental sync from Signal Desktop, importing only newer messages. It distinguishes from the sibling import_desktop by noting that on first call it behaves like it, making the purpose specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for repeated syncs by highlighting speed on repeat calls and contrasting with first call behavior (like import_desktop). However, it does not explicitly state when to avoid this tool or name alternatives for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness3/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It 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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior5/5
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.
Conciseness4/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose4/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness4/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior3/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It discloses cross-device sync and markdown rendering behavior, which is meaningful context. It does not detail return values or limitations, but for a self-messaging operation the disclosed behavior 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and compact for a 4-parameter tool. There is minor redundancy between 'synced across all your linked Signal devices' and 'sync to your phone,' but each sentence otherwise earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create-and-send tool with one required parameter and no output schema, the description covers purpose, sync behavior, message formatting, and optional attachments/quoting. It references the prior send_note_to_self result for quote_timestamp, giving enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real value beyond the schema: markdown usage guidance, attachment purpose, and quote_author/quote_timestamp semantics for threading follow-ups. This helps an agent use the parameters more effectively than the field descriptions alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Send a note to yourself via Signal's 'Note to Self' / saved messages feature') and explicitly distinguishes it from normal messaging siblings by targeting the user's own saved messages. There is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete use cases ('saving reminders, bookmarks, or drafts') and advises combining attachments and quotes into one call 'instead of separate calls.' It does not explicitly say when not to use it versus send_message, but the context is clear enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that voting stops, participants are notified, final results become visible, and only the creator can terminate. It also explains the identification method. It does not mention whether the action is irreversible, but 'stopping any further votes' strongly implies finality, and the disclosure is substantial for a tool of this simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a three-sentence paragraph with a logical flow: action, effects, identification, restriction, and parameter selection. Every sentence earns its place, and the main action is front-loaded. It is slightly verbose but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential context for calling this tool: how to identify the poll (timestamp from get_conversation), the required fields (target_author, target_timestamp), the optional but exclusive parameters (recipient/group_id), and the creator restriction. It does not mention return values, but there is no output schema, and the behavior is straightforward enough that nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already described. The description adds meaningful context beyond the schema: it explains that target_timestamp comes from the original poll message (and why it's used as the identifier), and it clarifies the mutual exclusivity of recipient vs. group_id. This adds value over the raw schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (terminate/close) and the resource (a poll you created), and distinguishes it from sibling tools like vote_poll and create_poll by specifying the termination behavior and creator restriction. It also adds the important identification detail (via timestamp, not a separate ID).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: it's for closing a poll you created, and it explains the parameter selection (either recipient for DM polls or group_id for group polls). It also states the creator-only restriction. However, it does not explicitly mention when not to use it (e.g., if you're not the creator) or name alternative tools, though that is implicitly clear from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses effect ('Read' indicator), batching behavior, source of timestamps, and dependency on sender's settings. However, it does not mention error handling or what happens if receipts are not delivered (e.g., silent failure).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, well-structured with front-loaded purpose. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, batching, restrictions, and prerequisite. Lacks return value description (though likely trivial) and error conditions, but sufficient for a simple notification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds limited value. The batching hint ('pass all timestamps in a single call') provides useful context beyond schema, but meaning of timestamps is already clear from schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'send read receipt' and the resource 'a contact', and distinguishes from sibling tools by explicitly forbidding use for group messages and noting that get_conversation handles local marking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: use after reading a conversation with get_conversation, pass all timestamps in a single call to batch, and do not use for group messages or local store marking. Also notes prerequisite about sender's read receipts setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It clearly states it retrieves statistics without side effects, and lists the exact data returned (count, unread count, DB size, date range).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the action and resource. It is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description provides sufficient context about what the tool does and returns. It could arguably mention that data is local, but it already says 'locally stored'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100% trivially. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it gets statistics about locally stored messages, listing specific metrics (count, unread count, DB size, date range). This distinguishes it from sibling tools like clear_local_store or list_conversations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only informational use case. It does not explicitly provide when-to-use or alternatives, but the lack of parameters and the nature of statistics make it clear it's for querying local storage state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the effect (removing from header) and prerequisites but does not elaborate on whether the action is reversible, permissions needed, or if the message is otherwise affected. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and effect. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description together with the schema is complete. It tells the agent what it does, what parameters are needed, and where to get them. No output schema is needed for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, and the description adds meaning by explaining the mutual exclusivity of recipient and group_id, and how to obtain target_author and target_timestamp from get_conversation. This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Unpin a previously pinned message in a DM or group conversation, removing it from the conversation header.' It uses specific verbs and resources, and distinguishes from sibling tools like pin_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: specify recipient for DMs or group_id for groups, and get target_author/target_timestamp from get_conversation. It also references the alternative pin_message. However, it does not explicitly exclude other scenarios or mention 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the name is stored only locally, never sent to the contact, and overrides the contact's profile name in displays. Lacks mention of reversibility or persistence but is adequate for a simple update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, effect, context, and exclusions. Though slightly verbose, every sentence adds value and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully covers what the tool does, its local-only scope, its effect on displays, and provides alternatives. No output schema exists, so the description adequately fills all gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters. The description adds marginal value by explaining the purpose of the name parameter, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets or updates the local display name for a Signal contact. Specifies verb and resource, and explicitly distinguishes from sibling tools like update_profile, block_contact, and remove_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use (adding a human-readable label) and when-not-to-use (for changing own profile, blocking, or removing). Also suggests using list_contacts first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness4/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It explains the delivery mechanism (POST), the trigger (every incoming Signal message), the payload structure (JSON fields listed), the disabling behavior (null), and the persistence side effect (saved to disk, survives restarts). This is rich, non-obvious behavioral detail beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences deliver the purpose, payload, use cases, disabling mechanism, and persistence without wasted words. The core behavior is front-loaded; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-optional-parameter tool, this description is complete: it tells the agent what the URL is for, how the endpoint is invoked, what the payload contains, how to clear the webhook, and that the configuration persists. Nothing needed for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 schema already documents 'url' and the clearing behavior ('Omit or pass null'). The description adds an example destination and relation to Signal, but does not materially extend the meaning of the parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Configure') and resource ('a webhook URL') and clearly defines the behavior: receiving a POST for every incoming Signal message. It distinguishes itself naturally from siblings like get_webhook by describing configuration rather than retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context: 'Use this to connect signal-mcp to n8n, Make, Home Assistant, or any local HTTP endpoint' and explains the disabling case with 'Pass url=null'. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to know when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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.
Conciseness4/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness4/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness4/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the pack is stored indefinitely on Signal's CDN. No annotations provided, but the description adequately covers the non-destructive nature and outcome. Could mention permissions or overwrite behavior, but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, no fluff. First sentence states main function, then input, output, usage guidance. Well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, the description explains input, output URL, indefinite availability, and correct usage. It doesn't cover error handling or rate limits, but is sufficient for a simple upload tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' is described in schema as 'Local path to manifest.json or a zip...' and the description adds context that the manifest describes the pack. Schema coverage 100%, so baseline 3, but the description adds a slight extra nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool packages and publishes sticker packs to Signal's CDN, specifying input types (manifest.json or zip) and output (a signal.art install URL). It distinguishes from the sibling tool add_sticker_pack, which installs packs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (create and distribute custom sticker packs) and when not to (use add_sticker_pack for installation), with a clear alternative mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters3/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines4/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness4/5Is 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.
Completeness5/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses sticker rendering style, error conditions for invalid pack/sticker, and prerequisite actions. Lacks details on response format or rate limits, but adequately 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Five sentences, front-loaded with core purpose, then progressively detailed. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers prerequisites, error conditions, and alternatives. Missing return value description (success/confirmation), but given complexity and lack of output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning: explains pack_id as hex string, sticker_id as 0-based integer, and how to obtain valid values from list_sticker_packs. This goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('send'), resource ('single sticker'), and channel ('Signal contact in a direct message'). It distinguishes from siblings like send_group_sticker 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (expressive image reaction/decoration), when not to use (regular images), prerequisites (list_sticker_packs/add_sticker_pack), and alternatives (send_group_sticker, send_attachment).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses asynchronous nature ('data arrives in the background over the next few seconds') and explains architecture reason. No annotations provided, so description carries the burden. Could mention if any authorization required, but overall clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage guidance, then behavioral note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description fully covers purpose, when to use, async behavior, and exclusion. Complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters. Baseline is 4. Description adds meaning by explaining what the sync entails, compensating for lack of params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool requests a full sync of messages, contacts, and groups from the primary device. Specifies verb (request), resource (sync), and scope (messages, contacts, groups). Distinguishes from sibling tools like receive_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: when list_conversations shows no history, list_contacts returns fewer contacts, or list_groups is missing groups. Also tells when not to use: for new incoming messages, use receive_messages instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavioral traits: resolves delivery block, trusts specific or all known keys, and security implications. 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured and each sentence adds value. Could be slightly more concise, but no redundancy. Front-loaded with purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the effect adequately. References sibling tool list_identities, and covers prerequisites. Does not explain return values or error scenarios, but sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions, but the tool description adds meaningful context: explaining the difference between providing a safety_number vs leaving it blank, and the security trade-off. Adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: trusting a Signal identity key after out-of-band verification. It distinguishes from siblings by referencing list_identities for inspection, and explains the context of safety numbers and encryption.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly indicates when to use (Signal blocks delivery with untrusted identity errors) and when not to use (without verifying the safety number). Suggests using list_identities first, and warns against trusting unverified keys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 the device restriction, the failure mode, and the side effect that the contact is not notified. This goes beyond basic mutation disclosure and covers relevant operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action, followed by essential conditions and alternatives. Every sentence serves a purpose with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no output schema, the description covers the core action, prerequisites, failure behavior, side effects, and related tools. Nothing essential is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter fully with a clear description (E.164 format). The description adds no additional semantic meaning beyond the schema, so the baseline of 3 for high schema coverage is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Unblock a previously blocked Signal contact') and the resource (Signal contact), and it explicitly distinguishes from the sibling block_contact. The verb and object are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when the tool works (primary device) and when it fails (linked devices), including the exact error message. It also names alternatives: use block_contact to re-block and list_contacts to see blocked contacts. This is thorough guidance for selection and invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the linked-device limitation, immediate and persistent effects, and the lack of read-back. Minor omission: doesn't mention potential permission requirements, but overall transparent for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough yet efficient. Each sentence adds distinct information—purpose, constraints, parameter meanings, alternatives. Front-loaded with the primary purpose, and no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 all needed context: what the tool does, when to use it, limitations, parameter semantics, and differentiation from siblings. An agent can call it correctly without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds plain-language explanations of each parameter's effect (e.g., 'read_receipts controls whether Signal tells senders...') beyond the schema's brief descriptions, providing genuine added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb+resource: 'Update Signal account-wide messaging settings.' It names specific sibling tools (update_account, update_profile) to differentiate scope, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (account-wide messaging settings) and when not (profile name/photo, account-level privacy), naming the alternative tools. Also notes the primary-device requirement and failure mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that changes propagate immediately and that remove_avatar must be set to true to clear photo. Does not mention permissions, rate limits, or failure modes, but for a profile update 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-structured sentences, front-loaded with purpose, then parameter details, then usage guidance. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no output schema and no complex dependencies. Description covers main behavioral traits (immediate propagation), parameter semantics, and usage boundaries. Does not specify return value, but for an update tool that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value over schema: explains name is shown to contacts who haven't saved your number, about is bio, avatar_path must be local JPEG/PNG, and remove_avatar clear without new image. Also clarifies all optional. Schema has 100% coverage but description enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool updates the user's own Signal profile, listing specific fields (name, about, avatar_path, remove_avatar). Differentiates from siblings like get_profile, update_device, and update_configuration by explicitly saying what NOT to use it for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context (updating own profile) and when-not-to-use (renaming device, changing messaging settings), naming alternative tools for those cases. Also notes all parameters are optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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.
Conciseness4/5Is 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.
Completeness4/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior4/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness4/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that messages auto-delete, existing messages are unaffected, changes are delivered to all participants, and how to disable (expiration_seconds=0).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action, then efficiently covers effects, special values, and constraints. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers all necessary context: when to use, parameter constraints, common values, behavior on new vs existing messages. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds meaning: explains common expiration_seconds values, the exactly-one constraint between recipient and group_id, and the effect of setting 0.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Set or disable the disappearing-messages timer') and clearly identifies the resource (conversations). It distinguishes from any sibling tool since no other sibling manages expiration timers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use (set or disable timer) and provides common values. It does not explicitly state when not to use, but the context is clear given no similar sibling tools exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses behavior: auto-expires ~15 seconds, stop parameter cancels, silently ignored if recipient disabled typing indicators, only for DMs, and no error returned. No surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with main purpose and each sentence adds useful information. It is slightly long but not verbose, efficient for a 2-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters, no output schema, and no annotations, the description covers all necessary behavioral, usage, and limitation details comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 purpose of the stop parameter (cancel active indicator) and the default behavior. It also clarifies recipient usage context, improving understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sends a typing indicator to a Signal contact. It specifies the verb 'send', the resource 'typing indicator', and distinguishes from siblings by explicitly saying it is for one-to-one DMs only (not groups) and related to before send_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use (before send_message), when to use stop=true (to cancel early), and clear exclusions (not for groups, do not call repeatedly). This helps the agent choose correctly among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters4/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure, and it excels: it reveals the primary-device-only constraint, the failure mode on linked devices, the PIN format (4–20 digits), the use of the PIN for storage key derivation, the 7-day lockout on forget, and a warning against choosing a forgettable PIN. All significant side effects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence contributes: purpose, device constraint, re-registration effect, PIN format, key derivation, lockout consequence, when-to-use, and the alternative tool. It front-loads the primary purpose and flows logically from how it works to the warning. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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, this description is fully complete. It covers what the tool does, when to use it, the only parameter, the failure scenario, side effects, and the recommendation to use remove_pin for reversal. An agent has everything needed to invoke it correctly and understand the impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the pin parameter as '4–20 digit numeric PIN', so schema coverage is 100%. The description adds value beyond that by explaining why the PIN matters (storage key derivation) and the consequence of forgetting it (7-day lockout). This is more than a repeat of the schema, though not a completely new semantic layer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set a Signal Registration Lock PIN), the resource (the Signal account), and the purpose (protect against SIM-swap and unauthorized re-registration). It is unmistakably distinct from siblings like remove_pin and pin_message, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use when you want to harden your account against SIM-swap attacks' and points to remove_pin as the way to disable the lock. It also states a critical precondition: only works on the primary device, with a specific failure message on linked devices, so an agent knows exactly when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool fails on linked devices, triggers SMS/voice code delivery, may require a captcha, and does not switch the number until finish_change_number succeeds. These are non-obvious behavioral traits, and all are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence earns its place: purpose, device restriction, code delivery, next-step call, rate-limit handling, and the ordering constraint. The structure is logical and front-loaded with the core action, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-step migration tool with no output schema, the description covers all necessary operational details: prerequisites, error conditions, parameter usage, the follow-up step, and the captcha workaround. An agent can correctly invoke this tool and know what to expect next.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the voice parameter (requests voice call instead of SMS), the captcha's conditional need (only if Signal demands it), and the E.164 format for number. This goes beyond the schema's brief descriptions, though the schema already covers the basics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Begin migrating') and resource ('your Signal account to a new phone number'), and distinguishes itself from the sibling finish_change_number by framing itself as the first step. The device-requirement clause adds clarity about when it applies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context: only as the primary device, and explicitly routes the agent to finish_change_number immediately after receiving the code. It also warns against calling finish without this tool, and explains the captcha fallback for rate limits. This fully covers usage scenarios and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 the critical failure condition (only works when signal-mcp is primary), the sync behavior (name appears immediately across devices), the limitation (only secondary devices can be renamed), and the non-effect on messaging. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though longer than typical descriptions, every sentence serves a purpose. It front-loads the core action and then logically expands into usage context, constraints, and alternatives without redundancy. The structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of device management (linking, primary vs secondary, failure modes), the description is complete. It covers prerequisites, error conditions, how to get IDs, what it doesn't affect, and alternatives. No missing information an agent needs to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions for both parameters. The description adds valuable context beyond the schema: device_id is a small integer, device 1 is always primary, and the name is the new display name. This enriches parameter understanding, though it doesn't add formatting constraints or new fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renames a linked secondary device on a Signal account, specifying the exact action (rename) and resource (secondary device). It distinguishes from siblings by explicitly contrasting with remove_device (unlink) and update_profile (rename primary account), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use when you want to distinguish between multiple linked devices by a meaningful label.' Also gives when-not-to-use: 'Do NOT use to rename your own primary account — that is done via update_profile.' It directs users to list_devices for IDs and remove_device for unlinking, fully routing to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 vote is delivered via signal-cli and visible in real time, that re-voting overwrites, that partial updates are not supported, and that voting on a terminated poll returns an error. This is comprehensive behavioral disclosure for a simple action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence contributes unique guidance. It front-loads the core purpose, then covers mechanics, identification, and exclusions without redundancy. Slightly long but efficient given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and multiple parameters with dependencies, the description covers all necessary context: how to identify the poll, how to construct votes, the one-of recipient/group_id rule, error on terminated polls, and alternatives. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds substantial meaning: it explains that votes are 0-based indices, that exactly one of recipient or group_id must be provided, and how to obtain target_author and target_timestamp from get_conversation. This goes well beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cast your vote' and the resource 'an active Signal poll in a DM or group conversation'. It explicitly differentiates from siblings by saying 'Do NOT use to create a poll — use create_poll instead' and references terminate_poll, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use ('Use when responding to an open poll in a conversation') and when-not-to-use ('Do NOT use to create a poll'), and names the alternative (create_poll). It also explains the conditions for single-choice vs multi-select and how to identify the poll via target_author and target_timestamp from get_conversation, giving complete routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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.
Conciseness5/5Is 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.
Completeness5/5Given 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.
Parameters5/5Does 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.
Purpose5/5Does 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.
Usage Guidelines5/5Does 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It explains that changes are applied instantly, all members receive notification, admin is required for certain changes, and details the behavior of parameters like add_members (sends invitations) vs remove_members (removes immediately).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise, front-loaded with the main purpose, and every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description is comprehensive: covers all parameter behaviors, side effects, prerequisites (admin), and provides cross-reference to list_groups. It fully compensates for missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description adds significant value: explains add_members sends invitations, remove_members removes immediately, add_admins promotes, remove_admins demotes, expiration_seconds sets disappearing timer (0 to disable), and link_mode options with descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Modify a Signal group's settings, membership, or permissions,' which clearly states the verb (Modify) and resource (Signal group). It distinguishes from sibling tools like create_group (creates) and send_group_message (sends).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Do NOT use to send a message — use send_group_message for that' and advises using list_groups to get the group_id and confirm admin status. Provides clear when-to and 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.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/googlarz/signal-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server