Local MCP
Server Quality Checklist
Latest release: v3.0.377
- Disambiguation3/5
With 241 tools, many serve overlapping purposes (e.g., multiple click and type tools for Chrome, Safari, UI, and web automation). While domain prefixes help, the sheer number and generic tools like fs_list vs. finder_list create ambiguity.
Naming Consistency4/5Most tools follow a pattern of domain prefix + verb + noun (e.g., chrome_navigate, create_note). However, some inconsistencies exist, such as read_email vs. m365_read_email, and the mix of list_* and search_* without a clear distinction.
Tool Count2/5241 tools is excessive for any server. While the server covers many domains, the count overwhelms the user/agent, making it hard to navigate and select the right tool. A more focused scope would improve coherence.
Completeness4/5The tool surface covers a wide range of domains (browsers, email, messaging, files, office, media, etc.) with most CRUD operations present. Minor gaps exist, such as missing update for OmniFocus tasks and limited editing for Office documents.
Average 3.2/5 across 241 of 241 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 8 community issues answered or closed in the last 6 months
- 353 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add related servers to improve discoverability.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates a write operation but discloses no behavioral traits such as file creation, overwrite behavior, or error handling. The lack of parameters also hides how inputs are resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it is underspecified to the point of being unhelpful. Conciseness is wasted when critical information about parameters is absent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool requires specifying a file, cell, and value to write, and there is no output schema, the description is completely inadequate. It provides no information on how to invoke the tool or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description implies parameters are needed (file, cell, value). The description adds no meaning beyond the schema and fails to explain how the tool receives inputs. Schema coverage is 100% but irrelevant because parameters are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'writes a value to a specific cell in an Excel file,' which is clear in verb and resource. However, the input schema has zero parameters, contradicting the implied need to specify file, cell, and value. This mismatch undermines clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like excel_create or excel_read. No context, prerequisites, or alternative suggestions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states basic function; no disclosure of side effects, permissions, rate limits, or how symbols are provided given the empty schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very short but cut off mid-sentence. Lacks completeness. Some value from initial wording but overall poor structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool likely requires symbol input and has no output schema, the description is severely lacking. It does not explain how to specify symbols or what market data is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero properties, but description implies symbols are needed. This contradiction is misleading. Since no param details exist in schema, the description fails to add meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with 'Gets current stock price and market data for one or more symbols' but truncates after '(e.g.', leaving it incomplete. It indicates verb and resource but is vague due to truncation and mismatch with empty schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like 'stocks_get_chart' or 'stocks_search_symbol'. No context provided for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'crops', implying a destructive or transformative operation, but provides no details on whether it modifies the original, creates a new file, or any side effects. No annotations exist to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but incomplete—it ends mid-sentence. It is underspecified rather than concisely complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 a truncated description, the tool is severely incomplete. An agent cannot understand how to invoke it or what result to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, yet the description mentions a target aspect ratio without explaining how it is specified. The description adds no value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts to say it crops a video to a target aspect ratio but is cut off, leaving ambiguity about what exactly it does. It fails to distinguish from sibling tools like video_trim or video_concat.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or comparisons to related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides no behavioral details: e.g., whether it searches locally or live, if connection is required, or what happens if no messages are captured. The claim 'by text' contradicts a schema with zero parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but omits essential information, making it under-specified rather than concise. It could be more efficient while still conveying necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, the description should thoroughly explain the tool's function, scope, and behavior. Instead, it provides only a vague single sentence, leaving the agent without adequate context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description specifies 'by text', implying a text input that does not exist. No parameter-level clarification is provided, and the description does not compensate for the missing parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description restates the tool's name with minimal additional information ('by text'), but fails to clarify how the search works since the input schema has no text parameter. It does not distinguish this tool from sibling tools like search_messages or signal_search_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites (e.g., must be connected to Zalo). The description lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no additional behavioral context in the description, the agent has no information about side effects, whether the action is destructive, or if focus is required. The description is purely functional and incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but incomplete due to trailing 'e.g.' without content. While brevity is valued, this undermines clarity. A proper description should be self-contained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description must provide full context. It fails to define valid key combinations, behavioral expectations, or interaction with other UI tools. The tool is essentially undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so schema coverage is 100%. However, the description fails to explain how to specify a key combination or what keys are accepted. The truncated example ('e.g.') shows the tool expects some input, but no guidance is given, making the parameter semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Sends a key combination' but ends with 'e.g.' without completing the example. The verb and resource are vaguely clear, but the missing example leaves ambiguity about what constitutes a valid key combination, especially given the large set of sibling UI tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use ui_keystroke versus alternatives like ui_type, safari_type, or other browser-specific tools. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/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 fails to mention whether credentials are required, whether a connection state is persisted, whether existing connections are overwritten, or any side effects on other ServiceNow tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified rather than appropriately concise. The single sentence does not earn its place because it conveys no useful information beyond the tool name, offering no structural benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate for an agent to understand the tool's purpose, prerequisites, or impact. There are no annotations, output schema, or contextual clues, making it impossible to safely invoke this tool based on the provided information.
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, so the schema is vacuously complete. Per the baseline rule for 0 params, a score of 4 is appropriate even though the description adds no semantic value beyond the name; there is nothing to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Connect ServiceNow.' is a tautology that merely restates the tool name without specifying what connecting actually entails, such as authentication, configuration, or scope. It does not differentiate from related tools like disconnect_servicenow or other ServiceNow operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, no context about whether this is a one-time setup or per-session action, and no mention of related tools. The agent receives zero instruction on choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits. It claims to search by name/email but lacks parameters, making the tool's actual behavior unclear and potentially misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but under-specified. It lacks necessary details about how to use the tool, making it insufficient for effective use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, an empty input schema, and no output schema, the description fails to provide essential context. The tool's purpose is stated but cannot be realized without parameters, leading to incomplete guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, yet the description implies parameters for name or email. This contradiction means the description adds no value and may mislead an AI agent about how to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it searches the M365 directory for users by name or email, which is specific. However, the input schema has no parameters, creating confusion about how the search is performed. It lacks explicit differentiation from sibling tools like 'search_contacts' or 'm365_search_contacts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'get_m365_person' or 'list_contacts'. No context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description should explain side effects, access requirements, or failure modes. It merely says 'control a native app's interface,' which is extremely vague and non-behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence and there is no wasted prose, but it is under-specified to the point of being useless. It does not convey the tool's actual function, so this is not effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a generic description. For a tool that presumably finds UI elements, the description should at least state that purpose. It is completely inadequate for understanding what the tool does or how to use it.
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 is empty (0 params), and schema coverage is 100% vacuously. With no parameters to explain, the description cannot add parameter semantics, and the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'GUI automation — control a native app's interface' is generic and does not name the specific action 'find element'. It could apply to almost any UI tool, so it fails to distinguish itself from siblings like ui_get_element or ui_read_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description gives no context, prerequisites, or exclusions, leaving the agent without any decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any side effects, prerequisites, or constraints (e.g., whether the window must be visible, what happens if bounds are invalid). This is a significant gap for a tool that modifies window state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single incomplete sentence. While concise, it fails to convey essential information, and the truncation indicates it is not well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (setting window frame) and the absence of an output schema, the description should explain prerequisites (e.g., how to obtain window_id) and the exact behavior. The current description is incomplete and provides minimal context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, yet the description mentions 'window_id' and bounds {x,y,w,h} as parameters. This contradiction between the schema and the description provides no useful guidance. With zero parameters documented, the description adds no value beyond confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it pins a window to fixed bounds, which is a clear verb+resource action. However, the truncated ending and lack of differentiation from sibling tools like 'window_focus' reduce clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use the tool. The mention of 'every take is framed identically' hints at use for consistent recording, but no alternative tools or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims a 'named marker' but the input schema has no parameter for the name, creating a contradiction. Additionally, there are no annotations, so the description fails to disclose important behavioral traits such as side effects or requirements (e.g., active recording must exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it omits critical information about the missing name parameter and usage context, making it insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a misleading description, the tool is severely under-described. The agent cannot infer prerequisites, return value, or behavior when no recording is active.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and is trivially 100% covered, but the description implies a name parameter that does not exist, misleading the agent about how to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'drops a named marker into the active recording's timeline,' which is a clear verb+resource, but the input schema has no parameters, contradicting the notion of a 'named' marker. This inconsistency makes the purpose less clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or context for using the marker tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the action but does not disclose behavioral traits such as success/failure behavior, prerequisites, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single incomplete sentence, poorly structured and not concise in a useful manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and an incomplete description, making it inadequate for an AI agent to understand how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the incomplete description does not explain how recipient or message content is specified, failing to add value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends an iMessage via the Mac's Messages.app, but it is incomplete (cuts off) and lacks parameter details, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like signal_send_message or whatsapp_send_message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the basic action. No mention of required connections, output format, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits essential details, making it under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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 fails to provide crucial context such as how the chat is determined, what the output looks like, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, yet the description implies a 'specific Signal chat' without providing a way to specify it. This misalignment reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it reads messages from a specific Signal chat, which is clear, but the input schema has no parameters to specify which chat, creating ambiguity. This undermines clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like signal_search_messages or signal_list_chats, nor any context on prerequisites (e.g., needing to connect first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description contradicts the empty input schema by claiming it retrieves contacts 'by name or ID', but no parameters exist to supply those values. This is a serious inconsistency that undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, but its accuracy is compromised, making it less valuable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without explicit parameters or output schema, the description fails to explain how the agent should specify the contact or what the response contains, leaving critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite a zero-parameter schema (baseline 4), the description asserts parameters that are not defined, causing confusion rather than adding meaning.
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 clearly states it retrieves a single contact from the Mac's Contacts app by name or ID, distinguishing it from sibling tools that list all contacts or perform broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_contacts' or 'list_contacts', nor are any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims search by name, email, or phone number, but the input schema has zero properties, making it impossible to provide these inputs. This contradiction misleads the agent about the tool's actual behavior. No annotations are provided to clarify.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is under-specified given the missing parameters, making it less useful. It could be improved with additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, yet the description implies search requires input. This incompleteness means the tool cannot be used as described. Context signals indicate zero parameters, so the description must explain how to perform the search, but it fails to do so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%, but the description implies parameters for name, email, or phone number. This contradiction adds no value and misleads. The description should clarify how search queries are specified, but it doesn't.
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 clearly states it searches the Mac's Contacts app by name, email, or phone number, providing a specific verb and resource. However, it does not differentiate from sibling tools like 'get_contact' or 'list_contacts', which have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'list_contacts' or 'm365_search_contacts'. There is no 'when not to use' or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not explain how the search behaves (e.g., case sensitivity, matching logic, or return format). The empty input schema contradicts the described functionality, severely undermining transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy, but it is too brief given the critical gap between its claims and the actual input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple in concept but the description fails to resolve the contradiction with the schema. An agent cannot determine how to perform a search without input parameters, making the definition incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies parameters for name or note content, but the input schema has zero parameters. This misleading mismatch confuses the agent about how to invoke the tool.
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 clearly states that the tool searches OmniFocus tasks by name or note content, which distinguishes it from list_omnifocus_tasks. However, the input schema has no parameters, so the purpose is overshadowed by the inconsistency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives like list_omnifocus_tasks or other search tools. The description lacks context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that a new file is created, but does not disclose how videos are selected, valid formats, output location, or any other behavioral traits. With no annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is abruptly cut off, making it incomplete. It lacks proper structure and is not concise due to the truncation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of video concatenation and the lack of parameters or an output schema, the description is severely inadequate. The agent has no way to understand how to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description does not explain how to specify which videos to concatenate. Schema coverage is 100% by default, but the description adds no meaning; the agent cannot infer how to invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts to state the purpose clearly - stitching videos end-to-end into a new file. However, it is cut off (ending with 'e.g.'), leaving the example incomplete, which slightly diminishes clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like video_trim or video_blur_region. Sibling tools exist for other video operations, but no differentiation is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it deletes an event but does not disclose consequences (irreversible, permissions needed, behavior on non-existent ID). Lacks critical behavioral context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste, but is too short given the significant gap between description and schema. Overly concise to the point of being incomplete and contradictory.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description should provide context on how to obtain the event ID and what the result looks like. It fails to do so, making it incomplete for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no properties, yet description implies an 'ID' parameter. This is a contradiction: the tool cannot delete by ID without that parameter. The description fails to add meaning beyond the schema and actually misleads.
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?
Clearly states the verb 'deletes' and resource 'event from Mac's Calendar app', and specifies the method 'by ID'. Distinguishes from sibling tools through the name, but could be more explicit about what 'by ID' means.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'create_calendar_event' or 'update_calendar_event'. No prerequisites (e.g., need to obtain the event ID from a list tool) or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details beyond 'create'. It fails to disclose whether events can overlap, require authentication, or have side effects like sending invitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it omits essential information. Conciseness is not beneficial when it sacrifices critical details needed for correct usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is grossly incomplete for a tool that requires multiple parameters and handles complex calendar operations. No output schema exists, and the empty input schema provides no guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty despite the need for parameters such as subject, start time, and duration. The description offers no hints about required or optional parameters, leaving the agent completely uninformed.
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 clearly states the verb (Create) and resource (calendar event in Microsoft 365 / Outlook), which distinguishes it from generic 'create_calendar_event' sibling. However, it could be more precise about whether it handles all event types or only simple events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'create_calendar_event' or 'update_calendar_event'. The description does not mention prerequisites, context, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details beyond the core action. It does not disclose how text is input (e.g., keystroke simulation), whether existing text is replaced, or error conditions. With no annotations, this leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but omits essential information (parameters, prerequisites). It is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description fails to provide a complete picture. It does not cover how to specify the text, prerequisites, or expected behavior, making it insufficient for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, yet the description implies a text parameter is needed. This is a critical inconsistency; the description does not explain how the text to type is provided, making the tool difficult to invoke correctly.
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 action ('types text') and target ('form field (input/textarea)') with a scope ('on the current page'), effectively distinguishing it as a web-focused typing tool. However, it does not differentiate from browser-specific siblings like chrome_type or safari_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., chrome_type, safari_type, ui_type). There is no mention of prerequisites (e.g., element must be focused) or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Connect Todoist.' It does not disclose whether this initiates an OAuth flow, stores credentials, requires user interaction, or has side effects. The agent is left without any awareness of what will happen when invoking this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, but it is under-specified for a connection tool. It earns its place as a clear subject-verb statement, but lacks critical context about the connection process. It is not verbose, but it is incomplete, so it does not merit a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no annotations, no output schema, and no parameters, the description is the only source of information. 'Connect Todoist' does not explain the connection flow, success/failure conditions, required authentication, or what happens after connection. This is completely inadequate for an agent to safely and correctly invoke the 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 tool has zero parameters, so the schema is fully covered by virtue of being empty. The baseline for 0-parameter tools is 4, and the description does not need to explain parameters. No additional parameter semantics are required.
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 'Connect Todoist' uses a specific verb and resource, making it clear that this tool establishes a connection to Todoist. It distinguishes from siblings like disconnect_todoist and connect_m365_account by naming the target service. However, it does not elaborate on what 'connect' entails, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as disconnect_todoist or other connection tools. No context is provided about prerequisites, when a user would need to connect Todoist, or how it relates to the many Todoist task management tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states 'Creates an event.' It does not explain whether the tool opens a dialog, saves immediately, requires Mac Calendar to be running, or what default values are used. Behavioral traits are completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but at the cost of important details. It front-loads the core action but fails to earn its place by omitting critical usage and behavior information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and missing annotations, the description is severely incomplete. It does not explain what happens when the tool is invoked (e.g., creates a blank event, requires user input, or returns an object) or any return value.
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 no parameters, so schema coverage is 100% trivially. The description adds no parameter information because none exist. Baseline score 3 is appropriate as the description provides no additional meaning.
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 clearly identifies the tool as creating an event in the Mac's Calendar app, distinguishing it from other calendar tools like m365_create_event and update_calendar_event. However, the lack of parameters leaves ambiguity about what kind of event is created (e.g., blank, default, or based on context).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., m365_create_event for Outlook). There are no preconditions or exclusions mentioned, leaving the agent without context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It mentions caching but does not explain permissions, rate limits, or behavior on cache miss. This is insufficient for a 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded, but overly terse. It lacks necessary details about parameters or behavior, trading completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input parameters, no annotations, and no output schema, the description must compensate significantly. It fails to explain how to specify a page, what the markdown includes, or error handling. Completely inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description implies the tool reads a specific page. It does not clarify how the page is identified (e.g., via context, implicit selection), creating confusion. Schema coverage is 100% but the description adds no value.
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 clearly states the verb (reads), resource (Notion page from local cache), and output format (markdown). However, it does not distinguish from sibling tools like notion_open_page or notion_search, lacking differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., notion_search, notion_open_page). No context or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only adds 'recursive' behavior. It fails to disclose that no search parameters (name, directory) can be passed, contradicting the semantics implied by the description.
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 sentence, 9 words, efficient. But the lack of details about the missing parameters reduces its practical value. Could be slightly longer to clarify the discrepancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no parameters and no output schema. It does not explain how the agent can specify a search term or directory, or what the tool searches by default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, baseline is 3. However, the description introduces concepts (name, directory) not reflected in the schema, misleading the agent about what can be specified. No parameter documentation exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (search files by name) and resource (OneDrive directory) with recursive behavior. However, the input schema has no parameters, making the described functionality impossible to specify via arguments, which confuses the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like onedrive_list_files or onedrive_file_info. The description does not mention prerequisites, scope, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'writes' without disclosing whether it overwrites, creates, or appends, or what happens if the file does not exist. It lacks essential behavioral details for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is too concise to be useful. It omits necessary details about file identification and content, making it inadequate for an agent to use the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete given the tool's complexity and lack of parameters. It does not specify the target file or content source, leaving critical gaps. An agent cannot determine how to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the description adds no meaning beyond the empty schema. It fails to explain how the target file and text content are specified, which is critical for correct invocation.
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 clearly states the action ('Writes text content') and resource ('file in OneDrive'), distinguishing it from sibling tools like onedrive_read_file or onedrive_delete_file. However, it does not specify how to identify the target file, which is a minor omission.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites or context for usage are provided. The tool is the only OneDrive write tool, but the description does not clarify when writing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It implies a read-only operation (reading full content) but does not address permissions, error states, or the return value format. The contradiction about parameters further reduces clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise. However, it omits critical details (e.g., how to specify the note) and is not well-structured to front-load essential information given the conflict with schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain what 'full content' includes and any prerequisites. The parameter mismatch makes the tool ambiguous, leaving the agent without enough context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (100% covered), but the description claims the tool operates 'by name or ID'—suggesting missing parameters. This is misleading and contradicts the schema, providing no useful semantic meaning beyond what the bare schema offers.
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 clearly states the tool reads the full content of a note, distinguishing it from sibling tools like create_note, update_note, or search_notes. It mentions the key identifiers 'name or ID', though this conflicts with the empty input schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_notes or list_notes. The description offers no contextual cues to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 fails to disclose any behavioral traits such as authentication needs, idempotency, or whether comments are appended or overwritten.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While very concise, the description omits essential information, making it insufficient for proper tool usage. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no output schema, and no annotations, the description must compensate. It does not, leaving critical gaps about how to specify the incident and what constitutes a valid comment or work note.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, but the description implies parameters (incident identifier, comment text) without explaining how they are provided. This undermines the agent's ability to invoke the tool correctly.
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 clearly states the action (add) and the resource (comment or work note to a ServiceNow incident). However, it does not specify how the incident is identified, which is a gap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other ServiceNow tools like servicenow_update_incident. No context on prerequisites or whether the incident must be previously selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose how the symbol is specified (schema has no parameters) or what data is returned (no output schema). It contradicts the schema by implying a parameter that doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While concise (one sentence), the description omits critical information needed to use the tool correctly. It is under-specified rather than effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks parameters and output schema, and the description fails to explain how to specify the stock symbol or what the output contains. This is incomplete given the tool's apparent requirement for a symbol.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so the description should clarify how the tool obtains the symbol. Instead, it misleads by stating it uses a stock symbol without a corresponding parameter. Baseline for 0 params is 4, but this misrepresentation reduces the 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 it gets historical price data for a stock symbol. This distinguishes it from sibling tools like stocks_get_quote (current price) and stocks_search_symbol (symbol lookup).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that it requires prior knowledge of a symbol or that stocks_search_symbol should be used first for symbol lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as authentication requirements, rate limits, or what happens on failure. The tool's behavior is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it lacks necessary details to be useful. It is underspecified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and no output schema, the description is severely lacking. It does not mention prerequisites, targeting mechanism, or return value, making it inadequate for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, and the description does not explain how to specify the destination (chat/channel ID) or message content. This is a critical omission for a send-message tool.
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 clearly states the action (sends a text message), resource (text message), and destination (Microsoft Teams chat or channel). However, it does not differentiate from the sibling tool 'teams_send_channel_message', which suggests possible overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'teams_send_channel_message' or 'send_message'. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'optimized looping GIF' and optional slice but does not disclose side effects (e.g., file output, temporary files) or requirements (how is video specified?). Insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise but omits critical details like how to specify the video. Not maximally efficient as it lacks front-loaded key info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 is too sparse. It does not explain how to provide the video source or what the output format details are. Incomplete for a tool with this functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters, yet description implies a [start_ms,end_ms] slice parameter. This is a contradiction: the description adds misleading information beyond schema. Baseline for 0 params is 4, but the contradiction warrants a 1.
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 clearly states the tool exports a video or a slice to an optimized looping GIF, with a specific use case (README/social). It distinguishes from video_trim and other siblings through its focus on GIF format and optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The mention 'for README/social' implies a context but does not provide exclusion criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states that the tool trims and creates a new file, but fails to mention what happens to the original, output format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it ends abruptly with 'e.g.' without completing the thought. It is concise but not fully structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool likely requires input parameters (time ranges), the empty schema and incomplete description make it impossible for an agent to invoke correctly. There is no output schema, and the description lacks details on file handling or result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description implies time ranges in milliseconds are needed. This contradiction means the description fails to provide actual parameter semantics, making the tool unusable as specified.
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 clearly states that the tool trims a video to one or more time ranges and concatenates them into a new file. However, it ends with 'e.g.' without providing an example, and it does not differentiate from the sibling 'video_concat' tool beyond implying trimming vs concatenation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like video_concat or video_export_gif. There are no usage conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It mentions running arbitrary JavaScript, implying potential destructive actions or side effects, but provides no safety warnings, no details on session impact, and no explanation of return value format beyond 'last expression's value'. This is insufficient for safe execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. However, it omits essential details (e.g., how to provide the JavaScript code), making it under-specified. While no words are wasted, the lack of completeness reduces its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is conceptually simple but the description fails to cover critical aspects: no input schema for the required JS code, no output schema, and no explanation of return value structure. This leaves the agent unable to correctly invoke the tool without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, yet the description says the tool runs arbitrary JavaScript. This implies a critical missing parameter (the JavaScript code), contradicting the schema. The description adds no meaning to the empty schema and actively misleads by suggesting an input that isn't defined.
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 clearly states it runs arbitrary JavaScript and returns the last expression's value, providing a specific verb and resource. However, it fails to differentiate from similar sibling tools like chrome_evaluate_js and safari_evaluate_js, which also evaluate JavaScript in browser sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives (e.g., browser-specific evaluate JS tools). There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description only states 'reads messages' without disclosing behavioral traits such as whether messages are marked as read, chat selection constraints, or rate limits. The burden is high due to missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but vague. It lacks front-loading of critical information, and the term 'specific' is unclear without corresponding parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complexity is low, but no output schema exists. The description fails to explain what the returned messages include (e.g., content, metadata). For a read tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters (100% coverage), so baseline is 4. However, the description mentions 'specific WhatsApp chat,' implying a parameter that doesn't exist, contradicting the schema. This contradiction lowers the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool reads messages from a specific WhatsApp chat, but does not specify how to identify the chat. With no parameters in the schema, the concept of 'specific chat' is unsupported, creating ambiguity. It distinguishes from siblings like 'whatsapp_search_messages' but not clearly from 'read_messages'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'whatsapp_list_chats' or 'whatsapp_search_messages'. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the basic action without explaining what 'recommended' means, the output format, side effects (e.g., network calls), or 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it includes an unfulfilled promise (filtering) that misleads. It could be improved by aligning with the actual schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, output schema, or annotations, the description is insufficiently complete. It fails to specify what the tool returns (e.g., list of server details) or any constraints, leaving the agent underinformed.
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?
There are no parameters, so the baseline is 4. However, the description mentions filtering by country or specialty, which does not exist in the schema, mildly reducing value. It adds no meaningful param info beyond the schema's emptiness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get recommended NordVPN servers by country or specialty,' which identifies the resource (servers) and suggests filtering, but the input schema has no parameters, creating a mismatch. The mention of 'by country or specialty' implies functionality not supported by the schema, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like nordvpn_status or nordvpn_diagnose. The description does not specify context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the function but omits critical behavioral traits such as required permissions, whether the operation is reversible, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence without waste, but it lacks any structural elements like usage context or bullet points. It is minimally adequate in length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of output schema or annotations, the description is severely incomplete. It does not describe return values, error conditions, or prerequisites, making it nearly unusable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, implying an impossible tool (sending a message without any parameters). The description does not clarify this paradox or explain how the tool determines the channel or message content. Schematically 100% covered, but the coverage is meaningless.
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 clearly states the action ('sends a text message') and target ('to a Microsoft Teams channel via Graph API'). It is specific enough to understand the tool's core function, though it does not differentiate from the sibling tool 'teams_send_message' which likely targets individual chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives. The sibling 'teams_send_message' could serve a similar but distinct purpose, but the description offers no distinction or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description lacks behavioral details: what fields can be updated, whether the operation is reversible, or any side effects. The empty input schema suggests potential incompleteness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly terse. It front-loads the purpose but omits necessary detail, making it borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an empty input schema, the description is severely incomplete. It does not specify how to identify the reminder, what fields are updatable, or the expected outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so the description adds no meaning. Even with 100% schema coverage (empty schema), it fails to clarify how to specify which reminder to update or what values to change.
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 clearly states the action (Update) and resource (existing reminder in Reminders.app). It distinguishes from siblings like create_reminder, delete_reminder, and complete_reminder, though no further detail is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites or context for when updates are appropriate, such as needing a specific reminder identifier or list membership.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It mentions inbox and Apple Mail but does not disclose if the operation is read-only, destructive, or side effects. Lacks details on return format, count, ordering, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but truncated, making it incomplete and not concise. Every part should be intentional; the cut-off harms structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description should fully explain the tool. It does not due to truncation, leaving the agent without complete guidance.
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?
No parameters exist; schema coverage is 100% vacuously. The description does not need to add param info, but it should explain output behavior. The truncated text fails to fully leverage the opportunity, hence a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description mentions 'see or triage their inbox on this Mac (Apple Mail)', giving a specific verb+resource+scope. However, the description is truncated, reducing clarity. Differentiates somewhat from siblings like search_emails or read_email.
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?
States 'use this when the user wants to see or triage their inbox', giving a clear context for use. But no explicit when-not or alternative tools are mentioned, and the truncation leaves ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 of transparency. It only states the tool reads email content but does not disclose whether it marks emails as read, fetches attachments, or has other side effects. This leaves significant ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is truncated, making it incomplete. It fails to be concise because it does not fully convey the tool's purpose or requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain return format, attachment handling, and limitations. It only vaguely mentions 'full content'. The description is insufficient for a tool that likely returns complex email data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description implies a required message ID. This contradiction between the schema and description is misleading. The description adds no useful parameter information and instead introduces confusion.
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 clearly states the tool is for getting full content of a Microsoft 365 email, and it distinguishes from sibling tools like m365_list_emails (list only) and m365_reply_email (reply). However, the description is truncated, reducing clarity.
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 mentions using the tool when the full content is needed and implies a prerequisite (message ID from m365_list_emails). But it does not specify when not to use it or mention alternatives, providing only basic guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool searches contacts but does not disclose key behaviors: whether a query is required, how results are returned, or any side effects. The mismatch between description and schema further reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise. However, it is misleading due to the parameter mismatch, and the structure is minimal but not well-formed for agent understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameters and output schema, the description is insufficient. It does not explain how to provide search input or what the output looks like, making it incomplete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 3. However, the description adds misleading information by mentioning search criteria that are not present in the schema. It does not meaningfully clarify parameters beyond the schema, and the inconsistency is detrimental.
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 clearly states the action (search contacts) and the target (Microsoft 365 address book), and mentions search criteria (name, email, company). However, it does not distinguish from sibling tools like 'search_contacts' or 'list_contacts', which may have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. More critically, it mentions search criteria that are not captured in the input schema (which has no parameters), creating a mismatch that misleads the agent about how to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only states the basic operation. It does not mention whether overwriting occurs, if authentication is needed, or any side effects. The lack of detail fails to inform the agent of important behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks necessary detail. It is front-loaded but too sparse to be effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description should explain how the move/rename is specified (e.g., via context or side effects). It fails to provide a complete picture, leaving the agent unable to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, which is surprising for a move/rename operation. The description does not explain how to specify source or destination, nor does it clarify that no parameters are needed (e.g., if it uses current context). It adds no meaning beyond the empty 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 ('moves or renames') and the resource ('a file/folder within OneDrive'), making the purpose unambiguous. It distinguishes from siblings like onedrive_write_file (which writes content) and onedrive_delete_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like onedrive_write_file or onedrive_delete_file. The description does not mention use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'Installs a SKILL', which indicates a write operation. No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not explain any side effects (e.g., whether it replaces an existing skill), required permissions, or the state after installation. This lack of detail results in low transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of a single incomplete sentence. While brevity is valued, the truncation suggests it is not intentionally concise but rather cut off. Essential information is missing, and the structure does not effectively front-load key details. This is under-specification rather than concise communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description must provide complete context. It fails to explain what 'install' means, what the user should expect as output, how to obtain the skill_token, or any prerequisites. The truncated ending further contributes to incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description instructs the user to 'pass the skill_token from their recipe_export'. This is a direct contradiction, as there is no parameter to accept that token. The agent receiving this tool definition would be misled into thinking a token parameter exists, making this dimension score very low.
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 explicitly states that the tool 'Installs a SKILL someone shared with you', which clearly identifies the verb (install) and resource (shared skill). It also references 'recipe_export', distinguishing it from other recipe tools like recipe_install or recipe_discover. However, the truncation at the end slightly reduces clarity, as it appears to be an incomplete sentence.
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 that this tool is used when someone shares a skill via recipe_export, providing some usage context. However, it does not explicitly state when not to use it or compare it to alternatives like recipe_install. Given the numerous sibling recipe tools, more explicit guidance would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral details, but it only states the action. It doesn't explain what happens if the list doesn't exist, whether the operation is reversible, or what the response is. This leaves critical safety and success/failure behavior undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundancy, but it omits essential context such as required inputs and behavior. It is concise but arguably too sparse for a meaningful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool description lacks information about how to specify which reminder list to rename and what new name to use, and there are no annotations or output schema to fill the gap. The agent cannot correctly invoke the tool based on this description alone.
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 there is no parameter information to elaborate. Under the '0 params = baseline 4' guideline, the description's minimal mention is sufficient for this dimension, though the lack of required inputs is a broader usability issue.
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?
Clearly states the action ('Renames') and the object ('existing Apple Reminders list'), differentiating it from create/delete/get siblings. The term 'folder' in the name versus 'list' in the description introduces a minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus other reminder tools, no prerequisites (e.g., list existence), and no exclusions. The sibling set includes related tools like create_reminder_list and delete_reminder_folder, but no alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It does not disclose authentication needs, error handling (e.g., incident not found), or return format. The phrase 'full details' is vague. More context is needed for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource. However, important information is missing, making it under-specified rather than optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a parameter mismatch, the description is incomplete. The agent lacks details on how to invoke the tool correctly (missing required inputs) and what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no properties, yet description implies parameters (number or sys_id). This mismatch reduces clarity. Description adds meaning beyond the empty schema, but the lack of formal parameters limits usefulness and may confuse the agent.
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 clearly states the tool retrieves full details of a specific ServiceNow incident by number or sys_id. It distinguishes from sibling tools like servicenow_search_incidents and servicenow_list_my_incidents. However, the input schema has no parameters, creating ambiguity about how to specify the incident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings. Does not mention prerequisites (e.g., must connect to ServiceNow first), exclusions, or context for use. The description only states what the tool does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool 'updates fields' but the input schema has zero properties, meaning no way to specify which incident or what values. This contradicts expected behavior and provides no insight into side effects, overwrite vs merge semantics, or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 12 words that immediately states the purpose and key fields. No redundancy or filler; front-loaded for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description fails to specify how to identify the incident (e.g., sys_id, number), valid values for the listed fields, or that no parameters are accepted. The absence of output schema and behavioral details leaves the agent without enough information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists fields (state, priority, assignment) implying parameters, but the input schema is empty. Schema coverage is trivially 100% only because there are no parameters defined. This mismatch means the agent cannot correctly invoke the tool as described.
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 'Update' and the resource 'existing ServiceNow incident', listing example fields (state, priority, assignment). It distinguishes from sibling tools like create, get, list, search, and add_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives (e.g., servicenow_create_incident for new incidents, servicenow_get_incident for viewing). Missing prerequisites such as the need for an existing incident ID and required permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present and the description merely restates the operation. It does not disclose workspace scope, channel filtering, match behavior, authentication requirements, or result characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. However, it is under-specified: there is room for meaningful detail without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no annotations, no output schema, and an empty input schema, this description is far too sparse. It omits how the search query is supplied, what scope is searched, and what the response contains.
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 of 4 applies. The description adds no parameter information, but none is required given the empty schema.
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 uses a clear verb and resource ('Searches Slack messages'), making the tool's basic purpose understandable. It differentiates itself from sibling search tools by explicitly scoping to Slack, though it doesn't fully distinguish among Slack-specific message tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like search_messages, teams_search_messages, or slack_read_channel_messages. No context, exclusions, or alternative conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description fails to disclose behavioral traits such as whether the tool is destructive, required permissions, or rate limits. It only states it sends a file, which implies mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it lacks structure and front-loading of critical information like required inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too brief given the tool's complexity (involves file I/O and messaging). No output schema or annotations exist, making it incomplete for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0 parameters in the schema, the description implies a file attachment and chat context, but no parameters are defined to specify these. The description adds no semantic value beyond the empty schema.
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?
Description clearly states it sends a file attachment to a WhatsApp chat. However, it does not differentiate from the sibling 'whatsapp_send_message' or specify file types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'whatsapp_send_message' for text). No prerequisites mentioned (e.g., must be connected via 'whatsapp_connect').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The truncated description lacks disclosure of behavioral traits such as file location requirements, format specifics, or error conditions. Carries the full burden but fails to deliver.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single truncated sentence. It is not appropriately sized; the truncation indicates poor structure and incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and a truncated description. The tool's complexity is low, but the description fails to provide complete context about return values or operation details.
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 zero parameters, the description does not need to add parameter meaning. Schema coverage is 100% trivially, so baseline is appropriate at 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates it reads transcript/captions from a local Zoom recording, but is truncated, leaving ambiguity about the exact artifacts. It is a specific verb+resource but incomplete, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like zoom_list_recordings. The description does not provide context for appropriate use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states the action 'marks as complete' but fails to disclose potential side effects, such as whether the task must be active, if it's irreversible, or any other 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is short and to the point. It conveys the core purpose without extraneous information, though it lacks structural elements like bullet points or sections.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, and the contradiction between description and input schema, the description is severely incomplete. It does not explain how to provide the task ID or name, leaving the agent unable to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, yet the description implies parameters ('by task ID or name'). This contradiction means the description does not align with the schema, providing misleading information. With 0 parameters and no compensation for missing schema details, this is a critical flaw.
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 (marks complete), the resource (OmniFocus task), and the identification method (by task ID or name). It effectively distinguishes from sibling tools like create_omnifocus_task or list_omnifocus_tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, side effects, or any context for choosing this tool over others like complete_reminder or todo_complete_task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 that only empty folders can be deleted, which is useful, but it omits whether deletion is permanent, what happens on failure, whether files go to trash, and what sync side effects occur. This is insufficient for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but visibly incomplete, ending mid-clause with an em-dash and no continuation. It is under-specified rather than concise, and the missing remainder likely contains essential context about the synced Drive path.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description does not cover return values, failure modes, target identification, or safety caveats. The only edge-case information is the 'empty folder' restriction, which is not enough to let an agent invoke this confidently.
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 zero parameters, so there is nothing for the schema to document. However, for a delete operation, the absence of a target parameter is conspicuous, and the description never explains how the file or folder to delete is identified. The description adds little meaning beyond the tool's name.
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 uses a specific verb ('Deletes') and identifies a clear resource ('a file or an empty folder') and scope ('synced Google Drive folder'). This distinguishes it from OneDrive or local delete tools by domain, though it doesn't explicitly name what it is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool over alternatives, no mention of prerequisites, and no exclusion criteria beyond the 'empty folder' restriction. The truncation also cuts off the contextual clause, leaving the intended usage implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It fails to mention whether reading marks the email as read, requires permissions, or works offline. The description only states the input condition, not the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is truncated (ends with 'message ID fr...'). As presented, it is incomplete, reducing its effectiveness. A full sentence would score higher.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is the sole source of context. It fails to explain the required input (message ID) properly due to schema mismatch, and does not describe the return value or side effects. The tool is simple but the description is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies a 'message ID' parameter is required, but the input schema is empty (no parameters). This is a serious inconsistency: the description suggests an input that the schema does not define, which would confuse an AI agent. With 0 parameters and 100% schema coverage, the description should not add parameter semantics, but it misleadingly does.
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 clearly states the tool reads the full content of an email from Apple Mail, distinguishing it from list_emails (which lists headers) and search_emails. The verb 'read' combined with 'full content' makes 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description begins with 'Use this when the user wants the full content of an email', which provides a clear when-to-use. However, it does not mention when not to use it or contrast with alternatives like list_emails or search_emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must inform behavioral traits. It only states that a recipe is saved, but does not disclose whether it overwrites, requires authentication, has side effects, or any rate limits. The cut-off sentence fails to add context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single incomplete sentence ('to this...'). It lacks front-loading of critical info and is not well-structured. Even if complete, it would be minimal, but the truncation makes it ineffective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 should comprehensively explain the tool's operation. It fails to specify how to input the recipe, what the output is, or any constraints (e.g., naming rules, size limits). The cut-off text exacerbates this gap.
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 is empty (no parameters), and schema description coverage is 100%. The description mentions a 'named recipe' with parameters, but does not explain how the recipe is provided (e.g., via context or a separate mechanism). Since there are no formal parameters, the description could clarify the implicit input; it does not, leaving ambiguity.
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 clearly states the tool saves a reusable SKILL (recipe) with explicit definition of a recipe as an ordered sequence of LMCP tool calls with parameters. It is specific about the resource and action, and the name 'recipe_save' aligns with sibling family. However, the description is cut off at 'to this...', slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use save versus related tools like recipe_import, recipe_install, or recipe_run. The description does not mention prerequisites, contexts, or alternatives, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for conveying behavioral traits. It does not disclose permissions, side effects, or what happens if a recording is already in progress. The description lacks essential behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise but overly terse. It could include more detail without being verbose, such as mentioning default behavior or how to specify the target. The structure is acceptable but lacks necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameters, the description should provide more context about recording behavior, resolution settings, or constraints. It is insufficient for an agent to understand the tool's full usage and implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, but the description mentions recording 'a display, window, or region,' implying the need for target selection, which is not reflected in the schema. This inconsistency undermines clarity. Baseline of 4 for zero parameters is not warranted due to misleading information.
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 function: 'Begins a screen recording (ScreenCaptureKit) of a display, window, or region.' The verb 'begins' is specific, and it identifies the resource (screen recording) and targets (display, window, region). It distinguishes itself from sibling tools like screen_record_status and screen_record_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as screenshot_capture or video recording tools. There is no mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral transparency burden. It only states the action (search) and fields (keyword, number, caller) but does not disclose pagination, rate limits, authentication requirements, or return format.
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 concise sentence with no extraneous information. It is front-loaded and efficient, but the lack of detail reduces its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or annotations, the description fails to explain return values, result format, or any processing details. For a search tool, this is incomplete. The empty input schema exacerbates the lack of contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties despite the description mentioning search by keyword, number, or caller. This contradiction means the description adds no parameter meaning; in fact, it misleads by implying parameters exist. Schema coverage is 100% but empty, so the description fails to compensate.
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 clearly states it searches incidents by keyword, number, or caller, which distinguishes it from sibling tools like servicenow_get_incident (single incident) and servicenow_list_my_incidents (own incidents). However, it could be more specific about the search scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., servicenow_get_incident for specific incident, servicenow_list_my_incidents for personal incidents). The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It discloses the optional focusing step but is silent on error behaviors, support for special keys, input validation, or what happens if no control is focused. Additionally, it references 'element_ref' as an input, but the schema defines no parameters, creating inconsistency that undermines transparency.
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 sentence and efficiently conveys the core action. However, the mention of 'element_ref' without schema backing clutters the clarity. It earns a slight penalty due to this ambiguity but remains relatively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and an empty input schema, the description should be more comprehensive. It lacks explanation of return values, input format for text, error conditions, and the nature of the focused control. Critical details are missing, making the tool hard to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters (100% coverage), so baseline is 3. The description adds little positive meaning—it mentions 'element_ref' which does not appear in the schema, potentially misleading the agent. It does not clarify what text to type or how to specify it, which is essential for a typing tool.
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 clearly states the action ('types text') and resource ('focused control'), and mentions an optional preliminary focus step. However, it does not differentiate from sibling tools like chrome_type, safari_type, or web_type, which also type text. The lack of distinction limits clarity for an agent deciding between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., chrome_type, ui_keystroke). The description does not specify prerequisites, such as requiring a focused control, or mention cases where another tool should be preferred. This leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 does not disclose side effects, required permissions, error behavior (e.g., event not found), or that it modifies calendar data. It only says 'updates an existing event' without elaboration.
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 sentence, concise and front-loaded. However, it is under-specified given the missing parameters and behavioral details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is insufficient for a mutation tool with no output schema and no annotations. It fails to specify which fields can be updated, the input format, or what the response looks like. The missing ID parameter is a critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, yet the description implies an ID parameter ('by ID'). This is misleading and a contradiction. Schema coverage is 100% (empty), so the description adds no value and actually creates confusion.
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 ('updates'), resource ('existing event in Mac's Calendar app'), and method ('by ID'). It distinguishes from sibling tools like create_calendar_event and delete_calendar_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an event ID from list_calendar_events) or scenarios where other tools like create_calendar_event are more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action. It does not mention side effects, required authentication, error handling, or any limitations. The implication of creating a group is clear, but no additional transparency is provided.
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, front-loaded sentence that is concise and easy to parse. It wastes no words, though it could benefit from additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter definitions, the description is too sparse. It omits critical context such as prerequisites (e.g., whether WhatsApp must be connected), return values, and error conditions, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, yet the description references 'given participants', implying parameters that do not exist in the schema. This mismatch fails to explain how participants are specified, and the description does not compensate for the lack of parameter documentation.
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 clearly states the action ('Creates a WhatsApp group') and the resource ('WhatsApp group'), which distinguishes it from sibling tools like whatsapp_group_info or whatsapp_send_message. However, the phrase 'adds the given participants' implies parameters that are not defined in the schema, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as whatsapp_list_groups or whatsapp_send_message. There is no mention of prerequisites (e.g., WhatsApp connection) or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of disclosing behavior. 'Searches' implies a read-only operation, but it does not mention prerequisites (e.g., syncing via whatsapp_sync), potential staleness of synced metadata, or what the return value looks like. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is truncated mid-phrase ('to their J...'), making it incomplete. It is not well-structured because the essential point is cut off, and the reader is left with an unfinished thought.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain how to use the tool given the empty parameter schema, what it returns (no output schema), or any preconditions like syncing contacts. The truncation exacerbates the incompleteness, leaving critical information missing for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, but the description claims the tool searches 'by name or number', suggesting the agent can specify these fields. This is a direct contradiction between the description and the schema, leaving the agent unable to provide the necessary input. The description adds misleading meaning rather than clarifying the empty schema.
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 clearly states the action ('Searches your WhatsApp contacts') and the resource, and specifies the search criteria ('by name or number'). It also provides a use case ('use it to resolve a person to their J...'). However, the sentence is truncated, cutting off the exact purpose, and the empty parameter schema contradicts the implied input, preventing a higher score.
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 a clear usage context: 'use it to resolve a person to their J...' This tells the agent when to apply the tool. It does not mention alternatives or exclusions, but the context is sufficiently specific for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure burden. It only states the core action without mentioning side effects, required permissions, error conditions, or what happens when created (e.g., which list added to).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is extremely brief and lacks structure. It does not provide important details or organize information effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is critically incomplete for a creation tool with no output schema and 0 parameters. It fails to explain how the tool works, what assumptions it makes (e.g., uses context, default values), or how results are returned.
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 is empty (0 parameters) and coverage is trivially 100%, but the description does not explain how a task can be created without any input. A score of 3 reflects that while schema coverage is high, the description adds no meaningful parameter insight.
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 ('Creates'), resource ('new task'), and application ('OmniFocus'), distinguishing it from sibling tools like 'complete_omnifocus_task' (complete) and list/search variants (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'complete_omnifocus_task' or 'list_omnifocus_tasks'. No context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states what the tool does, not how it behaves. It does not disclose how location is obtained (e.g., IP geolocation, default), whether it requires user consent, rate limits, or what 'short daily forecast' entails. No annotations are provided to compensate.
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, short sentence that efficiently conveys the tool's core purpose. No unnecessary words, and the structure is front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and no output schema, the description is too minimal. It fails to specify how the location is determined, the format of the output, or any edge cases. The tool's simplicity does not excuse the lack of essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is trivially 100%. However, the description says 'for a location', which misleadingly implies a location parameter exists. This contradiction between description and schema lowers the score below the baseline of 3.
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 clearly states that the tool retrieves current weather and a short daily forecast. The verb 'Gets' and resource 'weather' are specific. However, the lack of a location parameter in the schema makes it ambiguous how the location is determined, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are no sibling weather tools, but the description does not mention any prerequisites or context for usage (e.g., internet connection, location permissions).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only mentions 'via the cloud', but does not disclose any behavioral traits such as authentication requirements, potential side effects, or return behavior. The truncated description leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is cut off (ends with '...'), making it incomplete. While conciseness is generally good, truncation damages clarity and completeness. The structure is poor due to the truncated ending.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description should explain how the tool works or what it needs. The incomplete sentence fails to provide sufficient context. The tool likely requires additional inputs (e.g., recipient, subject, body) but none are defined, leaving major gaps in understanding.
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 0 parameters, and the input schema is empty. The description does not need to add parameter meaning since none exist. Schema description coverage is 100% (vaccuously). A baseline of 4 is appropriate for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'send from their Microsoft 365 / Outlook account via the cloud', which indicates the tool is for sending emails through M365/Outlook. However, the description is cut off and incomplete, lacking a clear verb. The tool name reinforces the purpose, but the description alone does not fully articulate the action.
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 provides a usage context: 'Use this when the user wants to send from their Microsoft 365 / Outlook account via the cloud'. This helps distinguish from other email tools like 'send_email' (generic) or 'm365_reply_email'. However, it does not specify when not to use this tool or mention alternatives explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description claims reading by 'chat ID or contact name' but the input schema has zero parameters, creating a contradiction. No disclosure of read limits, permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but omits critical details (e.g., how to specify chat). Not verbose, but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/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, description fails to explain essential aspects: how parameters are supplied, return values, error cases, and differentiation from siblings beyond mentioning iMessage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Baseline is 4 due to zero parameters, but description adds semantic meaning that conflicts with schema (claims parameters exist but schema says none). This misleads rather than clarifies.
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?
Name and description clearly state the tool reads messages from an iMessage conversation, distinguishing it from sibling tools for other platforms like Signal, Teams, WhatsApp, and Zalo. The verb 'reads' and resource 'messages' are specific.
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?
Implicitly specifies iMessage context, but no explicit guidance on when to use this versus alternatives (e.g., signal_read_messages). Also missing prerequisites like requiring a valid chat ID or contact name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 implies a side effect by saying 'Sends', but it does not explain the mechanism, required input, or consequences of the action. There is no mention of authentication, rate limits, or outcomes, leaving the agent without sufficient behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single sentence that cuts off mid-thought ('...'), making it incomplete and poorly structured. While brief, the truncation undermines conciseness, and the content is under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and no annotations. The description only covers the core action and object, omitting how to invoke it, what the user needs to provide, and what the outcome looks like. For a zero-parameter tool, the description is surprisingly incomplete, and overlap with 'request_feature' is unaddressed.
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 properties, so schema coverage is 100%, and the baseline for 0 params is 4. The description doesn't address how the report content is supplied, but it also doesn't mislead; given the absence of parameters, this is acceptable.
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 clearly states the tool 'Sends a problem report, feature request, or integration request to the LMCP team', identifying the action and recipient. However, the sentence is truncated at '— for when a user wants to...', and it doesn't distinguish from the sibling tool 'request_feature', which likely overlaps in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase '— for when a user wants to...' begins to provide usage context but is incomplete, leaving the actual conditions ambiguous. No alternatives or exclusions are mentioned, such as when to use 'request_feature' instead, providing very little guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as side effects, permissions needed, or rate limits. Minimal disclosure leaves the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but incomplete due to truncation. It conveys the core idea efficiently but lacks a complete sentence structure.
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?
Given no parameters, no output schema, and a simple function, the description provides minimal context. It does not describe what happens after submission or any confirmation, leaving some 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 tool has zero parameters; the input schema is empty with 100% coverage. The description does not need to add parameter details, and it meets the baseline for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it submits a feature request to the LMCP team, listing examples. However, the text cuts off, making it incomplete. The general purpose is clear, but specificity and completeness are lacking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among many sibling tools, this is unique, but the description does not provide context for its use or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any disclosure of behavioral traits such as which channel is read, number of messages retrieved, or rate limits. With no annotations provided, the description fails to inform the agent about important aspects of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence. However, it is so brief that it sacrifices necessary detail, which is not ideal for conciseness. It is structured adequately but lacks crucial information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, the description is incomplete. It does not specify which channel or DM is read, how many messages are returned, or any filtering criteria. The tool's functionality is not fully contextualized.
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 no parameters, so schema coverage is 100%. The description does not add any parameter semantics beyond what the schema already provides. A baseline score of 3 is appropriate.
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 clearly identifies the action ('Reads') and resource ('recent messages from a Slack channel or DM'). It distinguishes the tool from the sibling 'slack_search_messages' by specifying 'recent', but does not explicitly differentiate from other channel-related tools like 'slack_list_channels'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or when it should not be used. The description only states the function without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only says it searches for a symbol by company name but doesn't disclose return format, edge cases, limitations, or any side effects. This is insufficient for an agent to understand what happens when invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but appears to be an incomplete fragment, ending with '(e.g.' and no continuation. While conciseness is good, the truncation makes it poorly structured and incomplete, failing to fully communicate the intended message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 still needs to provide enough context for an agent to use it correctly. It fails to explain how to provide the company name, what the output looks like, or any example usage. The description is too truncated to be considered 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 schema has zero parameters, so the baseline is 4. The description adds the key semantic that the search is 'by company name,' which would be the implicit input. Even though the schema doesn't list a company_name parameter, the description gives the agent an idea of what the tool expects. No contradiction or additional parameter details are provided.
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 clearly states the tool searches for a stock ticker symbol by company name, using a specific verb ('searches') and resource ('stock ticker symbol'). It distinguishes from sibling tools like stocks_get_chart and stocks_get_quote, which have different purposes. However, the description is truncated ('e.g.' without examples), so it doesn't fully achieve complete clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or when not to use it. The description only states what it does, not how to decide to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'Creates a task' and 'via Reminders sync', lacking details on side effects, failure modes, or required account setup. The mention of sync hints at coupling but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it is too brief and lacks structure. It could include more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 the complexity of task creation, the description is incomplete. It does not explain what task is created, how the agent should specify it, or any prerequisites.
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 zero parameters, so schema coverage is trivially 100%. The description adds no parameter info, which is acceptable for a parameterless tool, but it fails to clarify how the task content is provided (e.g., from context or defaults).
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 clearly states the action (creates a task) and the target (Microsoft To Do) with a mention of the sync mechanism, which helps distinguish it from similar tools like create_reminder. However, it stops short of explicitly differentiating from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives like create_reminder or create_omnifocus_task. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only says 'sends' without disclosing behavioral traits such as whether previous connection is required, whether it returns a message ID, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but too brief for a tool with no parameters; fails to provide essential context on how inputs are obtained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description omits prerequisites (e.g., connection step), message format, and conversation identification method. For a 0-param tool, it lacks 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 zero parameters; description does not explain how the tool knows which conversation or what message content. Baseline for 0 params is 4, but lack of explanation reduces score.
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?
Description clearly states verb 'Sends', resource 'Zalo message', and target 'conversation'. It distinguishes from sibling messaging tools by specifying Zalo platform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like send_message or signal_send_message. No prerequisites mentioned (e.g., need to connect to Zalo first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavior. It only hints at returning machine associations but does not mention permissions, side effects, return format, or whether agents are filtered by state. The truncated fragment leaves significant behavioral information undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief, but it is an incomplete sentence that ends abruptly ('i...'). While it avoids waste, the truncation harms structural completeness and makes it read as an unfinished thought.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and no annotations, the description is expected to clearly explain what is returned. It starts to say 'which machine each is on' but is cut off, leaving the response format and any additional agent fields undisclosed. For a simple list operation, this is incomplete.
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 there are no parameter semantics to explain. The baseline for 0-parameter tools is 4, and the description's mention of 'ALL the user's machines' adds useful context about the implicit scope, which is appropriate.
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 names a specific verb ('Lists') and a clear resource ('agents currently working across ALL the user's machines in the mesh'), which distinguishes it from siblings like agent_mesh_status or agent_inbox. However, the description is truncated mid-sentence, cutting off the list of details about each agent, so it does not fully specify the output's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as agent_mesh_status or agent_checkin. It implies a monitoring/listing use case but does not state any exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description holds full responsibility for behavioral disclosure. It only implies a write operation ('adds to config') without specifying side effects (e.g., overwriting existing config, permission requirements, restart needs, or impact on clients). Critically missing for a tool that modifies system configuration.
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 sentence front-loading the purpose. No wasted words. Lists example clients efficiently. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 is too brief. It fails to explain what 'Local MCP' means, which config files are modified, whether clients need restart, or if the operation is reversible. A more complete description would improve usability 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 no parameters (schema coverage 100%). The description adds value by explaining what the tool does, which compensates for the lack of parameter information. According to guidelines, baseline is 4 for 0 parameters when description adds context, which it does.
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?
Description clearly states the action ('Adds Local MCP to the config') and target ('installed MCP-capable AI clients on this Mac'). It lists examples (Claude Desktop, Claude Code) which helps. However, it does not explicitly distinguish from the sibling tool 'update_local_mcp', which might have similar purpose. Slight ambiguity prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'update_local_mcp' or other configuration tools. The description only states what it does without providing context on prerequisites, frequency, or exclusions. An agent would lack decision support for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like authentication requirements or side effects. It only says 'connect,' which is vague and does not inform the agent about potential user interaction, permissions, or state changes.
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 sentence, making it concise. However, it could be slightly expanded without losing conciseness to provide more value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that likely involves OAuth or user interaction, the description lacks critical context about what happens after connection, prerequisites, or any follow-up steps. It is insufficient for an agent to understand the tool's role.
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 zero parameters and 100% coverage, so the baseline is 3. The description adds no additional meaning beyond the schema, which is acceptable for a parameterless tool.
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 clearly states 'Connect your Microsoft 365 account,' which is a specific verb+resource. It distinguishes from the sibling tool 'disconnect_m365_account' and other m365 tools. However, it lacks any additional context about what 'connect' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context. The description simply states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states it returns data, but does not confirm it is read-only, whether it has side effects, or any other behaviors like caching 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets to the point, but it is truncated, making it incomplete. It is concise but not fully formed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description should fully explain the tool. It partially explains what it returns but is cut off, missing details about output format, data freshness, or limitations.
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 baseline is 4. The description adds no parameter info, but that is fine since none exist. The description is incomplete but does not mislead.
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 clearly states the tool returns a morning briefing combining today's calendar events and reminders. It distinguishes itself from siblings like list_calendar_events and list_reminders by offering a consolidated view. However, the description is truncated, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when not to use it or any prerequisites. The context of a morning briefing is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions returning data but does not indicate if the tool is read-only, destructive, or has any side effects. The truncated 'one-click...' implies an action but is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main action, which is good. However, it is clearly truncated, which harms structure and completeness. Conciseness is otherwise acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a truncated description, the tool is under-described. The incomplete 'one-click...' leaves ambiguity about what the tool provides. The context is insufficient for an agent to fully understand the tool's output or behavior.
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, so schema coverage is 100%. The description does not need to add parameter information, and the baseline score of 4 applies. The description adds no parameter semantics, as none are needed.
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 clearly states that the tool returns macOS privacy (TCC) permissions that are not granted, using the verb 'Returns' and specifying the resource. However, the description is truncated, and there is a sibling 'permissions_status' that may overlap, but the tool's unique purpose is still discernible.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'permissions_status'. The description does not mention when-not to use it or provide context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description offers minimal behavioral information beyond the action. There is no mention of whether it lists all tasks, requires prior selection of a project, or any side effects. Given no annotations exist, the description fails to disclose critical 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but at the expense of necessary details. It is not verbose, but it is under-specified for effective tool use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is parameterless and has no output schema, but the description does not provide enough context about what tasks are returned (e.g., all tasks, only incomplete ones) or any prerequisites. Sibling tools exist that could have been distinguished. The description is incomplete for an agent to use it effectively.
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 schema coverage is 100%. The description adds no parameter details, which is acceptable since there are none. Baseline score of 4 is appropriate.
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 'Lists tasks from OmniFocus' clearly specifies the action (list) and resource (tasks from OmniFocus). However, it does not differentiate from sibling tools like 'search_omnifocus_tasks' or 'list_omnifocus_projects', which reduces clarity in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'search_omnifocus_tasks' for filtered queries or 'list_omnifocus_projects' for project-level listing. The description lacks any contextual cues for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It states the action is 'delete' (destructive) but omits details like permanence, permissions, or confirmation. Minimal 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?
Single sentence, efficient, front-loaded with the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with no output schema or annotations, the description lacks critical info: how to provide the event ID (schema has no parameter), return value, and error states. Incomplete for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties (0 parameters), but the description says 'by its ID', implying a required parameter. This mismatch is misleading. The description adds meaning that contradicts 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 (delete), the resource (calendar event), and the scope (Microsoft 365/Outlook calendar). It distinguishes from similar sibling tools like 'delete_calendar_event' by specifying the service.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'delete_calendar_event' for other calendars). No prerequisites or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only says 'lists files and folders' without details on recursion, error handling, or permission needs. Minimal transparency.
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 concise sentence with no unnecessary words. Could benefit from slight expansion but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and no annotations, the description lacks essential context about default behavior, output structure, and limitations. Incomplete for effective tool usage.
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 zero parameters, so no parameter info to add. However, the tool name implies a path parameter, which is missing, creating a mismatch. Baseline 4 for zero params is lowered by this inconsistency.
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 clearly states the tool lists files and folders in OneDrive, using a specific verb+resource. However, it could be more precise about which path (e.g., root or specified) and how it differs from siblings like onedrive_search_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as onedrive_search_files or gdrive_list_files. Lacks context on prerequisites, scope, or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the action but does not disclose any side effects, reversibility, required permissions, or what 'restricting access' entails beyond a vague folder reference.
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, concise sentence with no extraneous information. Every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a simple action, the description is incomplete. It lacks details about how the folder is determined, whether the change is persistent, and how to revert the restriction.
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 0 parameters and 100% coverage, so the description adds no parameter-level depth. However, the description implies a 'specific folder' but no parameter exists, which could cause confusion. Baseline for 0 parameters is 4, but this potential mismatch reduces clarity.
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 clearly states the action ('restricts LMPC's OneDrive access to a specific folder') using a specific verb and resource. However, it does not distinguish this tool from sibling tools like onedrive_root or onedrive_list_files, which also deal with OneDrive scoping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other OneDrive tools. There are no exclusions, prerequisites, or context about expected usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only states it 'reports' the state, implying a read-only operation, but does not confirm side-effect-free behavior or any prerequisites. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but appears truncated ('capture th...'), resulting in incomplete information. A complete sentence would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description should still explain the return format or how to interpret the permission state. It lacks this context, making it less useful for an AI 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, so the schema already provides full coverage. The description adds no parameter information, which is acceptable since none are needed.
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 clearly states the tool reports TCC permission state for specific types (screen recording, accessibility, microphone). However, it does not distinguish itself from the sibling tool 'list_missing_permissions', which also deals with permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_missing_permissions' or when not to use it. The description lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions running steps and persisting, but is truncated and does not cover side effects, permissions, or destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but is truncated, so it is not fully concise. It could be more complete without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (executing a recipe), and the description is incomplete. It does not explain what a recipe is, the lifecycle, or expected output. Given no output schema or annotations, more context is needed.
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 input schema fully covers parameter semantics. The description adds no parameter info, which is acceptable given zero parameters (baseline 4).
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 clearly states the tool executes a recipe end to end, binding params and running steps, which indicates a specific verb and resource. However, it is truncated, leaving some ambiguity about the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like recipe_discover, recipe_list, or recipe_delete. The description does not mention prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 fails to mention the destination path on disk, naming conventions, overwrite behavior, or any side effects. Additionally, with zero parameters, the tool relies on implicit context (likely the last read email), but this is not stated.
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, concise sentence that communicates the core action efficiently. However, the brevity sacrifices necessary detail for a function with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 or annotations, the description should provide more context about how the tool determines which attachment, where it saves to, and any constraints. The current description is insufficient for an AI agent to use correctly without additional clues.
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 zero properties (100% schema coverage). With no parameters, the description should clarify how the attachment is identified (e.g., from context). It does not, leaving an implicit dependency unexplained. Baseline for no parameters is 4, but the lack of explanation reduces the score.
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 clearly states it saves an attachment from an email to disk. The verb 'saves' and resource 'attachment from an email' make the action unambiguous. Among many email-related siblings, this tool is distinct in that it handles attachments. However, it doesn't specify which attachment is targeted (e.g., from the most recently read email).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., needing to have read an email first). There is no mention of conditions under which this tool should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only states it lists tasks. It does not disclose whether authentication is needed, how the target list is determined (given no parameters), or any side effects. Critical behavioral details are missing.
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 sentence with no extraneous content, making it concise. However, it lacks structure (e.g., bullet points for key points) that could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the context of many sibling tools for listing tasks (e.g., list_reminders, list_omnifocus_tasks) and no output schema, the description is incomplete. It does not explain how the tool integrates with other tools or what format the output takes.
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?
With zero parameters and schema coverage at 100%, the description need not explain parameters. However, it fails to clarify how the tool selects a specific list, which would aid usability. Score is baseline 3, as no additional value is provided beyond the schema.
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 clearly states the tool lists tasks from a Microsoft To Do or Reminders list, using a specific verb and resource. However, it does not explicitly differentiate from sibling tools like list_reminders or list_omnifocus_tasks, leading to slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_reminders or list_omnifocus_tasks. There are no usage conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only mentions that everyone in the chat sees the poll, which is a minimal behavioral trait. It does not disclose potential side effects, required permissions, connection requirements, or error behavior, leaving significant gaps for an 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, concise sentence with no wordiness. It is front-loaded with the core action. However, it is under-specified, lacking essential information. Given the conciseness dimension focuses on economy of expression rather than completeness, a score of 4 is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is not simple; sending a poll requires multiple pieces of information and likely has prerequisites, such as an active WhatsApp connection. The schema is empty and there is no output schema or annotations. The description does not cover prerequisites, how to indicate the target chat, poll options, or failure scenarios, making it incomplete for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so there are no formal parameters. The description does not explain how to specify the poll question, options, or target chat/group. Since the tool logically requires such details, the absence of any parameter guidance is a major deficiency. The baseline for 0 params is 4, but the description fails to clarify that the tool relies on natural language context or another mechanism, so it drops to 2.
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 function: sending a poll to a WhatsApp chat/group, and adds a specific behavioral detail that everyone in the chat sees it. It effectively distinguishes itself from sibling tools like whatsapp_send_message and whatsapp_send_file by focusing on the 'poll' object type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as whatsapp_send_message. It does not mention prerequisites (e.g., WhatsApp connection), target selection, or exclusions. The only implied usage is for sending polls, but no explicit when/when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 of behavioral disclosure. It states 'records' implying a write operation, but gives no details on idempotency, authentication requirements, whether emails are sent, or error handling. The return value is mentioned, but broader side effects and constraints are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is efficient, but it is truncated ('per p...') and awkwardly combines two clauses. While not verbose, the incomplete ending and lack of structure prevent it from being more polished.
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?
The tool is simple (no parameters, no output schema), and the description covers the core action and return value. However, it lacks context about preconditions (e.g., how colleagues are chosen), relationship to list_referral_candidates, and error behavior, leaving it incomplete for a mutation-type 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 input schema has zero properties, so there are no parameters to describe. With no parameters, the baseline is 4, and the description adds context by explaining the tool's behavior (recording invites and returning a unique link), which compensates for the lack of explicit parameters.
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 clearly states the tool 'records referral invites' and 'returns a unique referral link per person' (assuming 'per p...' means per person). This specifies the action and result, and it is distinguishable from the sibling tool list_referral_candidates which lists candidates rather than recording invites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not mention when to use this tool versus alternatives such as list_referral_candidates, nor does it give exclusions or prerequisites. It only implies usage after the user has chosen colleagues to invite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits, but it only says 'reply' without explaining whether it sends immediately, opens a compose window, or requires additional input. This omission is significant for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence starting with 'Use this when...', which is front-loaded and direct. However, it appears truncated, reducing its effectiveness. Assuming completion, it would be concise, but the cut-off warrants a moderate score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide a complete picture. It only mentions the platform and basic action, omitting details on behavior, prerequisites, or return values. The tool's simplicity does not fully compensate for missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, but the description implies a required 'message ID' from list_emails, creating confusion. With 0 parameters, the schema coverage is 100% trivially, but the description contradicts the schema by suggesting an unlisted parameter.
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 clearly states the action (reply) and the specific resource (Apple Mail emails), distinguishing it from sibling tools like m365_reply_email. The truncated reference to 'list_...' slightly reduces clarity but still conveys the context.
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 specifies when to use the tool (to reply to Apple Mail emails), providing clear usage context. It does not explicitly state when not to use it, but the platform specificity inherently excludes other email services.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states the basic action without mentioning read-only nature, side effects, required permissions, return format, or pagination. This is insufficient for an agent to understand the tool's impact.
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 short sentence with no wasted words. It is concise, though it could be considered under-specified for its context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is too minimal. It does not explain search syntax, result limits, or what the tool returns, leaving significant gaps 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 input schema has no parameters, so schema coverage is 100%. The description adds no parameter info, but with zero parameters, the baseline score of 4 applies.
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 clearly states the tool's action (search) and resource (ServiceNow Knowledge Base articles). It is a specific verb+resource combination that distinguishes it from many siblings, though it does not explicitly differentiate from other search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'servicenow_search_incidents' or other search tools. The description lacks any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions 'via Reminders sync', which hints at cross-platform synchronization, but does not disclose permissions, side effects, or whether the action is reversible. Minimal behavioral insight beyond the core function.
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 sentence of 12 words, very concise and front-loaded with the action. However, it omits crucial information about task identification, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and empty input schema, the description must explain how the tool knows which task to complete. It does not. For a tool that operates on an implicit task (likely the currently active one), this is a critical gap. The 'via Reminders sync' offers minor context but is insufficient.
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, and schema coverage is 100%. The description does not add any parameter information, but none is needed. However, it fails to explain how the target task is determined, which is an implicit parameter. Still, baseline 4 is appropriate.
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 clearly states the verb 'marks as complete' and the resource 'Microsoft To Do task'. It is distinct from siblings like complete_reminder and complete_omnifocus_task. However, it does not explain how the specific task is identified, which is ambiguous since the input schema has no parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like complete_reminder or complete_omnifocus_task. The description provides no context for when to choose this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states deterministic synchronization and replacement of sleeps, but omits critical details: what happens if the element never appears (timeout, error?), how long it waits, whether it can be interrupted, and any side effects. This is insufficient for safe agent use.
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 very short and front-loaded, earning its place with no wasted words. However, it is a phrase rather than a sentence, and could be restructured as a complete sentence for clarity while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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, no annotations), the description is the only source of information. It lacks coverage of error handling, timeout behavior, and how the tool determines which element to wait for (likely relying on prior context). This is insufficient for an agent to use it reliably alongside sibling UI tools.
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 is empty (0 parameters) with 100% coverage, so the schema already conveys all parameter info. The description adds no parameter-specific details, but per guidelines a baseline of 4 is appropriate for zero parameters. No improvement needed, though noting context-dependence would help.
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 'Deterministic synchronization — replaces all sleeps' clearly indicates the tool is a smarter wait mechanism, and the name 'ui_wait_for_element' specifies it waits for a UI element. It conveys the purpose effectively but could more explicitly state it waits for an element to appear or become available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used instead of arbitrary sleep calls, but it provides no when-to-use vs. alternatives guidance. It does not compare with sibling tools like ui_find_element or other wait tools, nor does it mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are given, and the description does not disclose any behavioral traits such as wait behavior, click type, or error handling.
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 very short and front-loaded, but it is not overly concise to the point of missing essential information. It earns its place by stating the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and parameters, the description is too minimal. It does not specify preconditions, postconditions, or what constitutes a successful click, especially important given many similar sibling tools.
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 baseline is 4. The description adds no extra parameter meaning, but none is needed.
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 explicitly states the action ('clicks') and the resource ('an element on the current page'), making the purpose clear. However, it does not distinguish itself from similar sibling tools like chrome_click or safari_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context on prerequisites or exclusions.
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 disclosure burden. It mentions saved login and return values, but omits details on page load behavior, timeouts, error handling, or idempotency.
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 sentence efficiently conveys core action and return values. Some front-loading of the core action is present.
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?
Describes return values (URL, title) adequately, but with no output schema, missing details on error cases, session identification, and interaction with other web tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters but the description mentions navigating 'to a URL', implying a needed parameter that is absent. This creates confusion and undermines agent understanding.
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 clearly states it navigates a web session to a URL using saved login and returns the resulting URL and page title. This distinguishes it from browser-specific navigate tools like chrome_navigate or safari_navigate, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over siblings like web_click, chrome_navigate, or safari_navigate. No context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It fails to disclose behavioral traits such as permission requirements, handling of duplicate folder names, or side effects. The description merely states the action without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with all essential information front-loaded. No wasted words; it is appropriately concise for a simple creation tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the lack of parameters and output schema, the description omits critical information: how the folder name is specified (no parameters, but creation requires a name). This makes the tool definition functionally incomplete for an AI agent to invoke 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 has no parameters (100% coverage baseline), so the description need not add parameter info. However, it also does not explain the absence of parameters or how the folder name is determined, which is a gap. 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 verb 'creates', the resource 'mailbox folder', and the context 'in Mail.app', distinguishing it from sibling tools that create other entities (e.g., notes, reminders).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool vs alternatives, nor does it mention prerequisites, error conditions, or whether folder existence should be checked beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'creates' without detailing behavioral traits like idempotency, side effects, or permissions. Insufficient transparency 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is concise, but under-specifies details. Could add value without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a tool with no annotations, no output schema, and many sibling tools. Lacks prerequisites, constraints, or expected behavior.
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?
No parameters in schema; description adds no meaning beyond schema. Baseline for 0 params is 4, but ambiguity about what note is created (content?) lowers to 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?
Clearly states 'Creates a new note in Apple Notes', specifying verb and resource. Distinct from sibling tools like read_note, update_note, list_notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of alternatives. Does not mention prerequisites or context for creating a note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses matching behavior (case-insensitive, partial) and that it starts from a root directory, but it doesn't explain how the root directory is determined given the input schema has zero parameters, nor what the return format is. With no annotations, this ambiguity is a significant gap.
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, concise sentence that front-loads the core purpose and key matching behavior. Every word earns its place with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, the description should clarify return values and operational context (e.g., scope of 'root directory'). It provides only basic search semantics, leaving significant ambiguity for a tool with no parameters.
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 no parameters, so the baseline is 4. The description adds the concept of a 'root directory' which is not a parameter, but there is no parameter information to clarify further.
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 clearly states the tool searches for files and folders by name, with case-insensitive and partial matching details. It identifies a specific verb and resource, though it doesn't explicitly distinguish from sibling tools like finder_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like file_list or finder_search. No prerequisites or context for invocation are mentioned, leaving the agent without sufficient direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions recursion and name-based search but fails to disclose output format, case sensitivity, blocking behavior, or prerequisites (e.g., sync status). This is insufficient for an unannotated 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?
The description is a single sentence with no wasted words, front-loading the key action and scope. It is highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 is insufficient. It omits return format, result details, and operational context (e.g., whether it searches only filenames or content). The tool's behavior is underspecified.
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, so schema coverage is 100%. The description need not explain missing parameters, and it accurately reflects the tool's no-parameter nature.
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 clearly states the action (searches), resource (synced Google Drive folder), and method (by name, recursive). However, it does not explicitly differentiate from sibling tools like gdrive_list_files or fs_search, leaving the agent to infer distinctions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No 'when to use' or 'when not to use' information is provided, and no alternatives are mentioned.
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 states it overwrites and uploads automatically, which discloses key behavior. However, it does not mention whether it creates new files, requires specific permissions, or has rate limits. Incomplete but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, focused sentence that gets to the point quickly. Truncated ending reduces conciseness slightly, but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema or annotations, the description should provide more context about file naming, content source, and behavior on overwrite. It is truncated and lacks details needed for safe usage.
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 is empty, so description cannot add parameter info. However, the tool likely needs parameters (content, filename) which are missing, indicating a design gap. Description does not compensate for missing schema details.
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?
Describes writing/overwriting a text file in the synced Google Drive folder. Clear verb and resource, and distinguishes from read and search siblings. However, description is truncated, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like onedrive_write_file, or when not to use (e.g., binary files). No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only mentions 'requires a connection,' omitting details on data returned, pagination, or rate limits. Incomplete for a no-annotation scenario.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but truncated, losing potential instructions. Could be more structured with context about prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters, description leaves out what the tool returns (subject line, metadata, etc.), any sorting, or pagination. Insufficient for confident use.
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 4 applies. Description adds no parameter info, but none is needed.
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?
Description clearly states the tool lists Microsoft 365/Outlook/Exchange inbox, distinguishing it from generic list_emails or search tools. However, truncation slightly reduces clarity.
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?
Provides explicit when-to-use ('Use this when the user wants...') but lacks guidance on when not to use or alternatives like m365_search_emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions 'via the cloud' but does not explain auth requirements, whether it only searches the primary mailbox, if it modifies state, or any rate limits. The description is insufficient for safe tool invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is truncated, suggesting missing information. It wastes no words, but the incompleteness reduces effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and a truncated description, the tool lacks essential context. How the search query is specified (e.g., via conversation context) is unclear, making it hard for an 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?
The input schema has zero parameters, so the description does not need to explain them. Baseline 4 is appropriate as there is no parameter information to add beyond what the schema provides.
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 clearly states the tool finds emails in Microsoft 365/Outlook mailbox via the cloud, matching the name. However, it does not differentiate from similar sibling tools like search_emails or list_emails, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description begins with 'Use this when,' providing usage context, but is truncated and does not specify when not to use or mention alternatives. It implies cloud-based email search but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'cached rows' hinting at possibly stale data, but does not disclose read-only nature, authentication needs, or any side effects. With no annotations, the description should provide more behavioral context, but it remains minimal.
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 sentence of 13 words that conveys the core action and a key detail (property mapping). No unnecessary words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks crucial context: which database is read (database selection not addressed), what 'cached' entails, and the return format. With no output schema, the description should explain the output more thoroughly. Incomplete given the tool's simplicity.
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 and 100% coverage trivially. The description adds value by explaining that properties are mapped through the schema, clarifying the output structure. Baseline for no parameters is 4, and description meets it.
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?
Description clearly states it reads cached rows of a Notion database and maps properties through the schema. This distinguishes it from siblings like notion_list_databases (lists databases) and notion_read_page (reads a single page). However, it does not specify which database is read, assuming a default selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like notion_list_databases or notion_search. The description does not mention prerequisites or context for using the tool, leaving the agent without decision support.
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 partially discloses behavior: it searches cached content case-insensitively. However, it doesn't clarify what 'cached' means, whether the tool is read-only, or any rate limits. It adds some transparency but leaves gaps.
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, clear sentence with no redundant words. It efficiently conveys the core functionality without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the tool returns (e.g., matching page titles, snippets). It does not, leaving the agent uncertain about the response format. The tool is simple but incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, yet the description implies a 'phrase' parameter. This is a critical inconsistency: the description misleads agents into thinking a phrase is needed when no parameter is defined. Schema coverage is trivially 100% but the description contradicts 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 (searches), resource (cached Notion content), and scope (page titles and block text, case-insensitive). It distinguishes itself from sibling Notion tools like notion_list_pages and notion_read_page by focusing on search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer search over listing or reading pages, nor does it explain the implications of searching cached content (e.g., may not include real-time updates).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Reads a text file,' without mentioning whether it returns the file contents, how it handles non-text files, size limits, or encoding. Two sentences are insufficient for a read operation with no output 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?
The description is a single, front-loaded sentence that contains only the essential information: the action and the resource. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameters, the description is too sparse. It fails to explain how the target file is selected, what the output will be, or any constraints (e.g., text-only files). Users would need additional context from sibling tools like onedrive_set_scope to use this 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 has zero parameters and the schema is empty, so there is nothing to document. The description adds contextual meaning by specifying 'text file' and 'OneDrive synced folder,' aligning with the baseline of 4 for zero-parameter tools.
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 clearly states the verb ('Reads') and resource ('a text file from your OneDrive synced folder'), distinguishing it from sibling tools like onedrive_list_files and onedrive_search_files. However, it does not explain how the specific file is identified (e.g., via a selected file or scope), leaving minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as file_read, gdrive_read_file, or pdf_read. It implicitly suggests use for reading text files from OneDrive but does not state exclusions or compare with other read tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 for behavioral disclosure. It only mentions 'browses', which implies a read-only operation, but does not explain if it lists, searches, or filters. No details on authentication, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence fragment), and front-loaded with the action. However, it is truncated and incomplete, which is a structural flaw. Every word earns its place, but the lack of completeness reduces conciseness effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without output schema and with a truncated description, the tool is incomplete. A user or agent cannot fully understand what the tool returns or how to use the result. The description should clarify the output (list of recipes) and any filtering criteria.
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, and schema description coverage is 100% (trivially). According to the rubric, 0 parameters baseline is 4. The description adds no parameter info since there are none.
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 it browses installable community SKILLS (ready-made LMCP workflows), which is a specific verb and resource. It gives an example of a morning brief, but the description is truncated, leaving ambiguity. It distinguishes from siblings like recipe_install and recipe_list, but not explicitly.
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?
No explicit guidance on when to use or not. Implied usage is when the user wants to discover new recipes. No exclusion criteria or alternatives are provided, relying on the tool name and context.
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 carry the burden. It indicates a harmless listing operation (non-destructive), but does not explicitly state read-only behavior or any side effects. Minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but appears truncated (ends with '...'), which undermines completeness. It lacks full information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify what the returned list contains (e.g., names, IDs). It only mentions 'reusable SKILLS' without detail, leaving the agent underinformed.
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, so baseline is 4. The description adds no parameter semantics since none are needed.
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 clearly states it lists the user's reusable SKILLS (saved recipes), indicating a retrieval operation. However, it does not differentiate from sibling tools like 'recipe_get' or 'recipe_discover', missing an opportunity to clarify scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives, nor any conditions for usage. The agent is left without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond stating it runs a command and returns output. No annotations are provided. Important details like potential destructiveness, permission requirements, sandboxing, or handling of long-running commands are omitted, which is a significant gap for a command execution 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?
The description is a single sentence of 14 words with no unnecessary information. It is front-loaded and efficiently communicates the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters and no output schema, the description is too minimal. It fails to mention critical context like the security implications, that any shell command can be run, or what the output format (stdout/stderr) looks like. A command execution tool requires more completeness for safe and effective use.
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 no properties (0 parameters), and schema description coverage is 100%. The description does not need to add parameter information since none exist. Per calibration, 0 parameters yields a baseline of 4.
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 clearly states the tool runs a shell command on the user's Mac and returns output, using specific verb 'Runs' and resource 'shell command on the user's Mac'. It distinguishes from sibling tools that focus on browsers, file operations, or specific applications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when a shell command is needed versus using a dedicated tool like fs_list or safari_navigate. No prerequisites, limitations, or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the tool searches by title or content but does not explain case sensitivity, matching behavior, limit on results, or whether it scans entire note content. This minimal detail is insufficient for an AI agent to anticipate 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 a single, clear sentence with no wasted words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 is the sole source of context. It lacks information about return format, result count, error conditions, and integration with note-specific behavior. For a zero-parameter tool, this is insufficient for full contextual understanding.
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 no parameters (0 params, 100% coverage), so the baseline is 4. The description mentions searching by title or content, which adds no parameter-specific meaning since there are none. This is acceptable for a parameterless tool.
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 clearly states the tool searches Apple Notes by title or content, which is a specific verb and resource. However, it does not distinguish itself from sibling tools like list_notes or read_note, which may also retrieve notes but without search semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as list_notes or read_note. It does not mention prerequisites, limitations, or scenarios where alternative tools are preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'Create a new incident' without mentioning any side effects, authentication needs, or return values.
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 very concise at 6 words, but it sacrifices useful detail. Still, it is front-loaded and easy to read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and no annotations, the description fails to mention what happens after creation (e.g., returns incident number, opens form) or any prerequisites.
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 has zero parameters, so baseline is 4, but the description does not explain how the tool creates an incident without parameters (e.g., relying on connected ServiceNow 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 clearly states the verb 'create' and the resource 'incident', and it is distinct from sibling tools like servicenow_get_incident, servicenow_update_incident, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to create vs search or update incidents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states that the tool shows or submits a survey, but it does not disclose what side effects occur (e.g., interrupting the user, opening UI, permanently submitting responses), whether the operation is idempotent, or what happens if no survey is assigned. This is insufficient for a tool that appears to have user-facing 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 a single sentence that is immediately informative and front-loads the core action. It contains no filler or redundancy, earning the highest score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (zero parameters, no output schema), the description leaves critical gaps: it does not clarify what triggers a show vs. submit, how the survey content is determined, or the expected outcome of calling the tool. The presence of the sibling 'survey_skip' suggests a workflow, but the description does not explain this tool's role in it, making the overall context incomplete.
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 coverage is 100%, so there are no parameter semantics to elaborate. Per the rubric, 0 parameters earns a baseline of 4. The description adds no parameter information, but none is needed.
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 clearly states the tool shows or submits an in-product survey assigned to the machine. It names the specific resource (survey) and indicates two possible actions. However, the dual verb 'shows or submits' is somewhat ambiguous about which action occurs in a given call, and no explicit distinction from the sibling 'survey_skip' is made, though the resource is clearly identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, such as survey_skip. The description does not specify scenarios where showing vs. submitting is appropriate, nor does it mention any prerequisites or conditions like the presence of a pending survey. The context is minimal and left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 of behavioral disclosure. It only says 'Create a Todoist task' without explaining side effects, auth requirements, failure modes, or how task content is specified given zero parameters. This is minimal and leaves the agent guessing about the tool's 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 a single sentence with no filler or redundancy. It is concise and to the point, appropriate for a tool with such a simple name and no parameters. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks essential context for an agent: it does not explain how to provide task details (given zero parameters), what happens after creation, or how this differs from similar tools. The sibling list includes 'todo_create_task' which may be an alias, but no clarification is given, leaving the description incomplete for reliable 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?
The input schema has zero parameters, and schema coverage is trivially 100%. Per the baseline for zero-parameter tools, the description need not add parameter details; the description adds no parameter semantics but none are necessary. The empty schema itself is a limitation but not the description's fault.
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 the verb 'Create' and the resource 'Todoist task', clearly indicating the tool's function. While it restates the tool name almost verbatim, it does distinguish from other create-* tools by naming Todoist explicitly, so it is specific but not highly differentiated from the sibling 'todo_create_task' which may be identical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like 'todo_create_task', 'create_omnifocus_task', or 'todoist_list_tasks'. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides minimal behavioral detail. It only states that the tool 'updates' a note, implying mutation, but does not disclose destructive consequences, permission requirements, or whether updates are incremental or overwriting.
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 concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and no parameters, the description is severely lacking. It fails to explain prerequisites, return values, or how the tool identifies the target note, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, yet the tool presumably needs to identify which note to update. The description does not explain how this identification occurs (e.g., via implicit context or state), leaving a semantic gap.
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 ('updates') and the resource ('existing note') within 'Apple Notes'. It effectively distinguishes itself from sibling tools like 'create_note', 'read_note', and 'search_notes' by specifying the update operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., noting which note to update) or when to choose update over create or other operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'Fetches' (read-only) but fails to mention any side effects, required connection state, what 'live info' specifically includes, or return format. This is a significant gap for a tool that might depend on external state.
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 concise sentence that front-loads the verb and resource. It is appropriately sized for the tool's simplicity, though 'live info' is a bit vague and could be more precisely stated without much added length.
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 simple tool with no parameters and no output schema, the description is mostly adequate but lacks details on what 'live info' encompasses and how the group is specified. Given the absence of output schema and annotations, more context about return values and usage would improve completeness.
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 no parameter documentation is needed. The description doesn't need to explain any parameters, but it also doesn't clarify how the tool identifies which group to fetch, which could be confusing. Baseline for 0 params is 4.
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 uses a specific verb ('Fetches') and clearly identifies the resource ('WhatsApp group's live info + participant list'). This distinguishes it from siblings like 'whatsapp_list_groups' which lists groups rather than details for a specific group, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other WhatsApp tools, nor any prerequisites such as needing an active connection or selecting a group first. The description gives no context for its intended use case or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only says 'Reads' without explaining output format, behavior when no polls exist, or any side effects. This is essentially just the verb, providing no meaningful 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is under-specified for a tool that could benefit from more context. It is not a tautology, but it is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameters, the description is insufficient for an agent to understand how to invoke the tool correctly. It doesn't specify how a poll is identified (e.g., current chat, most recent poll) or what results are returned, relying on implicit context not provided.
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, so the empty schema is already complete. The description adds no parameter details, but none are needed since there are none to explain.
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 (Reads) and the resource (WhatsApp poll results), distinguishing it from sibling tools like whatsapp_read_messages and whatsapp_send_poll. It is 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as whatsapp_read_messages. It doesn't mention prerequisites (e.g., requiring a WhatsApp connection) or which poll to read, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure, yet it only states the basic action without mentioning side effects, prerequisites, or error conditions like requiring a prior connection or non-existent chat.
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 concise sentence with no wasted words, but it could be slightly more informative without breaching conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description is too sparse—missing context like requiring a connection via whatsapp_connect or specifying the chat identifier.
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 schema coverage is trivially 100%. The description adds no value beyond the schema, but the baseline for zero parameters is 4.
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 'sends' and the specific resource 'text message to a WhatsApp chat', which distinguishes it from sibling messaging tools like send_email or signal_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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., signal_send_message), nor any prerequisites such as needing a WhatsApp connection or chat identification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It states the tool reads messages (implying a read-only operation) but does not clarify side effects, permission requirements (e.g., OAuth scopes), or limits like message count or time range for 'recent'. The dependence on being 'linked' is vague.
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 sentence that is concise and front-loaded. However, it could be slightly improved by clarifying the 'captured' and 'linked' concepts, which would reduce potential confusion without significantly increasing length.
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?
Given no output schema and no annotations, the description should provide more context. It lacks information about the return format (e.g., message content, sender, timestamps), pagination, or error conditions. For a simple read tool with no parameters, it is minimally adequate but leaves gaps for an AI agent to make assumptions.
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 and 100% schema description coverage. With no parameters to document, the description naturally adds no parameter details, but the baseline of 4 is appropriate. The description implicitly confirms that no user input is required beyond invoking the tool.
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 clearly specifies the verb 'reads' and the resource 'recent Zalo messages', and it differentiates from sibling tools like 'zalo_list_chats' (lists chats, not messages) and 'zalo_search_messages' (searches for specific messages). However, the phrase 'that Local MCP captured while linked' introduces some ambiguity about whether messages are stored locally or fetched in real-time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'read_messages' (generic), 'zalo_search_messages', and 'signal_read_messages', the description does not explain the specific use case or prerequisites (e.g., needing an active Zalo connection or prior capture). The agent must infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose key behaviors: it does not state that it is read-only, what happens if Drive is not synced, whether it returns full metadata or just names, or if pagination exists. The scope (locally-synced folder) is vague.
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 concise sentence, front-loaded with the verb 'Lists'. Every word adds value, no superfluous information.
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?
Given no parameters or output schema, the description is minimally viable but lacks details on return value format, file/folder information included, and prerequisites like Google Drive sync setup. It is adequate for a simple list operation but not comprehensive.
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 no parameters; the description implicitly confirms it takes no arguments by stating it lists a fixed path. This is clear enough, though it could specifically say 'No parameters required'.
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 clearly states the tool lists files and folders in Google Drive, specifically the locally-synced folder. It distinguishes from siblings like gdrive_search_files (search) and onedrive_list_files (different service), but could be more explicit that it only lists the root of the synced folder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like gdrive_search_files or finder_list. It does not mention prerequisites (e.g., Google Drive must be synced) or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose authentication needs, return format, or any side effects. The phrase 'detailed information' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but ends with an ellipsis, suggesting truncation. The important identification method is front-loaded, but the trail-off reduces professionalism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 lacks completeness. It doesn't specify what fields are returned, authentication requirements, or error conditions. For a tool with no parameters, more behavioral context is needed.
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 mentions identification by 'user ID or email', adding context beyond the empty schema, though it's unclear how this maps to actual input.
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 detailed info about a specific person from Microsoft 365 directory, using user ID or email as identifier. This distinguishes it from sibling tools like 'get_contact' or 'search_m365_directory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'search_m365_directory' or 'list_contacts'. No context about prerequisites or 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the name. It does not mention that this is a read-only operation, whether it returns all notes or only a subset, or any limitations. With no annotations provided, the description should compensate but fails to do so.
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 concise sentence with no unnecessary words. It front-loads the core purpose and is well-structured.
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?
Given the simplicity of the tool (no parameters, no output schema), the description is minimally sufficient. However, it lacks details such as whether the list includes all notes or just titles, sorting order, or any limitations. For a simple list tool, it could be considered adequate but not comprehensive.
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, and the input schema is empty. The description adds meaning by specifying the app (Apple Notes), which is not evident from the schema. Since schema coverage is trivially 100%, the baseline is 3, but the domain context justifies a 4.
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 clearly states the tool lists notes from the Apple Notes app. It specifies the action (lists) and resource (notes from Apple Notes). However, it does not differentiate from sibling tools like 'search_notes' which also retrieves notes but with filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it does not clarify that 'list_notes' returns all notes without filtering, while 'search_notes' is for filtering. The description provides no context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors. It only states 'lists projects', implying read-only, but does not explicitly state side effects, authentication needs, or output format. This is insufficient for a tool with zero annotation coverage.
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 extremely concise at four words. It is front-loaded and contains no filler. For a zero-parameter tool, this level of conciseness earns a 5.
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?
Given no annotations and no output schema, the description could be more complete by mentioning the return type or usage context. It is adequate for a simple list tool but leaves gaps for the 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 no parameters, and the schema coverage is 100% (empty schema). The description adds no extra parameter meaning, but none is needed. Baseline 4 is appropriate.
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 clearly states it lists projects in OmniFocus, identifying the specific resource. It is distinct from sibling tools that list folders, tags, or tasks. However, it does not elaborate on any filtering or scope, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_omnifocus_folders or list_omnifocus_tasks. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states what the tool does, not its safety profile (e.g., read-only, requires authentication). Since annotations are missing, the description should compensate but does not, earning a 2.
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 is concise and front-loaded. Every word is necessary; there is no fluff or redundancy. It perfectly balances brevity and clarity.
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 simple tool with no parameters and no output schema, the description is minimally adequate. However, it lacks details such as whether all contacts are returned (or paginated), and it does not explicitly state the read-only nature. Given the presence of sibling tools, the agent might benefit from more context. Score 3.
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 coverage is 100%. The description adds value by specifying the scope (Microsoft 365/Outlook), which is meaningful context beyond the empty schema. Per the baseline for 0 params, a 4 is justified.
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 clearly states the verb ('List') and resource ('contacts from your Microsoft 365 / Outlook address book'). It is specific and unambiguous. However, it does not differentiate from sibling tools like 'list_contacts' (which might be from a different service) or 'm365_search_contacts' (which filters contacts). A 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives (e.g., search_contacts for filtering, m365_get_contact for a single contact). The agent receives no help in choosing the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 of behavioral disclosure. It implies a read operation but does not explicitly state nondestructiveness, authentication requirements, or behavior when no events 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?
The description is a single, clear sentence with no wasted words. It is front-loaded and effectively communicates the tool's purpose.
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?
Given no output schema and no parameters, the description is minimally adequate. However, it lacks details about the time frame ('upcoming' is vague), ordering, or what properties are returned, which would help an agent interpret results.
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 and 100% coverage, so the description is not required to explain parameters. The description correctly does not add extra but is sufficient for a parameterless tool.
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 clearly states the action (list) and resource (upcoming calendar events) with specific context (Microsoft 365 / Outlook calendar). However, it does not differentiate from the sibling tool 'list_calendar_events', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic context but lacks explicit guidance on when to use this tool versus alternatives, such as searching for events or using list_calendar_events. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 lists output fields but does not mention side effects (assumed none), authorization or access requirements, error conditions, or whether the tool is read-only. The description is too sparse for a user to understand potential impacts.
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 concise sentence that quickly conveys the tool's purpose. It front-loads the action ('Reports') and the output fields. However, it could be slightly improved by adding a brief note on file selection without making it verbose.
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 simple inspection tool with no output schema, the description covers the main functionality. However, missing context includes how the file is specified (e.g., from current selection or path) and any dependencies. Given the low complexity, the description is mostly adequate but has a notable gap.
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?
There are zero parameters, so the input schema trivially covers 100%. The description adds meaning by enumerating the returned fields, but it fails to explain how the input file is determined. Without parameters, the tool likely relies on application context, which is not addressed.
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 clearly states the tool reports specific metadata fields (duration_ms, width, height, etc.) for video/audio files. It distinguishes from sibling video manipulation tools like video_concat or video_trim. However, it does not clarify how the file is selected (e.g., current context, path), leaving a slight ambiguity.
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 metadata of a media file is needed, but provides no explicit guidance on when to use or not use this tool versus alternatives. No prerequisites or exclusions are mentioned, and there are no sibling metadata tools to differentiate from.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states it reads text but doesn't mention whether the operation is read-only, what side effects might occur, how the file is located, or what the output contains. This is minimal for a tool with no annotations.
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, concise sentence that front-loads the action and resource. Every word adds meaning, and there is no extraneous information.
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 simple read operation with no parameters or annotations, the description provides the core purpose but leaves out important context such as how the file is chosen and what the return value looks like. This makes it minimally viable but not fully 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 tool has zero parameters, so the schema provides no information. The description adds the file format (.pptx), which is useful context, but it doesn't clarify how the target presentation is identified. Given the zero-parameter baseline of 4, this is sufficient.
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 clearly identifies the action ('Reads') and the resource ('slide text content from a PowerPoint presentation'), and specifies the file format (.pptx). This distinguishes it from siblings like ppt_create, though it doesn't mention how the file is selected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as ppt_create or other read tools. There are no exclusions or context clues to help an agent decide between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 mentions removing 'manifests under ~/.local/shar...' but does not explain if the operation is reversible, requires confirmation, or what happens to dependencies. The cut-off text leaves ambiguity about the exact storage location and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and appears cut off, sacrificing completeness for brevity. It lacks structure and fails to cover essential details beyond the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, annotations, and zero parameters, the description should fully explain the tool's functionality. It partially does but leaves critical gaps (e.g., how to specify the recipe, what the outcome looks like).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, but the description does not clarify how the tool identifies which recipe to delete (e.g., relies on context or previous selection). Without this explanation, the agent may not understand how to invoke the tool correctly.
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 verb 'remove' and the resource 'saved recipes/skills', distinguishing it from sibling tools like recipe_install (add) or recipe_list (list). The phrase 'one of THEIR saved recipes' clarifies scope.
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 specifies when to use ('when the user wants to remove one of THEIR saved recipes/skills'). It does not explicitly state when not to use or list alternatives, but the context is clear and no sibling tool offers similar deletion functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It mentions 'single portable token' but fails to describe token format, length, or whether the export has side effects (e.g., deleting the original). The incomplete sentence leaves out important details about what exactly the token is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but ends abruptly as an incomplete sentence. It is front-loaded with the main action, but the cut-off detracts from proper structure.
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?
Given the tool has no parameters and no output schema, the description is mostly sufficient. However, the incomplete sentence leaves the explanation hanging, and the token's nature is not fully described, creating a minor completeness gap.
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, and schema description coverage is 100% by default. Per guidelines, baseline is 4. The description adds meaning by explaining the action, but the cut-off prevents full context.
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 clearly states the tool exports a saved SKILL (recipe) as a single portable token for sharing. This verb+resource combination distinguishes it from sibling tools like recipe_import (import token) and recipe_list (list recipes). The incomplete sentence does not hinder understanding the primary purpose.
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 the tool is used to create a shareable token, but it does not explicitly state when to use it versus alternatives (e.g., recipe_get for details). No guidance on when not to use or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should fully disclose behavior, but it lacks any mention of side effects, authentication requirements, or error conditions (e.g., what if recipe not found). Read-only nature is implied but not stated.
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 sentence, no wasted words. Front-loaded with the action and resource.
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 zero-parameter tool with no output schema, the description is minimal but adequate. It doesn't specify what a 'manifest' includes, which could be ambiguous for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), but the description implies a 'name' parameter exists. This discrepancy reduces clarity. The description adds no useful parameter semantics and may mislead.
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 (returns) and resource (full manifest of a recipe by name). This distinguishes it from sibling tools like recipe_list (listing names) and recipe_discover (discovering recipes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., recipe_list to find a name first). No prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fails to disclose behavioral traits like read-only status, permissions, or side effects. It only states the purpose.
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 sentence, direct and without redundancy. It is concise and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details on search input mechanism, output format, and limitations. For a search tool with zero parameters and no output schema, this is incomplete.
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 baseline score 4 applies. The description does not need to explain parameters, but could have clarified how search input is provided (e.g., from conversation context).
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 clearly states the tool finds specific emails on Apple Mail. It is specific but does not differentiate from sibling tools like list_emails or m365_search_emails.
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 provides a clear use case ('when the user wants to find specific emails') but does not offer exclusions or alternatives, such as when to use list_emails or m365_search_emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose any behavioral traits such as side effects, authentication requirements, state changes, or whether the connection is persistent. The single sentence is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words. It is as concise as possible while conveying the basic purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of parameters, output schema, and annotations, the description is too minimal. It does not explain what 'Connecting Signal to Local MCP' entails, what the result is, or how it fits into the workflow. For a setup operation, this is insufficient.
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 no parameters, so schema description coverage is 100% trivially. Baseline for zero parameters is 4. The description adds no parameter info, but none 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?
The description clearly states the action ('Connect'), the resource ('Signal'), and the target ('Local MCP'). It is specific and distinguishes this tool from sibling tools like signal_list_chats or connect_m365_account.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. It does not mention situations where this connection is needed or how it differs from other connect tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'Reads messages', implying a read-only operation, but fails to detail authentication requirements, message scope (all messages or recent), pagination, or return format. The agent lacks adequate behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (6 words) but at the cost of being under-informative. While there is no fluff, the brevity leaves significant gaps in understanding, such as how the channel is determined. A slightly longer description with workflow context would be better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema) but the description is incomplete. It does not explain how the target channel is selected, what messages are returned (recent, all, count), or any authentication/scope requirements. For a read tool, this is insufficient.
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 is empty (0 parameters), and schema coverage is 100% trivially. Since there are no parameters, the description does not need to add parameter details. The baseline for 0 parameters is 4; no deduction 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?
The description 'Reads messages from a Microsoft Teams channel' clearly states the action (reads) and the resource (messages from a Teams channel). It distinguishes from sibling tools like teams_read_chat_messages (reads from a chat, not a channel) and teams_send_channel_message (sends, not reads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., needing to select a channel first) or exclusions. There is no context about typical workflow steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden but only mentions input modes. Lacks details on behavior if element not found, visibility requirements, or simulation accuracy.
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 sentence, no fluff, directly conveys the action and options. Front-loaded and efficient.
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?
Adequate for a simple click action but lacks details on return values, error handling, and behavior when both or neither parameter is given. No output schema to compensate.
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?
Despite an empty input schema, the description introduces the two parameters (element_ref, coords) and explains their purpose. Baseline 4 for 0 schema parameters; adds value beyond schema.
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?
Clearly states the action (clicks) and two target types (element_ref or coords). Distinguishes from browser-specific siblings by its generic 'ui_' prefix, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives like chrome_click or safari_click. No when-not-to-use or prerequisite information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It only says 'scrapes structured data,' omitting whether the operation is read-only, modifies page state, or requires specific conditions. The agent cannot infer side effects or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks additional context such as output format or usage note. It earns its place but could be more helpful without much bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and no annotations, the description is insufficient. The term 'structured data' is vague, and the agent is left guessing about the return format or any constraints. More completeness is needed to set expectations.
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 schema coverage is 100%. The description adds no parameter detail, but the baseline is 4 for no parameters, as parameter documentation is not 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 clearly states the tool scrapes structured data from the current page, using a specific verb ('scrapes') and resource ('current page'). Among siblings like web_read and web_find, this distinguishes it as a structured extraction tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. The agent receives no context about prerequisites (e.g., page must be loaded) or when to choose web_extract instead of web_read or web_find.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing effects like whether it requires the app to be open, permissions, or what the default list is. For a mutation tool, more behavioral context is needed.
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 sentence, which is efficient and front-loaded. However, it is somewhat under-specified, lacking details that would not add much verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 is thin. It doesn't explain what kind of reminder is created (e.g., title, date) or how the user interacts with it, leaving 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?
The input schema has zero parameters, so there is nothing to describe beyond the tool's action. The description does not repeat schema information. Baseline for 0 params is 4.
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 'creates' and the resource 'a reminder', and specifies the app 'Reminders.app'. This distinguishes it from sibling tools like 'complete_reminder', 'delete_reminder', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions for use. It simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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. 'Deletes' conveys a destructive action but does not state whether deletion is permanent, whether an exact title match must be unique, what happens if no matching note is found, or whether confirmation is required. These are significant omissions for a mutation 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?
The description is a single sentence with no filler, front-loading the action and resource before the targeting details. It earns its place fully.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple in schema, but as a destructive operation with no annotations and no output schema, it should clarify permanence, ambiguity handling, and prerequisites. The discrepancy between the description's 'by ID or exact title' and the empty input schema also makes the definition incomplete for an agent trying to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description claims the tool operates 'by ID or exact title,' which is meaningful parameter information. However, the input schema exposes zero properties, so there is no structured way to pass an ID or title. This mismatch leaves the agent uncertain about what arguments to actually provide and their expected formats.
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 precise verb ('Deletes'), a specific resource ('a note from Apple Notes'), and the accepted selection modes ('by ID or exact title'). This makes the tool's intent unmistakable and clearly distinguishes it from sibling tools like delete_reminder or gdrive_delete_file.
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 the tool should be used when a specific Apple Note needs to be removed, and it even hints at how to target it (ID or exact title). However, it provides no explicit guidance on when not to use it, no mention of listing notes first to obtain an ID, and no comparison to update_note or read_note for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Reads a text file', implying a safe read operation. It does not disclose what it returns, error handling, size limits, or whether the file must be locally synced. Critical behavioral details are missing.
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 redundancy. It efficiently conveys the tool's purpose without extraneous details. Ideal conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the tool has zero parameters yet claims to read a file. The description fails to explain how the file is identified, making the tool effectively unusable. It also omits return value and error conditions. Incomplete for practical use.
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 no parameters, so description cannot add parameter meaning beyond that. Baseline for 0 params is 4. The description adds context about file types, 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 verb 'Reads' and the resource 'text file from the synced Google Drive folder', lists supported extensions, and implicitly distinguishes from sibling tools like gdrive_file_info (metadata) and gdrive_write_file (write). It is 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., gdrive_file_info for metadata, fs_read for local files). The description does not mention prerequisites, when-not-to-use, or explicit context for invoking it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states that it lists events and hints at another mode ('or reads O...'), but fails to mention side effects, permission requirements, rate limits, or handling of recurring events. The read-only nature is implied but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but truncated mid-sentence ('or reads O...'), making it structurally incomplete. While short, the abrupt cutoff violates clear structure and leaves a dangling thought.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain return format, how the date range is provided, permission prerequisites, or what the alternative reading mode entails. The sibling list shows many similar calendar tools, so more differentiation is needed.
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 zero parameters, so the baseline is 4. The description adds the concept of a date range, but this is not represented in the schema, creating ambiguity about how the range is specified. This inconsistency reduces the helpfulness of the added semantic information.
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 events from the Mac's Calendar app' with specific scope (local/iCloud calendars) and a date range filter. This distinguishes it from sibling tools like create/update/delete_calendar_event and m365_list_events. Although truncated, the core purpose is unambiguous.
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 phrase 'in a date range' implies a usage context, and specifying 'Mac's Calendar app' differentiates from Microsoft 365 calendar tools. However, no explicit alternatives or exclusions are mentioned, so guidance is contextual rather than direct.
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?
The description indicates a read operation (Get full details) with no destructive side effects. However, without annotations, it fails to disclose authentication requirements, rate limits, or the exact scope of 'full details'. It is minimally transparent but not misleading.
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 front-loads the verb and resource. It contains no redundant words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the empty input schema, lack of output schema, and no annotations, the description is inadequate. It does not explain how to provide the contact ID, what 'full details' means, or how this differs from related tools like m365_list_contacts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so the description's mention of 'by ID' is contradictory. With schema coverage at 100% (no parameters), the description adds no value and actually misleads by implying a parameter that does not 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 action (Get), resource (full details of a specific Microsoft 365 contact), and method (by ID). It distinguishes from sibling tools like list_contacts and search_contacts which return lists or search results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It mentions 'by ID' but does not explain how to obtain the ID or when to prefer this over list or search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states the search criteria without mentioning any side effects, permissions needed, or limitations like search scope or result format.
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 sentence clearly conveying the tool's action and scope. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and an empty input schema, the description is insufficient. It fails to explain what the tool returns, how to specify search criteria, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, but the description implies parameters for content, sender name, and date range. This contradiction adds confusion rather than clarity. The description does not help understand how to structure a valid input.
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 searches iMessage conversations by content, sender name, or date range. It distinguishes this tool from sibling tools that search other resources (e.g., emails, contacts, notes).
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 for iMessage searches but does not explicitly differentiate from other message search tools like signal_search_messages or slack_search_messages. No guidance on when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It only states 'Full-text search', omitting crucial behaviors like whether a connection via signal_connect is required, what is returned, or any limitations.
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 single-sentence description is concise and front-loaded with the key action, but it could benefit from slightly more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input schema and no output schema, the description is insufficient. It fails to clarify what the search query is (as there are no parameters) or what results to expect, leaving the agent underinformed.
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% (no parameters), so the description doesn't need to add detail. The baseline is high, and the description's lack of parameter info is acceptable.
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 ('Full-text search') and the specific resource ('locally-cached Signal messages'), effectively distinguishing it from sibling tools like signal_read_messages and signal_list_chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., signal_read_messages or the generic search_messages), nor are there any prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It only states 'reads messages' but does not specify that it is read-only, the scope returned (e.g., recent messages), authorization requirements, or if pagination is supported. The description lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is appropriately sized for a simple tool with no parameters, though it could benefit from slight expansion to improve completeness without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and absence of an output schema, the description is incomplete. It fails to mention what the tool returns, any limitations (e.g., only recent messages), or dependencies on prior selections (e.g., active chat). More context is needed for effective use.
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), and the description does not need to explain parameters. It implicitly suggests the tool relies on context (e.g., current chat), which is acceptable 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 reads messages from a Teams chat or direct message thread, specifying the action (reads), resource (Messages), and scope (chat or direct message thread). It distinguishes from sibling tools like 'teams_read_channel_messages' which is for channels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'teams_read_channel_messages' or 'read_messages'. There is no mention of prerequisites, context (e.g., requires an active chat selection), or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses that the tool requires user interaction in a real browser window. However, it does not describe what happens after login or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but truncated, missing a complete statement. It is front-loaded but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 should provide complete context. It explains the action but omits what happens after login (e.g., return value or success indication).
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, so the description does not need to add parameter semantics. Baseline for zero parameters is 4.
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 clearly states the tool opens a real browser window for user sign-in, distinguishing it from other web automation tools. It uses a specific verb and resource, but is slightly truncated.
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 manual user login is needed, but does not explicitly state when not to use it or mention alternatives among the many sibling web tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the output is returned inline but does not disclose whether the session is preserved, any side effects, or dependencies. For a tool with zero annotations, more transparency is needed.
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?
A single sentence of 14 words that front-loads the action. Every word adds value, with no redundancy. Very concise.
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 no parameters and no output schema, the description adequately covers the core functionality. It specifies the output type (PNG) and format (inline). Minor gaps: does not specify if it captures viewport or full page, or if an active session is required, but these are implied by 'current page of a web session'.
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, and schema coverage is 100%. The description adds no parameter info, which is appropriate. Baseline for 0 params is 4.
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 clearly states the action (captures) and the resource (PNG screenshot of current page). It specifies the output format and purpose (returned inline for web AIs). However, it does not explicitly distinguish from sibling tools like screenshot_capture or web_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., need an active web session) or exclusions. The description only states what it does, not the context of use.
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?
There are no annotations, so the description carries the full burden. It discloses the checks performed and implies a read-only health inspection, but it does not explicitly state whether any state is changed, whether it contacts the network, or how errors and malformed outputs are handled.
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 sentence with the purpose front-loaded and immediately followed by useful details. It is compact, though the trailing 'message...' reads as incomplete or cut off, slightly weakening the structure.
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 no-argument diagnostic, the core purpose and output areas are covered, but with no annotations or output schema, more context would help: prerequisites such as an active WhatsApp connection, return format, and whether the command is safe/non-destructive are 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 tool has zero parameters, so no parameter clarification is needed. The description focuses on what the diagnostic reports rather than input semantics, which is appropriate for a no-argument tool.
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 action ('health check') and resource ('WhatsApp'), and lists concrete outputs such as linked account, last sync time, and store lock. It is clearly distinct from other whatsapp_* tools by focusing on diagnosis rather than messaging or connection setup, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to run this diagnostic versus related tools like whatsapp_sync, whatsapp_connect, or run_diagnostics. The phrasing implies troubleshooting use, but there are no stated conditions, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states the action without disclosing idempotency, reversibility, or effects if called on an already completed reminder. The lack of parameters raises questions about how the target reminder is identified.
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 sentence with no wasted words. Front-loads the core action and application.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters, the tool likely requires implicit context (e.g., selected reminder). No output schema is provided. The description is insufficient to understand the tool's full behavior and dependencies.
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, so schema coverage is 100%. Per guidelines, baseline for 0 params is 4. Description adds no additional value but is not required to.
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 (Marks complete), resource (reminder), and application (Apple Reminders), distinguishing it from siblings like create_reminder or delete_reminder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use, prerequisites, or alternatives. The agent must infer context; no details on whether a reminder must be selected or if the tool acts on a specific reminder.
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 clearly states the tool never sends, which is critical for safe use. However, it does not disclose whether it modifies an existing draft, requires a previously composed email, or has side effects (e.g., overwriting drafts). The behavior on input source is opaque.
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 short sentence that front-loads the key action and constraint ('never sends'). Every word is necessary and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input schema and no output schema, the description should compensate by explaining how the email content is determined (e.g., from prior steps, clipboard, or current Mail.app state). It does not, leaving a significant gap in contextual understanding for the agent.
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 zero parameters and 100% schema description coverage. The description adds no additional meaning about parameters because there are none. A score of 3 is appropriate as baseline for high coverage, but the description does not explain why no parameters are needed (e.g., context dependency).
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 clearly states the tool saves an email to Mail.app's Drafts folder and explicitly says it never sends. This distinguishes it from send_email. However, it does not explain how the tool obtains the email content (e.g., it might use a previously read or composed email), which introduces ambiguity.
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 you want to save a draft for manual review, but it does not explicitly state when to use this tool versus alternatives like send_email or create_email_folder. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It notes the creation action but omits details like return value, side effects (e.g., list creation location), error conditions, or required permissions. The agent cannot anticipate what happens after execution.
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?
A single, concise sentence that immediately conveys the purpose. No extraneous words. Well structured for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 lacks essential context such as what the tool returns (e.g., list ID or confirmation) and how it fits into a workflow of creating and managing reminder lists. It is incomplete for an agent to use effectively without additional hints.
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 0 parameters with 100% schema coverage, so no param documentation is needed. The description has no parameter information, which is acceptable given the trivial 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 ('Creates') and the resource ('a new list in Apple Reminders'). It distinguishes from the sibling tool create_reminder which creates individual reminder items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., create_reminder). No mention of prerequisites, typical workflow, or when not to use it. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 of behavioral disclosure. It only states 'Reads data' with no mention of return format, read-only guarantees, error handling, or size limits. It leaves all behavioral traits unexplained.
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, and it is appropriately concise for the tool's simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what 'reads data' returns (e.g., rows, cells, or raw values) and whether it operates on a currently open file. The description is too sparse to fully inform an agent about invocation expectations.
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, and the baseline for no parameters is 4. The description does not need to explain parameter semantics because there are none, though it could mention how the target file is selected (e.g., current context) to add 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?
The description uses a specific verb ('Reads') and resource ('Excel spreadsheet (.xlsx file)'), clearly distinguishing this from sibling tools like excel_create and excel_write_cell. It immediately identifies the tool's primary function and file format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While the name suggests reading rather than writing, there is no explicit contextual cue or exclusion (e.g., 'use excel_write_cell to modify'). The description offers no usage scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only says 'fast health check' without details on what is checked, potential side effects, output format, or permissions needed. Vague.
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 sentence with no fluff. Front-loaded with key information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description is too brief. It lacks details on what constitutes a health check, expected return values, and when it is appropriate to run.
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?
Zero parameters with 100% schema coverage. Description adds no extra meaning but none is needed since there are no parameters. Baseline 4 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 runs a fast health check of all LMCP integrations on the machine. The verb 'runs' and resource 'health check of all LMCP integrations' are specific. It distinguishes from siblings which are individually focused on specific integrations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like lmcp_state or update_self_diagnosis. The context is implied for troubleshooting but lacks clear when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without describing side effects, authentication, rate limits, or output format. As a read-only list tool, behavioral details are minimal but still absent beyond the purpose.
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 9 words, starting with the verb 'Lists'. It is front-loaded and contains no unnecessary words. Every word adds value.
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?
Given the tool has no parameters, no output schema, and no nested objects, the description is minimally adequate. It states what the tool does but lacks context about which workspace it operates on, return format, or prerequisites. A slightly more descriptive sentence would improve completeness.
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 schema coverage is 100%. The description adds no parameter info, but with zero parameters, the baseline is 4. The description does not need to compensate for missing parameter information.
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 clearly states the verb 'Lists' and the resource 'channels in a Microsoft Teams workspace'. It distinguishes from sibling tools like teams_list_chats and teams_list_teams. However, it doesn't specify that it lists channels for the currently connected workspace, which is implicit.
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?
No explicit guidance on when to use this tool versus alternatives. The purpose implies it's for listing channels, but there is no when-not-to-use or alternative mention. Usage is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description only states 'offline' and 'all chats' but fails to disclose read-only nature, permission requirements, or limitations of the search.
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?
A single, front-loaded sentence with 10 words conveys the core purpose without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description omits how to specify a search query (no input schema provides a query parameter), leaving the tool's usage unclear despite a simple concept.
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 zero parameters, the description adds context (offline, all chats) beyond the empty schema, meeting the baseline for 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 does an offline full-text search across all WhatsApp chats, using a specific verb and resource, distinguishing it from sibling tools like 'search_messages'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 of behavioral disclosure. It only says 'Creates a new Word document' without covering overwrite behavior, permission requirements, or failure modes.
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 that directly names the action and key inputs. It contains no redundant filler, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file-creation tool with no annotations and no output schema, the description lacks crucial context such as return values, file overwrite behavior, formatting support, and error conditions. It is not sufficiently complete for confident 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?
The input schema has no properties, yet the description names the key parameters: `path`, text content, and an optional title. This adds essential meaning beyond the schema, though it omits types and required status.
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 creates a new Word (.docx) document at a specified path, with text content and an optional title. This specific verb+resource combination distinguishes it from sibling tools like word_append and word_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The word 'new' implies it is for creating documents while word_append modifies existing ones, but that contrast is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 indicates a state-changing action ('enrolls') but does not specify what changes occur, whether the pairing code is consumed, if the machine needs to be restarted, or what happens if already enrolled. Minimal behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action. However, the text is visibly truncated (ending mid-word at 'ma...'), which harms completeness and structure. It is concise but incomplete as provided.
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 zero-parameter tool with no output schema, the description provides the essential purpose and method. But it omits any indication of return values, success/failure behavior, or post-conditions. The truncation also leaves missing context, so it is not fully 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 tool has zero parameters in the schema, so the baseline is 4. The description adds meaningful conceptual input by mentioning the 'pairing code', which is not represented in the schema but is clearly essential to the operation. This aids agent understanding, though it is not formally defined as a parameter.
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 ('Enrolls THIS machine'), the target resource ('into an existing agent mesh'), and the method ('using a pairing code'). It is distinct from sibling tools like agent_mesh_create or agent_mesh_invite because it focuses on joining this machine to an existing mesh rather than creating or inviting.
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 the use case: the user has a pairing code from another machine and wants to enroll the current machine. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions.
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 carries the burden of disclosing side effects. It mentions immediate removal and consequences (stops appearing in the directory, stops receiving messages), but omits reversibility, permissions, or effects on existing connections. Some transparency is present, but not comprehensive.
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 that efficiently conveys the core action and immediate outcome. No wasted words, and the key information (removal, immediacy, directory removal) appears early.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers immediate effects but fails to specify how the target machine is selected, and the text is truncated. Without parameters or an output schema, the description is incomplete for safe and targeted use. It lacks broader context about the revocation process and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero properties, yet the tool clearly requires a target machine. The description says 'another machine' but does not explain how the target is identified, leaving the agent without essential information. With no parameters, the description should clarify how the target is derived, but it does not, making this a significant gap.
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 ('Removes another machine from this mesh') with a specific verb and resource, distinguishing it from sibling mesh tools like create/invite/join/status. The scope and immediate effect are mentioned, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for revoking a machine from the mesh, but provides no explicit guidance on when to use it versus alternatives, nor any exclusions. The context of being a mesh management tool partially compensates, but explicit when-to-use details are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 does not specify whether the listing is recursive, includes hidden files, or which directory is listed (current working directory vs. a fixed path). The read-only nature is implied by the verb but not explicitly stated.
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 wasted words. Every word contributes to stating the tool's core function.
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 simple zero-parameter tool, the description covers the main purpose, but it lacks behavioral specifics and usage differentiation from sibling file-related tools. It is minimally adequate but leaves room for 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?
The tool has zero parameters and the schema is empty, so the description does not need to add parameter-level detail. The baseline for 0-parameter tools is 4.
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 ('Lists') and resource ('files and folders') with clear scope ('in a local directory'). It distinguishes from remote listing tools like gdrive_list_files and from search tools like file_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as finder_list or file_search. The description implies usage but does not state exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It hints at local scope ('synced on this Mac') but does not explicitly state that the operation is read-only or non-destructive. No side effects or authorization needs 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?
A single concise sentence that front-loads the action and scope. No redundant information.
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?
The description is sufficiently complete for a simple list tool with no output schema, but it could be improved by specifying the kind of information returned (e.g., folder names and IDs). Without an output schema, the agent may need to infer return format from the description.
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, and the schema covers 100% of expected input. The description adds no further parameter meaning, but none is needed. Baseline 4 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 verb 'Lists' and specific resource 'Google Drive folders synced on this Mac'. It also enumerates the scope ('My Drive, Shared drives, per-account mounts'), effectively distinguishing it from sibling tools like gdrive_list_files which list files, not folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., gdrive_list_files, gdrive_search_files). There is no mention of use cases or explicit conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden for behavioral disclosure. It only states 'list', implying read-only, but fails to disclose any side effects, authentication needs, rate limits, or details about the data source. This is minimal transparency beyond the basic purpose.
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 sentence that conveys the core purpose efficiently. However, it is truncated, which may lose some detail. Still, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should provide hints about the return format or structure of the list. It does not mention fields like name, email, or relevance score. For a simple list tool, more completeness is expected to guide the 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 input schema is empty with no parameters, and schema coverage is 100% (default). The description adds meaning by explaining what the list is based on (communication patterns, collaboration), which is valuable context beyond the schema. Baseline for 0 params is 4.
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 'List' and identifies the resource 'people most relevant to you in Microsoft 365' based on communication patterns and collaboration. This clearly differentiates it from sibling tools like 'list_contacts' (general contacts) and 'search_m365_directory' (searchable directory).
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 for automatically generated relevance list but does not explicitly state when to use vs alternatives. No exclusions, prerequisites, or scenarios are mentioned, leaving the agent to infer usage context.
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?
The description implies a read-only operation with no side effects, but without annotations, it does not disclose any potential prerequisites, rate limits, or behavior in edge cases (e.g., if LMCP is not running). 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main purpose. However, it appears truncated (ending with '...'), which slightly reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description only partially lists returned items, leaving the agent uncertain about the full structure. For a complex environment snapshot, more detail is needed to ensure correct interpretation.
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%. The baseline for zero parameters is 4, and the description adds no parameter information, which is acceptable.
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 specifies the verb 'Returns' and the resource 'structured snapshot of the LMCP environment', listing specific items like versions and detected AI client. This clearly distinguishes it from sibling tools like lmcp_welcome or get_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools such as get_config or lmcp_welcome could perform similar informational roles, but no comparison or usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on whether deletion is permanent, if it moves to recycle bin, behavior for non-empty folders, or required permissions. This is critical for a deletion 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?
Single sentence, front-loaded, no unnecessary words. Highly concise and structured.
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?
Minimally adequate for a simple tool without parameters, but lacks behavioral context about permanence and folder requirements. Could be more 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?
With zero parameters, the description doesn't need to add parameter info. Baseline for 0 params is 4, and the description correctly focuses on the 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 clearly states the verb 'deletes' and the resource 'file or empty folder from OneDrive', distinguishing it from sibling tools like onedrive_read_file or onedrive_move_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., moving to trash or other deletion methods). Missing prerequisites, consequences, or context for deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 core function (read/extract text) but omits important details such as whether it handles scanned PDFs, encryption, or what the return format is. No side effects or limitations are mentioned, leaving significant behavioral ambiguity.
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 is direct and front-loaded with the action and resource. Every word earns its place, with no fluff or repetition. It achieves maximum clarity in minimal space.
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 zero-parameter tool with no output schema, the description is minimally sufficient: it identifies what the tool processes and what it produces (text). However, it lacks details about return structure, error cases, or supported PDF variants. Given its simplicity, more context would improve usability but is not strictly required.
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. The description adds no parameter-specific detail, but none is needed since the tool takes no arguments. The description confirms it operates on a PDF document by name, which is the only relevant semantic 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 clearly states the action (reads and extracts text) and the target resource (a PDF document). It distinguishes this tool from siblings like file_read or gdrive_read_file by specifying the PDF file type, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or compare with other file-reading tools. Users are left to infer that this is the PDF-specific reader, but no explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits like system modification, permissions, reversibility, or side effects. It only says 'installs onto this Mac' without elaboration on what installation entails.
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?
A single, well-structured sentence that front-loads the verb and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too brief for a state-modifying tool. It fails to clarify how the 'id' is obtained or passed, and does not explain what happens upon installation (e.g., idempotency, overwrite behavior).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, but the description refers to an 'id' parameter, implying the schema is missing this required input. Schema coverage is 100% only because the schema is empty, but the description contradicts the schema structure.
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 installs a community SKILL by id, sourced from recipe_discover, enabling recipe_run to use it. It distinguishes the tool from siblings like recipe_discover (discovery) and recipe_run (execution).
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 workflow: discover (recipe_discover) → install (this) → run (recipe_run). It does not explicitly state when not to use it or mention alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the basic function and output attributes, omitting any behavioral traits such as whether it requires prior connection, is read-only, or has rate limits. This lacks sufficient transparency for safe agent invocation.
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, clear sentence with no extraneous words. Every word adds value: verb, resource, key output fields. It is optimally concise and front-loaded.
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?
Given zero parameters and no output schema, the description is minimal. For a simple list tool, the core purpose is covered, but the absence of output format details (e.g., array of objects, fields beyond timestamps) and no explanation of non-parameter dependencies leaves some contextual gaps. Adequate but not comprehensive.
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 zero parameters, so schema_description_coverage is effectively 100%. The description adds no parameter information (none needed). Baseline 3 is appropriate as the schema already covers the absence of 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 specifies the verb 'Lists', the resource 'Signal conversations (chats)', and the included information 'with last-active timestamps'. It distinctly identifies the Signal messaging context, avoiding confusion with sibling tools like slack_list_channels or whatsapp_list_chats.
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 a list of Signal chats, but provides no explicit guidance on when to use vs alternatives, no prerequisites (e.g., signal_connect), and no exclusions. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states 'frees it' but does not explain what is freed (memory, handles, auth). No mention of impact on other sessions or reversibility.
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?
Extremely concise: one sentence conveying the core action with no wasted words.
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?
Adequate for a simple tool with no parameters and no output schema. However, missing guidance compared to many sibling tools; could mention return value or confirmation.
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 no parameter info needed. Baseline for 0 params is 4; description adds no param info but also doesn't need to.
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 'closes' and the resource 'web-automation session's window', and the action 'frees it' is specific. It distinguishes from sibling tools like web_session_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., closing a specific tab vs entire session). No prerequisites or side effects mentioned.
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 discloses that it polls rather than sleeping and that it times out, which is useful behavioral information. However, it fails to mention what happens on timeout (error vs. silent return), what it returns, or how the element is identified given no parameters, leaving significant behavioral ambiguity.
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 front-loads the key action ('Waits'), clarifies the mechanism ('polls, not a fixed sleep'), and states the termination condition ('appears... or times out'). This is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the low complexity, the description is incomplete. It doesn't specify how the target element is chosen (since there are no parameters), what the timeout duration is, what happens on timeout, or what the return value indicates. This ambiguity could prevent an agent from using 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. The description doesn't add parameter details, but it also doesn't need to for zero params. However, it mentions 'an element' without clarifying how that element is specified, which is a slight omission but doesn't reduce the score below 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 clearly states the tool waits (polls) until an element appears or times out. It uses a specific verb and resource, making the core purpose clear, though it doesn't explicitly differentiate from sibling wait tools like chrome_wait_for or safari_wait_for.
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 (wait for an element rather than a fixed sleep) but provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites. The 'polls, not a fixed sleep' hint gives some context, but it's not enough to guide tool selection among the many sibling wait tools.
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 is the only source of behavioral info. It adds value by stating it preserves the document's existing content, but the truncated description gives no details on error handling, permissions, or formatting effects. This is a moderate level of 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?
The description is a single, dense sentence that front-loads the core action ('Appends text') and key resource (existing Word document at path). Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutating tool with no annotations, no output schema, and an incomplete input schema, the description fails to cover expected return values, error conditions, preconditions, or side effects beyond preservation. The agent cannot fully anticipate the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references a `path` parameter, but the input schema has zero properties. This mismatch is confusing for an agent, and no type, format, or requiredness details are provided. The schema cannot be used at all, and the description only names the parameter without explaining it.
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 appends text to an existing .docx file at a path, using a specific verb and resource. This distinguishes it from siblings like word_create (which creates new documents) and word_read (which reads).
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 qualifier 'existing' implies it should be used for existing documents rather than new ones, but no explicit exclusions or alternative tools are mentioned. It provides context but not definitive when-to-use guidance.
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?
The description discloses key behavioral modes (create, overwrite, append), which gives some transparency about side effects (e.g., overwriting destroys previous content). However, with no annotations, it does not mention permissions, prerequisites (like required directories), return behavior, or error handling. It is minimal but provides a basic sense of what happens.
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, concise, front-loaded sentence. It conveys the core action ('Writes text to a local file') and the three modes in a compact, readable format. Every word earns its place with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is presented with an empty schema, no annotations, and no output schema, so the description must carry all context. It explains the basic operation and modes but fails to provide any information on how to specify the file path or content, or what the tool expects as inputs. An agent would struggle to invoke this tool correctly based solely on this description.
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 is empty (0 properties), which gives a baseline of 4 per the rubric. The description does not add parameter names or types, but it does imply the conceptual inputs (text, file destination) and modes. Since there are no parameters to document, the description is not penalized for missing details.
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 writes text to a local file with explicit modes (create, overwrite, append). It uses a specific verb and resource ('Writes text to a local file') and distinguishes itself from siblings like file_read or file_list by indicating it performs writes, not reads or listings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention contexts such as needing to create a new file, update an existing one, or append data, nor does it reference sibling tools like file_read or gdrive_write_file. There is no when-to-use or when-not-to-use information.
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 of behavior disclosure. It does add a meaningful behavioral trait (Spotlight-free) and implies a read-only operation. However, it omits critical details such as how the target directory is determined, whether the listing is recursive, or whether hidden files are included, leaving clear gaps.
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 that wastes no words. 'Lists files and folders in a directory' immediately conveys the action and resource, while '(Spotlight-free)' adds key differentiation without excess. It is an excellent example of minimal yet effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too sparse to be fully complete. It does not specify which directory is listed, how the directory is chosen (current Finder window, home folder, etc.), or what the return format is. For a tool with no parameters, this ambiguity is a significant gap that could cause incorrect usage.
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 with 100% coverage. Per the baseline for 0-parameter tools, the description doesn't need to explain parameter semantics. The description avoids introducing any parameter-related confusion, so a baseline score of 4 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's function: 'Lists files and folders in a directory'. The parenthetical '(Spotlight-free)' distinguishes it from the sibling tool 'finder_search' by explicitly signaling that it does not use Spotlight, which helps differentiate from similar file-listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The '(Spotlight-free)' hint implies avoiding Spotlight, but there is no direct statement about when to prefer this over finder_search, file_list, or other file-related tools. Sibling context exists but is not leveraged.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions the allowlist and Spotlight, but fails to disclose how the tool works with zero parameters (how the file name is specified), the scope of the allowlist, potential failure modes (e.g., Spotlight disabled), or the return format. This makes behavior opaque.
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, efficient sentence that leads with the core action and includes a parenthetical implementation note. Every part earns its place; no redundancy or excessive length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description leaves critical gaps: no explanation of how the search query is supplied (given empty schema), no definition of the 'allowlist,' and no output schema or return behavior. A zero-parameter tool needs more context to be usable, so this is incomplete.
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 0 parameters and the schema has 100% coverage (empty), so the description is not required to document parameter details. The baseline for 0 params is 4; no substantial deduction since nothing is missing from the schema side.
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 ('Searches') and resource ('files by name'), and adds scoping context ('within the allowlist') and implementation detail ('uses mdfind/Spotlight'). This clearly distinguishes it from sibling tools like file_search or finder_list.
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 intended use is implied ('search for files by name'), but there is no explicit guidance on when to prefer this tool over siblings, no exclusions, and no mention of alternatives. The 'allowlist' hint suggests a restriction but doesn't instruct the agent on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'recent' without defining recency. It does not mention side effects, permissions, or other behavioral details. For a tool with no annotation coverage, the description should provide more context.
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 sentence, direct, front-loaded with verb and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and description does not explain return format or structure. The term 'recent' is vague. For a simple tool, more info about the output would aid the 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 0 parameters, so the input schema fully covers semantics. Per guidelines, 0 parameters baseline is 4, and the description adds no further param 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?
Description clearly states the tool returns recent LMCP tool call history from the local audit log, with a specific verb and resource. It is distinct from siblings, none of which relate to audit logs.
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?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It only states 'Lists contacts' without detailing whether it returns all contacts, pagination, read-only nature, or output format. Minimal transparency.
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 sentence, no wasted words, front-loaded with action. Very concise, though more detail could be included without harming conciseness.
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?
Given no parameters and no output schema, the description is adequate for a simple list tool but lacks completeness in describing output or limitations. Sibling tools suggest more context could be helpful.
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?
Tool has no parameters, so schema coverage is 100%. With zero parameters, baseline is 4; description adds no further parameter info, which is acceptable.
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 'Lists contacts' and specifies the resource 'from the macOS Contacts app', distinguishing it from sibling tools like 'search_contacts' (which implies filtering) and 'get_contact' (single contact).
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?
No explicit guidance on when to use this tool versus alternatives like 'search_contacts' or 'get_contact'. The description only implies usage for retrieving all contacts, but lacks exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully explain behavior. It describes the returned fields but does not disclose whether the operation is read-only, requires permissions, handles errors (e.g., no displays), or performance characteristics. This is a significant gap for a tool with no annotations.
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 short and front-loaded with the core action and key data fields. However, it is truncated, which slightly reduces its completeness. Efficient but could be expanded slightly.
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?
Given the tool's simplicity (no params, no output schema), the description provides a reasonable summary of what is returned. However, it lacks details on return format (array/object), data types, and edge cases. The truncation also leaves ambiguity about the final field.
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 zero parameters, schema coverage is 100%, baseline is 3. The description adds value by enumerating the return data (bounds, scale_factor, main display), which is not present in the schema. This compensates well for the lack of an output 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 lists connected displays with bounds, scale_factor, and likely main display identification. No other sibling tools appear to list displays, so it is well-distinguished.
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?
No explicit when-to-use or alternatives are provided, but since it is the only display-related tool among siblings, usage is implied. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'lists folders'. It does not disclose behavior such as read-only nature, authentication requirements, or output format. For a tool with no annotations, the description should provide more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise, though it could be slightly more informative while remaining brief.
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?
Given the absence of output schema and parameters, the description is somewhat complete but lacks information about the return format or any additional context. It minimally conveys the tool's purpose but does not cover all contextual needs 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?
There are no parameters (0 params, 100% schema coverage). The baseline score for 0 parameters is 4, and the description adds no parameter info because 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 'Lists folders in OmniFocus' uses a specific verb 'lists' and identifies the resource 'folders in OmniFocus'. It clearly distinguishes from sibling tools like list_omnifocus_projects and list_omnifocus_tags.
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?
No explicit guidance on when to use this tool versus alternatives. While usage is implied (when you need a list of folders), it does not mention exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose any behavioral traits like default scope, sorting, limits, or side effects, leaving the agent uninformed about what exactly happens.
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 unnecessary words, efficiently conveying the core function without verbosity.
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 parameters and no output schema, the description is mostly complete. However, it could be slightly more specific about the scope (e.g., all reminders vs. default list) to fully set expectations.
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 description adds no parameter information. Since schema coverage is 100% and there are 0 params, baseline 4 is appropriate; the description does not need to add more.
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 'Lists', the resource 'reminders', and the source 'Apple Reminders (Reminders.app) on this Mac', distinguishing it from sibling tools like list_reminder_lists or create_reminder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as filtering by list or using list_reminder_lists first. It lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only mentions 'opens' and 'deep link' but omits prerequisites (e.g., desktop app installed), failure modes, or side effects like app focus.
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 sentence, direct and without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simplicity, the description fails to specify which Notion page is opened (no parameters), leaving ambiguity. It should clarify that it relies on context or a default page.
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 (baseline 4). The description adds meaning beyond the empty schema by stating the tool's purpose, which is essential since schema gives no hints.
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 'opens' and the resource 'Notion page in the desktop app (deep link)', distinguishing it from listing, reading, or searching sibling tools.
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?
No explicit guidance on when to use this tool versus alternatives like notion_read_page. The context implies it's for opening in desktop app, but lacks when-not or comparative advice.
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 burden. It discloses the comparison behavior, but does not mention side effects, permissions, or that it is read-only. Adequate but not detailed.
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 sentence, front-loaded with key information, no unnecessary words. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain what the tool returns (e.g., a list of accounts per app or differences). With no output schema, this omission makes it incomplete for an agent to use effectively.
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 in the input schema, and schema coverage is 100%. Per guidelines, 0 parameters leads to a baseline of 4. The description adds no parameter info because 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 clearly states the tool checks configured email accounts in Outlook and compares with Mail.app, using specific verbs and resources. It distinguishes from siblings like 'list_email_accounts' which likely only list without comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'list_email_accounts' or other diagnostic tools. The context is implied but not stated.
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?
The description discloses key traits: it is anonymous, content-free, and is a signal (likely telemetry). However, it is truncated and does not mention what happens after sending (e.g., return value, logging, or user impact). With no annotations, the description carries the full burden, and missing the conclusion leaves some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The visible portion is a single, run-on sentence listing conditions, and it is clearly cut off mid-word. While it is not unnecessarily verbose, the truncation and awkward listing make it less structured than an ideal description. It earns a middle score due to its brevity but loses points for incompleteness.
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 zero-parameter tool, the description gives necessary trigger conditions and signals that it is anonymous and content-free. However, the truncation means it lacks a conclusion (e.g., what the agent should expect afterward). With no output schema, the description should clarify the tool's effects, and it does not fully do so.
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, so the schema is inherently complete (100% coverage). The description does not need to explain parameters, and it doesn't. Per the baseline for 0 params, a score of 4 is appropriate.
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 clearly states the tool sends an anonymous, content-free signal when an LMCP tool fails or returns nothing useful. It uses a specific verb ('send') and resource ('signal') with trigger conditions, making the purpose clear. It doesn't fully distinguish from sibling 'report_problem', but the 'content-free signal' wording gives it a distinct identity.
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 when to use the tool: 'when an LMCP tool fails, returns nothing useful, the user seems frustrated...' This provides clear context for invocation. It does not mention alternatives or exclusions, but the trigger conditions are specific enough for an agent to decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits like performance, rate limits, or authentication requirements. The tool is likely safe and read-only, but this is not explicitly stated.
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?
A single, well-structured sentence that front-loads the core information with no wasted words. Ideal for quick parsing.
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 parameterless list operation, the description is largely adequate. However, it does not specify the return format or data structure, which could be inferred from context but is not explicitly stated.
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 no parameters, so there is nothing to document. The description correctly implies the tool requires no inputs, and with baseline 4 for zero parameters, it adds no additional meaning beyond the schema but doesn't need to.
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 Microsoft Teams chats, specifying the resource (chats) and scope (direct messages and group chats). It effectively distinguishes from sibling tools like teams_list_channels and teams_list_teams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as list_message_chats or teams_list_channels. The description lacks context about prerequisites or scenarios.
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 bears the full burden. It does disclose a key behavioral trait: the tree is 'COMPACT' and limited to 'labeled + interactive elements', which helps the agent know not to expect all nodes. However, it lacks details on whether accessibility permissions are required, how the tree is structured, or if there are any latency implications.
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 that immediately states the primary purpose. It uses no filler words and every element ('COMPACT', 'labeled + interactive') adds value. Although truncated in the prompt, the provided text is highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema and annotations, so the description should clarify the return format, but it only says 'accessibility tree' without specifying whether it is a string, JSON, or a visual representation. It also omits prerequisites like 'app must be running' or accessibility permissions. Given the zero-parameter simplicity, the description is incomplete for an agent to confidently use the result.
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 input schema is empty, so there are no parameter semantics to clarify. Per the rubric, a baseline of 4 is appropriate when there are no parameters; no additional description 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?
The description clearly states the tool returns a 'COMPACT accessibility tree' of a running native app's 'labeled + interactive elements', using a specific verb ('Returns') and a specific resource. This distinguishes it from siblings like ui_get_element and ui_find_element, which target individual elements rather than the whole tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention alternatives or conditions such as 'use this to get the full UI structure' or 'prefer ui_find_element for locating a single element'. The description is purely functional with no contextual placement among the many UI-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates destructive behavior (blurring/pixelating) but does not explain how rectangles are specified, what the output is, or potential side effects like permanent changes.
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, efficient sentence that conveys the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/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 should clarify how the agent invokes the tool. It lacks guidance on specifying rectangles or expected input, making it incomplete for reliable 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 has zero parameters, so baseline is 4. However, the description fails to explain how the tool determines which rectangles to blur, leaving ambiguity. It adds minimal value 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 identifies the tool's action: pixelating/blurring rectangles over video for redacting PII. It distinguishes itself from other video tools like trim, concat, etc., by specifying its unique redaction 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 states 'the tool for redacting PII', providing clear context for when to use it. It does not explicitly list when not to use it, but the use case is well-defined, and sibling tools cover other video operations.
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 full burden. It correctly indicates a read operation with a preview, but does not disclose pagination, authentication requirements, or any side effects. The behavioral insight is minimal.
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, clear sentence with no wasted words. It is front-loaded and efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what properties each chat entry contains (e.g., name, last message sender, timestamp). The agent lacks sufficient information to interpret the tool's output.
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, and the input schema is empty. The description adds no parameter info because none exist. According to guidelines, 0 parameters yields a baseline of 4, which is appropriate here.
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 WhatsApp conversations with a last message preview. The verb 'lists' and noun 'conversations' are specific, and it is distinct from sibling tools like whatsapp_read_messages or whatsapp_search_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., whatsapp_search_messages for searching, or signal_list_chats for Signal). The description lacks any contextual cues for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states the output is text content, but it does not explain how the tool determines which .docx file to read since no parameters are provided. This is a significant gap in transparency regarding invocation and potential limitations.
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 that conveys the essential information without any fluff or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and no parameters, the description should provide more context about how the file is specified and what exactly is returned. The description only says 'text content' but omits critical operational details, leaving the agent without enough information to use 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 tool has zero parameters, so schema coverage is trivially 100%. Per the baseline for 0 params, the description need not explain parameters. However, the description does not clarify the implicit mechanism for selecting the file, which is a minor gap, but the baseline 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 clearly states the tool's function: 'Reads text content from a Word document (.docx file).' The verb 'Reads' and the resource 'Word document (.docx file)' are specific, and it is easily distinguished from siblings like word_append and word_create which modify or create documents.
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 the tool is for retrieving text from .docx files, but it does not explicitly state when to use it over alternatives like pdf_read or file_read, nor does it mention any exclusions or context such as local file paths or integration with other tools. Usage is inferred rather than explicitly guided.
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 carries full burden. It states it lists conversations but gives no details on authentication, rate limits, or output structure. The behavior is straightforward but lacks depth.
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, concise and front-loaded with key information. No wasted words.
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?
Given no output schema or annotations, the description is minimal. It could specify what information is returned per conversation (e.g., name, ID) to aid agent understanding.
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, baseline score of 4 applies. The description adds no parameter-specific detail, which is acceptable.
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 clearly states it lists Zalo conversations (friends and groups) for picking a recipient, using specific verb and resource. It distinguishes from other Zalo tools but not from sibling chat list tools for other platforms.
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 before sending a message ('so you can pick a recipient') but provides no explicit when-to-use or alternatives. For a simple tool, guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 tool creates a new .xlsx file but does not mention whether it requires special permissions, where the file is saved, whether an existing file can be overwritten, or what the return value is. For a side-effecting tool, this leaves important behavioral traits undisclosed.
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 earns its place: it names the action, the file type, and the core content options. This is ideal conciseness.
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 zero-parameter creation tool, the description provides the essential purpose and input concept, but it omits key operational details such as the file save location, whether a file path is returned, and how the 'headers and optional data rows' are supplied given the empty schema. The lack of an output schema makes these omissions more significant, resulting in a minimum-viable but not fully complete description.
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 per the rubric the baseline is 4. The description adds some useful context by mentioning 'headers and optional data rows', giving the agent an idea of what the tool can accommodate, even though no parameters are defined in the schema. It does not need to explain parameter syntax 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 uses a specific verb ('creates') and a specific resource ('Excel spreadsheet (.xlsx file)'), and it differentiates from sibling tools like excel_read and excel_write_cell by clearly indicating this is for making a new file. It also specifies the content ('headers and optional data rows'), which is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when creating a new Excel file, which is enough to distinguish from read/write operations, but it does not explicitly state when to prefer this tool over alternatives or mention any exclusions. The usage context is only implied by the verb 'creates'.
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 behavioral disclosure burden. 'Lists' implies a read-only operation and the returned fields are named, which is useful, but the description does not mention output format, permissions, errors, or whether Mail.app access is required.
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. It states the action, resource, and returned fields efficiently.
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 zero-parameter list tool, the description covers the essential information an agent needs: what is listed and what fields are included. It could be slightly more complete by stating that no arguments are required or that it returns an array, but the current level is largely sufficient.
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 and 100% schema description coverage, so the baseline is 4. The description adds value by clarifying what each returned account entry contains, which is sufficient for a parameterless tool.
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 uses a specific verb ('Lists') and a clear resource ('Mail.app email accounts') plus the exact fields returned. It is unambiguous about what the tool does, though the sibling list_email_accounts could create some ambiguity that is not explicitly resolved.
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 this tool is for reading Mail.app account metadata, which provides enough context for basic selection. However, it gives no explicit guidance on when to prefer it over list_email_accounts or other account-related siblings, and no exclusions are stated.
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 exist, so the description must carry the behavioral disclosure burden. It states the tool lists calendars but does not mention any side effects, permissions, or performance implications. For a simple read-only list, this is minimally adequate but lacks depth.
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, focused sentence with no extraneous information. It is front-loaded and efficiently conveys the essential purpose.
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?
Despite zero parameters and no output schema, the description omits details about the return format (e.g., list of strings) and any ordering or filtering. It is minimally complete but leaves some ambiguity about what the agent can 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?
The tool has zero parameters, and schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline score of 4 applies as per guidelines.
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 'Lists the calendars' and specifies the resource: the Mac's Calendar app (Calendar.app, local/iCloud). It is unambiguous and distinguishes itself from sibling tools like list_calendar_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives, nor does it mention any prerequisites or context. Given the sole purpose of listing calendar names, guidance is minimal but absent.
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 should disclose behavioral traits. It mentions that nested target folders are found by name, which is helpful, but does not specify what happens if the target folder doesn't exist, whether it's a move or copy across accounts, or any side 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?
One concise sentence that is front-loaded with the core action. No wasted words.
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?
Given the empty schema and no output schema, the description lacks context on what constitutes a mailbox, whether it works across accounts, and what the outcome is. It is adequate but not complete for a tool with no structured metadata.
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 no parameters, so the description has no obligation to explain parameters. The baseline is 4 for zero 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 'moves an email' and the destination 'to another mailbox', with a specific detail about nested target folders. It distinguishes itself from sibling email tools like send_email or create_draft.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, nor any prerequisites or exclusions. The description does not help an agent decide between tools like move_email and other email operations.
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 partially carries the burden. It lists what checks are performed but does not disclose side effects, safety profile, or output format. Since it's a diagnostic, likely safe, but minimal behavioral context is given.
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, front-loaded sentence that directly states the purpose. However, it appears truncated (ends with 'supported...'), reducing completeness slightly. One sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no annotations, the description is incomplete—truncated and lacks details on return values, output format, or whether it performs any side effects. For a diagnostic tool, more context is expected.
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 input schema provides complete coverage. The description adds meaning by enumerating the diagnostic areas (installation, login, etc.), which helps agents understand what the tool returns.
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 runs a diagnostic check on NordVPN, listing specific aspects (installation, login state, connection status, kill switch). It is a specific verb+resource and distinguishes from sibling tools like 'nordvpn_status' which likely only shows current status.
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 does not provide explicit guidance on when to use this tool versus alternatives like 'nordvpn_status' or 'run_diagnostics'. Usage is implied by the diagnostic nature, but no when-not-to or alternative comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose key behaviors such as whether existing files are overwritten, what permissions are required, or what the function returns. It only specifies the input format, leaving side effects and error handling unclear.
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 concise sentence that front-loads the purpose and includes the essential input format. There is no wasted wording, and it reads clearly.
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?
Given the absence of annotations and output schema, the description is the sole source of information. It covers the key input (path and slides) but leaves out return behavior, overwrite semantics, and error handling, making it minimally viable but not fully complete for an agent to use without uncertainty.
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 is empty, so the description is entirely responsible for parameter semantics. It introduces `path` and the slides array with a clear shape ({title, bullets:[…]}), which is meaningful and helpful. However, it omits explicit types and any optional parameters, so it does not fully compensate for the absence of schema properties.
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 (creates), the resource (PowerPoint .pptx), and the destination (path), and specifies the input structure as an array of slides with title and bullets. This distinguishes it from sibling tools like ppt_read and other document creation tools.
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 for creating presentations, but it does not explicitly state when to use this tool over alternatives such as ppt_read or word_create. There are no mentions of prerequisites, exclusions, or preferred contexts, so the agent must rely on the verb 'creates' to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose how target is selected, whether it saves to file or returns data, or any side effects. Minimal behavioral detail.
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 sentence of 10 words, perfectly concise with no superfluous information. Front-loaded with the verb and resource.
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?
Despite no output schema, description does not explain return value format (e.g., file path, base64). For a simple capture tool, some return details are expected. Adequate but not fully 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?
No parameters defined, so description does not need to explain them. Baseline for 0 params is 4. Description mentions capture targets but adds no parameter-related 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?
Description uses specific verb 'Captures' and resources 'display, window, or region' with output format 'PNG'. Clearly distinguishes from screen recording siblings and browser-specific screenshots.
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?
No explicit guidance on when to use this tool vs alternatives like screen_record_start or web_screenshot. Usage is implied for static captures, but lacks direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the source ('Slack Desktop') without detailing any behavioral aspects such as error handling, permission requirements, or potential side 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 a single sentence, concise, and front-loaded with the key action and subject. Every word adds value.
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 simple tool with no parameters and no output schema, the description is minimally adequate. It could provide more detail about what information is returned (e.g., workspace IDs, names) to be fully 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 no parameters, so schema description coverage is 100%. The description adds no parameter information, but the baseline for zero parameters is 4.
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 Slack workspaces (teams) connected in Slack Desktop. It uses a specific verb ('Lists') and resource ('workspaces'), and distinguishes from sibling tools like slack_list_channels by specifying scope.
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?
No explicit when-to-use or alternatives are mentioned. However, the purpose is straightforward and the context implies it is a prerequisite for tools requiring a workspace, but no guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states 'reads the current page', lacking details on output format, side effects, or requirements. The minimal disclosure is insufficient for a tool with no annotations.
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 a clear verb-object structure. It is front-loaded and contains no wasted words, earning its place efficiently.
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?
Given no output schema and no parameters, the description covers the basic action. However, it omits what exactly is read (HTML, text, markdown) or how the output is structured, which could leave an agent uncertain about the return value.
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 zero parameters and 100% schema coverage (trivial), the description adds no parameter-specific meaning. Baseline for zero-parameter tools is 4, and the description succinctly describes the action without needing parameter details.
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 reads the current page of a web session for reasoning. It uses a specific verb ('reads') and resource ('current page of a web session'), and implicitly distinguishes from siblings like 'web_navigate' or 'web_click'.
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 for reading page content but offers no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like 'web_extract' or 'web_eval', leaving differentiation to inference.
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 discloses that the tool forces a sync and blocks until completion ('THEN returns'). However, it does not mention potential side effects like overwriting local data, failure behavior, or whether it's idempotent. This partial transparency aligns with a mid-range score.
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, well-structured sentence. It conveys the action, target, and synchronous nature without extraneous detail. The front-loaded verb 'Forces' and the added 'THEN returns' provide clarity in an extremely concise format.
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?
Given the simplicity (no params, no output schema), the description covers the core behavior. However, it omits the return value (what the caller receives) and any failure/error semantics. It also doesn't explain that this is a prerequisite for reading fresh WhatsApp data, which would enhance usefulness.
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 an empty schema, so schema coverage is 100%. Per the baseline for 0 params, a score of 4 is appropriate. The description doesn't need to elaborate on parameters that don't 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 tool performs a sync: 'Forces WhatsApp to pull the latest messages, groups and contacts into the local store'. The verb 'pull' and the specific resources distinguish it from siblings like whatsapp_connect (connection setup) or whatsapp_list_chats (reading from local store).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to invoke this tool versus alternatives. It doesn't mention that this should be called before reading latest data or that it's unnecessary when cached data is acceptable. The description is purely functional without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects (e.g., whether state is modified), required user interaction (scanning QR), or if the tool is destructive. Minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Fully front-loaded and efficient.
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 zero-parameter, no-output tool, the description is adequate but sparse. Missing details like whether it returns success/failure, whether the QR requires external scanning, or if it connects immediately.
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 100%), so the baseline is 4. The description adds no parameter info, but none 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?
The description clearly states the action ('Link Zalo to Local MCP') and the mechanism ('by showing a QR code right here in the chat'). It distinguishes from sibling tools like zalo_disconnect and zalo_list_chats.
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 it's for initial setup, but does not explicitly state when to use it vs. alternatives (e.g., after connection is established, use other Zalo tools). No when-not-to or exclusions.
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 for behavioral disclosure. It adds valuable details: single-use and 15-minute validity. Yet it omits other aspects like permissions required, whether existing invites are invalidated, or what the response contains. The absence of these details leaves the agent without a complete safety/behavioral profile.
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 sentence, front-loaded with the verb and core resource. It is efficient and easy to parse. However, the sentence ends abruptly with 'ag...', suggesting truncation, which slightly undermines the structural completeness.
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 zero-parameter tool with no output schema, the description covers the essential purpose and key constraints (single-use, 15-minute validity). Still, it does not explain how this fits into the broader mesh flow (e.g., that agent_mesh_join consumes the code), and the truncation leaves the context incomplete. A fully articulated alternative reference would make it more 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 tool has zero parameters, which per rubric is a baseline 4. The description appropriately says nothing about parameters because none exist. No additional semantic meaning is needed beyond what the empty schema already conveys.
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 creates a 'single-use pairing code' with a specific intent to be redeemed by another machine. This is distinct from sibling tools like agent_mesh_join (which presumably redeems) and agent_mesh_revoke (which revokes). The verb 'Creates' and resource 'pairing code' make 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'another of the user's machines can redeem' implies the use case of pairing a new device, and the 15-minute validity hints at time-sensitive usage. However, there is no explicit 'use this when' or mention of alternatives (e.g., agent_mesh_join for redemption), and the truncated ending 'ag...' suggests incomplete guidance.
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. It discloses the main effect (disconnect and remove tokens) but lacks details on side effects, safety, or required permissions.
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, direct sentence with no wasted words. Ideal conciseness for a simple 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?
For a straightforward tool with no parameters and no output schema, the description is adequate. Could add note about invalidating connection, but not essential.
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?
Tool has zero parameters, so no parameter explanation is needed. Baseline of 4 applies as description adds no param info (correctly).
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 'disconnect' and the resource 'Microsoft 365 account' and 'stored tokens', distinguishing it from the sibling 'connect_m365_account'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, prerequisites (e.g., being connected first), or when not to use it. Given the sibling 'connect_m365_account', explicit context would be beneficial.
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 full burden. It correctly indicates no side effects but does not disclose potential constraints like permission requirements or whether it works offline. Minimal but not misleading.
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 sentence that is front-loaded with the verb and includes specific details. No filler.
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?
Adequate for a simple metadata tool, listing key fields. Could mention if it works for both files and folders (it does) and any error conditions, but overall sufficient.
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 description does not need to clarify parameters. It adds value by listing the returned metadata 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 returns metadata (size, modification date, type, extension) for a file or folder, which distinguishes it from sibling tools like onedrive_list_files or onedrive_read_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, or any prerequisites or limitations. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states listing behavior without disclosing potential side effects, permission requirements, or limitations (e.g., only shows top-level mounts). Fails to add transparency beyond the basic 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?
Single sentence of 8 words, no filler. Front-loaded with verb. Every word is essential and clear.
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 no parameters and no output schema, the description adequately conveys the action and scope. Might benefit from clarifying that it only returns root-mounted directories, but overall sufficient.
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?
Tool has zero parameters, so schema coverage is 100%. Description naturally cannot add parameter semantics, earning a baseline of 4 as per guidelines for zero-parameter tools.
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 'Lists' and resource 'all mounted OneDrive directories' with scope 'on this Mac'. Clearly distinguishes from siblings like onedrive_list_files and gdrive_root.
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?
Description states what the tool does but offers no guidance on when to use it versus alternative tools like onedrive_list_files or onedrive_search_files. No exclusions or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose any behavioral traits beyond the basic action, such as authentication requirements, whether accounts need to be preconfigured, or any side 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?
Single sentence, front-loaded with the key intent, no 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 simple tool with no parameters and no output schema, the description is reasonably complete; it could be improved by noting return behavior or prerequisites.
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 zero parameters and schema coverage is 100%; description adds no parameter information but is adequate given no parameters 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?
Description clearly states the verb (send) and resource (email) and distinguishes from sibling tools like m365_send_email by specifying the Apple Mail context.
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 when to use (user wants to send email from Apple Mail), but does not mention when not to use or list alternative tools like m365_send_email or reply_email.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states what is listed, lacking details on side effects, authentication requirements, 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?
A single, front-loaded sentence under 20 words that efficiently communicates the tool's function without superfluous detail.
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 no parameters and no output schema, the description is mostly adequate. It could clarify which workspace is used, but given the tool name, it is sufficient.
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 has zero parameters, so schema_description_coverage is 100%. The description adds no parameter info, but none is needed. Baseline for 0-param tools is 4.
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 'Lists' and resource 'channels', clearly stating it includes public, private, and DM channels. It effectively distinguishes from sibling tools like slack_list_workspaces and slack_read_channel_messages.
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?
No explicit guidance on when to use vs. alternatives is provided. The usage is implied as listing channels, but the description does not mention conditions or exclusions.
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 disclose behavior itself. It states the primary action and effect but omits details like irreversibility, idempotency, or error behavior. The 'closes it' phrase adds a little context, but the description is minimal.
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 one short sentence that is immediately informative and contains no wasted words. It's appropriately sized 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?
For a tool with zero parameters and no output schema, the description states the core action adequately. However, it doesn't mention how the target task is identified (e.g., via context), which is a minor gap given the zero-parameter design.
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. The description doesn't need to explain parameters, and there are none to document.
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 the specific verb 'mark' and names the resource 'Todoist task', with 'closes it' clarifying the effect. This clearly distinguishes it from siblings like complete_omnifocus_task or complete_reminder.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It doesn't mention context like requiring a selected task or connection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It only mentions bringing the window to front and user takeover, omitting details like side effects, prerequisites (e.g., existing session), or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it appears truncated (ends with 'co...'), which reduces clarity and professionalism.
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 no parameters and no output schema, the description is fairly complete. It explains the primary action and a common use case. However, it could mention the relationship to browser sessions or session management tools.
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. No param information is needed, and the description doesn't need to compensate.
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 brings a web session's browser window to the front for user interaction, e.g., to solve a CAPTCHA. It distinguishes from sibling tools that perform automated actions like clicking, navigating, or reading.
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 when user intervention is needed, like solving CAPTCHAs. It provides context but lacks explicit when-not-to-use instructions or alternatives among siblings.
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 carries the full burden. It states the core behavior (focus and activate) but does not disclose potential side effects (e.g., focus stealing), error conditions (e.g., invalid window_id), or required permissions. 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?
A single sentence of 14 words, front-loading the action. Every word is necessary; no redundancy or extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a rich sibling ecosystem, the description is too minimal. It lacks prerequisites, error handling, or behavioral nuances expected for a focus-changing tool. Should provide more context for safe agent usage.
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. Per calibration, baseline is 4. The description adds context by stating that the window_id comes from list_windows, which is meaningful beyond the empty 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 (brings to front, activates) and the resource (window), referencing the source of window_id from list_windows. This is specific and distinguishes from sibling tools like window_set_frame.
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 that window_id comes from list_windows, hinting at appropriate usage, but lacks explicit when-to-use, when-not-to-use, or alternatives. It provides minimal guidance for an agent to decide between this and other window tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It notes the tool self-upgrades LMCP and does not edit user files, but omits potential side effects such as app restarts, network requirements, or permission needs—a significant gap for a mutation 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?
The description is a single sentence that front-loads the core action and adds a clarifying parenthetical. Every word contributes, with no fluff or repetition.
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 parameterless tool, the description covers the main behavior and one exclusion. However, without annotations, it does not fully disclose operational consequences (e.g., whether confirmation is required or what happens if no update exists), making it only moderately 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 no properties, so schema coverage is trivially 100%. The description appropriately does not discuss parameters, and the baseline score of 4 is appropriate for a zero-parameter 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 'Checks for and installs a newer LMCP version' with a specific verb and resource. The parenthetical 'a self-upgrade of the LMCP app itself' distinguishes it from sibling tools like lmcp_upgrade_diagnostics and clarifies it is not a data-editing tool.
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 when to use the tool (to check for and install LMCP updates) and gives an exclusion with 'not editing any of your...' However, it does not name an alternative tool for editing, so guidance is clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral transparency. The description fails to disclose critical behavioral details, such as whether the reply creates a draft or sends immediately, permission requirements, or side effects (e.g., adding to sent items).
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, well-structured sentence that front-loads the key purpose and context. Every word contributes to understanding, with no unnecessary verbiage.
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?
Given the tool's simplicity (0 parameters, no output schema), the description partially covers the core action. However, it omits important behavioral details (e.g., reply behavior, attachment handling, draft vs. send) that would reduce 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?
The input schema has zero properties, and schema coverage is 100% (vacuously). The description references a 'message ID' implicitly, adding context, but does not formally document parameters. With 0 parameters, the baseline is 4, and no further parameter 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?
The description clearly states the tool's action ('reply to a Microsoft 365 email') and identifies the necessary resource ('message ID from m365_list_emails'). It distinguishes itself from related tools like send_email and create_draft.
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 context for when to use the tool (when the user wants to reply to an email retrieved via m365_list_emails), but it does not explicitly state when not to use it or suggest alternatives among siblings.
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?
The description discloses that the data comes from a local cache ('cached on this Mac'), which is useful behavioral context beyond what annotations would provide (none present). However, it does not explain cache freshness, behavior when cache is empty, or potential side effects, leaving some gaps.
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, clear sentence with no wasted words. It front-loads the key action and resource, and every part is informative.
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?
Given no output schema, the description does not detail the return format or handle edge cases (e.g., no cached databases). It states 'with their schema' but lacks specifics on how the data is structured, which is moderately incomplete for a tool with no output schema.
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, and the schema coverage is 100%, so the description need not add parameter details. Baseline 4 applies per instructions; the description succinctly covers the tool's 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 uses a specific verb 'Lists' and resource 'Notion databases cached on this Mac', clearly distinguishing it from siblings like 'notion_list_pages' (pages) and 'notion_read_database' (read a specific database's content). It also specifies the output includes schema, adding clarity.
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 use when you need to see available databases and their schemas, but it does not explicitly state when to use this tool versus alternatives (e.g., 'notion_list_pages' or 'notion_search'). No exclusion criteria or alternative recommendations are provided.
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 full burden. It discloses a key behavior: it does not send, it returns guidance for the user to send. However, it lacks details about prerequisites (e.g., Signal connection), what the guidance format is, or any side effects. Basic transparency is present.
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 directly states the tool's function. No unnecessary words or repetition.
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?
Despite the tool's simplicity, the description omits important context: how the message content is determined with zero input parameters, and what the step-by-step guidance looks like. Since there is no output schema, the description should clarify the deliverable format. It adequately states the outcome but leaves the mechanism ambiguous.
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 0 parameters, the baseline is 4. The description adds minimal meaning beyond the schema, but since there are no parameters, there is little to explain. The phrase 'Composes a Signal message' may imply context-derived input, but that is not elaborated.
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 composes a Signal message and returns step-by-step guidance, explicitly differentiating it from tools that actually send messages (e.g., send_message, whatsapp_send_message). 'Composes' and 'guidance' make the resource and action specific.
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 purpose implies when to use it (when the user needs to send the message themselves), but it does not explicitly mention alternatives or exclusions. There is no guidance on when NOT to use it or when to prefer an actual sending tool.
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?
There are no annotations, so the description carries the full burden. It transparently states this is a search operation over history and specifies the scope, but does not disclose limitations such as whether channels are excluded, authentication requirements, or the exact return format.
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, front-loaded sentence that immediately states the action and resource. It is concise and to the point, though it appears truncated (ends mid-word 'sender n...'), which slightly reduces polish.
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 read-only search tool with no output schema or annotations, the description covers the core aspects: what is searched (chat and DM history), the search criteria, and the all-conversations scope. It does not explain return values, but that gap is acceptable given the tool's simplicity.
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. The description adds meaningful semantics by stating that searching happens by text and sender, even though no schema properties exist. This helps an agent understand the intended query syntax despite the empty 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 uses a specific verb ('Searches') and names the exact resource ('Microsoft Teams chat and direct-message history') with an explicit scope ('all conversations at once'). It also indicates the search criteria (by text, sender). This clearly distinguishes it from tools like teams_read_chat_messages or search_messages.
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 an appropriate use case: searching across all Teams chats and DMs at once rather than reading a specific chat. However, it does not explicitly exclude channel messages or name alternatives like teams_read_chat_messages for targeted reads, so it provides only implied 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, the description carries full burden. It discloses the location (~/Documents/Zoom), sorting order (newest first), and listed fields (meeting name, date). It does not mention read-only status or permissions, but the behavior is sufficiently transparent for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence, but it is truncated ('dat...'), which suggests incomplete information. While concise, truncation undermines clarity.
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 simple list tool with no input schema or output schema, the description covers the essential behavior (source, sorting, fields) but is truncated and lacks details about potential errors or limitations (e.g., only local files, no search/filtering).
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, so the description needs to add no parameter info beyond the schema. It adds value by describing the output content (meeting name, date), which compensates for the lack of 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 lists locally saved Zoom recordings from ~/Documents/Zoom, sorted newest first, including meeting name and date. It uses a specific verb ('Lists') and resource, distinguishing it from the sibling 'zoom_read_transcript' which reads transcript content.
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 use for browsing local recordings but provides no explicit guidance on when to use or not use this tool versus alternatives. No exclusions or context for sibling tools like 'zoom_read_transcript' are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states the primary action of notifying senders; it does not disclose whether messages are marked as read, any irreversible effects, or prerequisites beyond reading via agent_inbox. This is insufficient for a tool that has side 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 a single, direct sentence, front-loaded with the action ('Tells the senders') and no unnecessary wording. Every word 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 parameterless tool with no output schema, the description covers the core functionality and references the related agent_inbox. It could add a note about when exactly to use it, but overall it is sufficiently complete for its simplicity.
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, so schema coverage is vacuously 100%. The description does not need to explain parameter semantics, and the baseline for 0-param tools is 4.
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 ('Tells') and clearly identifies the resource ('senders' regarding 'messages agent_inbox gave you'). It effectively distinguishes this tool from messaging tools like agent_send by focusing on acknowledgment rather than sending new 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 clearly implies the context: use this after reading messages via agent_inbox to confirm receipt. It provides a clear usage context without explicit exclusions, but it does not name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does reveal that the current machine becomes the first member, but omits any consequences, side effects, prerequisites, idempotency, or failure behavior. This is minimal disclosure for a state-creating 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?
A single, front-loaded sentence with zero filler. Clearly states the action, the resource, and the key distinctive detail about the current machine, making every word count.
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 zero-parameter, no-output-schema tool, the description covers the essential purpose and the unique 'first member' aspect. However, it doesn't mention follow-up actions like inviting other members, which would be helpful given the sibling mesh tools, but the simplicity of the tool keeps the gap modest.
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 the baseline for parameter semantics is 4 per rubric. The description adds no parameter meaning because there are none, but it correctly implies no inputs are needed for the operation.
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 a specific verb ('Starts') and clearly identifies the resource ('agent mesh') while adding the unique scope 'with THIS machine as its first member.' This distinguishes it clearly from sibling mesh tools like join/invite/revoke by indicating it is the genesis operation.
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 phrase 'new agent mesh' and 'first member' implicitly convey that this is for creating a fresh mesh rather than joining an existing one. However, it does not explicitly state alternatives or exclusions, such as 'use agent_mesh_join if you already have an invitation.' The guidance is clear context but lacks direct comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states the action and target. It does not mention potential side effects, delivery guarantees, prerequisites beyond getting the handle, or behavior on failure. This is a minimal disclosure for a send operation with network implications.
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, clearly worded sentence that front-loads the primary verb and object. It includes a useful cross-reference without unnecessary verbiage. Every word 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 tool with no parameters and no output schema, the description covers the essential aspects: what it does, to whom, and where to find the handle. It does not elaborate on the nature of 'coordination messages' or outcomes, but given the tool's simplicity, the description is adequately 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, and the description appropriately avoids parameter details. The pointer to agents_list for obtaining the handle is useful context. Baseline for 0 params is 4, and nothing reduces this.
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 ('Sends a coordination message') and the target ('to an agent on ANOTHER of the user's machines'). It also differentiates from siblings by specifying cross-machine communication and references agents_list for obtaining the handle.
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 clear context on when to use the tool (sending a coordination message to another machine's agent) and a key prerequisite (get the handle from agents_list). However, it does not explicitly state when not to use it or name alternative tools, so it falls short of a full 5.
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 burden of disclosure. It states the read-only nature ('Shows') and provides context about the data returned (delivery and acknowledgment info). However, it does not disclose potential limitations such as message recency, filtering, or scope beyond 'this machine.'
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 front-loads the verb and resource, followed by clarifying details. No filler or 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?
Given the tool's low complexity (no parameters, no output schema), the description adequately covers what the tool returns: sent messages with delivery and acknowledgment info. It could possibly mention the messaging context (e.g., agent mesh), but the name and sibling tools make this evident.
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 description correctly implies that no input is needed. By default, a zero-parameter tool earns a baseline of 4, and there is 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?
The description uses the verb 'Shows' to specify a read operation, and clearly identifies the resource as 'what THIS machine sent,' with additional detail on delivery and acknowledgment status. This distinguishes it from sibling tools like agent_inbox (received) and agent_send (send).
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 a use case (checking sent messages and their delivery/ack status) but does not explicitly state when to use this tool instead of alternatives like agent_inbox or agent_ack. No exclusions or alternative tool names are given.
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 carries full burden. It states the tool 'permanently deletes', signaling destructive behavior, but lacks details on permissions, error handling, or return values.
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 is front-loaded with the key action 'Permanently deletes'. Every word adds value, and there is no redundancy or wasted space.
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 deletion tool with no parameters and no output schema, the description covers the essential behavior (permanent deletion by ID). It lacks mention of what happens if the ID is invalid, but overall is adequate.
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, so schema coverage is 100% trivial. According to guidelines, 0 parameters earns a baseline of 4; 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 uses specific verb 'deletes' and resource 'reminder in Apple Reminders (Reminders.app) by ID', clearly stating the tool's action and scope. It distinguishes from sibling tools like 'complete_reminder' (mark complete) and 'update_reminder' (modify).
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 for deleting reminders but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives like 'complete_reminder' for non-destructive actions.
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 and states a non-destructive read operation with a specific scope (local, plain text, absolute path). It does not cover error handling, encoding, or size limits, but for a simple read operation, this is a minimal but adequate disclosure.
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, front-loaded sentence that immediately states the action and target resource. It is efficient, though slightly truncated, but the visible content has no filler.
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?
The description conveys the essential purpose and identifies the target file type and location, which is sufficient for selecting the tool among siblings. However, it does not explicitly state the return value, and the absolute path requirement is not reflected in the schema, leaving invocation details incomplete.
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 has no parameters, yet the description specifies an absolute path requirement, which is essential information for invocation. This adds meaning beyond the empty schema, though it highlights a mismatch between the description and schema that the agent must resolve.
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 ('Reads'), resource ('plain text file'), and scope ('local filesystem by its absolute path'), and explicitly labels it as the 'primary, default tool' for reading, which differentiates it from siblings like pdf_read or word_read. Even though truncated, the core purpose is unmistakable.
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 phrase 'primary, default tool for read...' gives clear guidance that this tool should be the first choice for file reading. It does not explicitly mention when not to use it or name alternatives, but the 'plain text' and 'local filesystem' qualifiers implicitly exclude non-text and remote file tools.
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 carries the full burden. It discloses that the tool returns metadata (size, dates, type) and mentions 'synced Google Drive,' which hints at scope. However, it does not specify authentication requirements, rate limits, or whether the operation is read-only. This is adequate for a simple metadata fetch but not comprehensive.
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?
A single sentence of 12 words, front-loaded with the key purpose ('Metadata for a file/folder'). No wasted words; every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief but critically omits how the tool identifies which file or folder to retrieve metadata for. With zero parameters and no explanation of implicit context (e.g., a currently selected file), an agent cannot reliably invoke this tool. An output schema is absent, but the return values are partially listed. Significant completeness 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 input schema has zero parameters, so schema description coverage is effectively 100%. The description adds no parameter information, but since there are no parameters, a baseline of 4 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 uses a specific noun and verb: 'Metadata for a file/folder' clearly indicates it retrieves metadata. It distinguishes from sibling tools like gdrive_read_file (which reads content) and gdrive_list_files (which lists files) by focusing on size, dates, and type.
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 implicitly states it's for metadata retrieval, but lacks explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, but the context is clear enough for an agent to infer basic usage.
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 discloses that the API key is masked, which is a helpful behavioral trait. However, it does not explicitly state that the operation is read-only or has no side effects, though 'returns' implies it. 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?
The description is a single, well-structured sentence with no unnecessary words. It front-loads the main action and includes a key detail about masking.
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 zero parameters, the description provides essential context: what is returned and that the API key is masked. It does not enumerate all fields of the configuration, but for a simple config retrieval, this is reasonable.
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 the schema is fully covered. The description adds value by describing the return content (configuration with masked API key), which is a meaningful semantic 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 states exactly what the tool does: 'Returns the current LMCP configuration (api_key masked).' The verb 'Returns' and resource 'LMCP configuration' are specific, and the masking note adds clarity. Among siblings like lmcp_state and lmcp_welcome, this tool is distinct.
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?
No explicit guidance on when to use or alternatives. Since it's a simple getter with no parameters, the usage is implicit. However, it lacks explicit context such as 'Use this to inspect the current LMCP configuration before changing settings.'
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. The word 'Lists' indicates a read-only operation, and 'on this Mac' clarifies that it operates on the local system. However, it does not explicitly state that there are no side effects, whether special permissions are needed, or how it behaves if Reminders.app is not available. Some context is given but not comprehensive.
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 that states exactly what the tool does. It includes necessary clarifying details ('lists (folders)', 'Apple Reminders (Reminders.app)', 'on this Mac') without any wasted words or 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 parameterless listing tool with no output schema, the description provides sufficient context: it identifies the exact data source and the nature of the result. It doesn't explicitly state the return format (e.g., an array of folder names), but the verb 'Lists' and the tool name make that obvious. Minor gap is that it doesn't mention edge cases like empty results or accessibility, but it's generally 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?
The tool has zero parameters, so there is nothing for the description to add. According to the rubric, a baseline of 4 is appropriate for 0 parameters. The description correctly implies that no input is required, and the schema coverage is 100% (vacuously, since there are no properties).
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 the specific verb 'Lists' and clearly identifies the resource as 'lists (folders) in Apple Reminders (Reminders.app) on this Mac'. It differentiates from sibling tools like list_reminders (which lists individual reminders) and create_reminder_list (which creates folders), 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?
No explicit when-to-use or alternative tools are mentioned. However, the description's scope ('folders in Apple Reminders') clearly implies that this tool should be used when the agent needs to retrieve folder names, rather than actual reminders. It lacks explicit exclusions or references to alternatives like list_reminders, but the intended use case is reasonably inferable.
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 carries the burden. It discloses the output fields (chat id, name, service) and the read-only nature of 'Lists', but it does not mention potential limitations like how 'recent' is defined or whether permissions are required. The description adds some transparency beyond the tool name.
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 concise sentence that immediately states the action and scope, with the output fields in parentheses. No redundant words or filler.
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 has zero parameters and no output schema, the description adequately covers its purpose and return values. It lists the key fields, and while it could mention 'recent' interpretation, the simplicity of the tool makes this sufficient.
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 no parameters, and the schema is empty, so the baseline is 4 per the rubric. There is no parameter information needed, and the description does not need to compensate for any missing details.
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 recent iMessage/Messages.app conversations and specifies the output fields (chat id, name, service). This distinctly identifies it from sibling tools for other messaging platforms like whatsapp_list_chats or signal_list_chats.
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 use for accessing iMessage conversations but does not explicitly mention when to use it over alternatives like WhatsApp or Signal chat lists. There are no direct exclusions or guidance, but the iMessage-specific phrasing provides clear context.
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 states 'Returns' implying read-only behavior, but does not disclose any side effects, data sources, or whether it modifies state. It is minimally transparent but adequate given simplicity.
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?
A single sentence that efficiently communicates the tool's purpose and output. Every word adds value, with no redundancy or unnecessary detail.
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 no parameters and no output schema, the description adequately covers what it does and why. It could optionally mention output format, but is sufficient for an agent to understand its use.
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 no properties, so schema description coverage is 100% and no parameters need explanation. Baseline for zero parameters is 4, and the description adds no param info, which is acceptable.
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 'returns', the resource 'emailable contacts plus an invite template', and the context 'for recommending LMCP to a colleague'. This distinctly separates it from siblings like 'create_referral_invites'.
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 wanting to refer a colleague to LMCP, but does not explicitly state when not to use it or contrast with sibling 'create_referral_invites'. The context is 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It adds a safety clarification ('not editing your data') but does not disclose whether the tool performs network calls, reads local state, or has side effects. The mention of 'current version' hints at output but lacks depth.
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 sentence and front-loads the key verb and resource. However, the trailing '...' suggests it may be truncated or incomplete, which slightly detracts from structure.
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 no-param, no-output-schema tool, the description should fully explain what health information is returned. It mentions 'current version' but leaves the rest ambiguous with '...', which is insufficient for an agent to know 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?
The tool takes zero parameters, and schema coverage is trivially 100%. Per guidelines, the baseline for 0 params is 4, and the description adds useful context about what the tool reports, even if it doesn't elaborate on parameters (which don't 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 tool returns LMCP's self-upgrade health, with a specific verb ('Returns') and resource. It also distinguishes this from editing data, which differentiates it from sibling tools like lmcp_install_upgrade and lmcp_state.
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 context that this tool is about the app upgrading itself, not user data, which implies when to use it. However, it does not explicitly mention alternatives (e.g., lmcp_install_upgrade for performing upgrades) or exclusions.
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 description carries burden. It explicitly states it is a read-only operation ('shows'), with no mention of side effects. However, it lacks details on whether data is real-time or cached, and what exactly constitutes 'results'.
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?
Short single sentence that conveys purpose efficiently, though truncated. No extra fluff, but could be completed for clarity.
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?
With no output schema or parameters, description should hint at output structure (e.g., fields returned). It says 'and their results' but doesn't specify what that includes (success, timestamps, output data). Also no mention of sorting or limits. Incomplete for a data retrieval 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?
Tool has no parameters and schema coverage is 100% trivially. Description does not need to add parameter info, but it also doesn't confirm that no input is needed. Still, no missing 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 tool shows history of recipe runs and their results, distinguishing it from other recipe tools like recipe_run (executes) and recipe_list (lists recipes). Verb 'shows' plus resource 'history of past recipe runs' is specific and informative.
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?
Description implies usage for reviewing past runs to reuse or compare, but it does not explicitly state when to use this tool instead of sibling tools like recipe_list or recipe_get. No prerequisites or context provided.
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 carries full burden. It discloses the finalization of .mov and writing of JSON, but does not mention side effects like file overwriting, required permissions, or whether the recording must be active. The description is 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?
The description is a single sentence, front-loaded with the primary action, and contains no extraneous information. Every part is essential.
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 parameters, no output schema, and no annotations, the description is largely sufficient. It covers the main purpose and outputs, but could be improved by explicitly stating the prerequisite (an active recording must exist) for complete context.
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 schema coverage is 100%. The description doesn't need to add parameter details, but it effectively explains the tool's action and outputs, adding value beyond the empty 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 'stops' and the resource 'active recording', and specifies the outputs: '.mov' and 'marker timeline JSON'. It distinguishes itself from siblings like screen_record_start and screen_record_status.
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 use after a recording has started by mentioning 'active recording', but does not explicitly state when to use or not use this tool, nor does it reference alternatives like screen_record_start or screen_record_status.
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 must carry the full burden of behavioral disclosure. It does reveal that the skip is 'for now', implying a temporary dismissal rather than a permanent opt-out. However, it does not explain side effects, such as whether the survey will reappear, or if any state is stored. For such a simple action, this level of transparency is adequate but not comprehensive, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it appears truncated—ending with 'doesn't want...'—leaving the thought incomplete. While brevity is a plus, the structural incompleteness suggests a lack of polish, preventing a higher score. It is not as concise as a fully formed, complete sentence would be.
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 trivial complexity (no parameters, no output schema), the description provides sufficient context: it states the action, the target, and the motivating scenario. It doesn't need to explain return values or complex behaviors. The only minor gap is the absence of details on what happens after skipping, but for a simple 'skip', the description is complete enough.
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, so the baseline for this dimension is 4. The description correctly omits parameter details since there are none. It does not need to compensate for any schema gaps because the schema fully defines the empty parameter set. Thus, the score aligns with the 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's function: 'Skips the short in-product survey Local MCP showed the user'. This is a specific verb (skip) applied to a distinct resource (the survey), and it inherently differentiates from the sibling tool 'survey_respond' by indicating a non-response action. The 'for now' qualifier adds temporary intent, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage trigger: 'use this when the user doesn't want...' This tells the agent exactly when to invoke the tool. However, it does not explicitly mention alternatives or when not to use it, though the sibling 'survey_respond' is implied as the contrasting choice. The guidance is clear but not exhaustive, so it earns a 4.
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 clearly indicates a read-only action ('Lists') and defines the scope ('all the Microsoft Teams the user belongs to'). However, it does not disclose prerequisites like needing an authenticated Teams connection, nor does it mention potential pagination or output format.
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 that directly states the tool's purpose with no redundant words. It is maximally concise while remaining clear.
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 (0 parameters, no output schema), the description adequately explains its purpose. It could slightly improve by stating the return type explicitly, but 'Lists all the Microsoft Teams' already implies a list of team entities, making it 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?
There are zero parameters, so the baseline is 4. The description adds no parameter details because none exist, and the empty schema fully covers this aspect.
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 ('Lists') and a clear resource ('all the Microsoft Teams the user belongs to'). It clearly distinguishes from sibling tools like teams_list_channels and teams_list_chats, which list different entities.
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 when to use this tool (when you need to list Teams the user belongs to) but provides no explicit exclusions or comparison with alternatives. Sibling tool names suggest different scopes, but the description itself does not explain when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 of behavioral disclosure. It does reveal that only active (incomplete) tasks are returned, which is a useful behavioral trait. However, it does not mention that the operation is read-only, whether authentication is required, or whether it lists tasks across all projects or a specific scope.
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, front-loaded with the verb 'List' and the object, with no filler or repetition. Every word contributes to the meaning, making it highly concise 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?
Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is largely sufficient. It clearly states the purpose and the key filter (incomplete tasks). However, the absence of an output schema means the return structure is not explicitly described, and prerequisites like Todoist connectivity are not mentioned, which slightly reduces completeness.
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, so schema coverage is trivially 100%. The description need not explain any parameters, and the baseline for 0 parameters is 4. The description adds no parameter-specific information, but none 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?
The description clearly states the tool's function with a specific verb ('List') and resource ('active (incomplete) Todoist tasks'), distinguishing it from sibling tools like todoist_list_projects (lists projects) and todoist_complete_task (completes tasks). The inclusion of 'Todoist' indicates the service, and the filter for incomplete tasks adds precision.
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 (use when you need to list active Todoist tasks) but does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. No guidance is given for choosing between this and similar tools like todo_list_tasks.
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?
The description explains that the tool re-resolves element bounds/state, but does not disclose potential failure modes (e.g., element no longer exists), or whether it issues a new UI query. With no annotations, more detail would be beneficial.
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 conveys the core purpose without any extraneous information. It is appropriately concise and 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 tool with no parameters and a straightforward purpose, the description provides sufficient context. No output schema exists, but the return value is implied by the description (updated element_ref). It is adequate.
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 description does not need to add parameter meanings. It is clear and sufficient for the no-parameter case.
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 re-resolves a previously returned element_ref to update its bounds/state. This distinguishes it from siblings like ui_find_element (which finds new elements) and ui_click (which interacts with elements).
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 an element may have changed state, but it does not explicitly state when to use this tool versus alternatives like ui_find_element, nor does it mention prerequisites or conditions.
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 burden. It discloses the optional nested menu following, but does not describe behavior on failure (e.g., item not found), error handling, or side effects like menu opening.
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 clear sentence with no unnecessary words. It is front-loaded with the core action and includes the optional behavior efficiently.
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 parameters, the description covers the main action and optional path following. It could mention that the click typically opens a menu or that the status-bar item must be visible, but overall it is sufficient for a simple action.
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 no parameters, so schema coverage is 100%. The description does not need to add parameter information, and it correctly omits parameter details. The optional menu path is a behavioral aspect, not a parameter.
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 ('Clicks'), the target ('status-bar item'), and the optional behavior ('follows a nested menu path'). It distinguishes the tool from other click tools like ui_click or safari_click.
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 using this tool for status-bar items but provides no explicit guidance on when to use it versus alternatives like ui_click for regular UI elements. No exclusion criteria or context is given.
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 present, so the description carries the full burden of behavioral disclosure. It transparently lists consequences: closing the open window and erasing cookies and site data, which clearly conveys that this is a destructive operation. It could explicitly say 'irreversible', but 'deletes' and 'erases' are already strong signals.
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?
A single sentence with the action front-loaded and the side effects listed compactly after a colon. Every word contributes meaning, and there is no filler or repetition.
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 zero-parameter, destructive tool with no output schema, the description covers the core action and its immediate effects well. The only slight gap is that it does not specify which profile is deleted when multiple saved profiles exist, but the absence of parameters implies a context-determined or singleton target.
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, so there is no parameter documentation burden on the description. The schema is trivially 100% covered, and the baseline for zero-parameter tools is appropriately high.
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 ('Deletes') and a specific resource ('SAVED web-automation login profile'). It also enumerates concrete effects, which makes it clearly distinct from siblings like web_session_close that only close an active session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance about when to choose this tool over related alternatives such as web_session_close or web_login, and it does not mention any prerequisites or exclusions. The destructive use case is implied but never framed as a choice point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 of behavioral disclosure. It states 'logs out the linked device' but does not detail side effects, reversibility, or state changes after disconnection, leaving the agent underinformed about the tool's impact.
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, well-structured sentence that front-loads the action and context. Every word is meaningful, and there is no redundant or 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?
For a simple action with no parameters, annotations, or output schema, the description is relatively complete. It tells the agent what the tool does and how, but could benefit from noting expected outcomes (e.g., connection state). Still adequate given simplicity.
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, and the input schema fully describes this (100% coverage). The description adds no parameter information, but this is acceptable given the absence of parameters. Baseline for 0 params is 4.
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 (unlink/logout), the resource (WhatsApp from Local MCP, linked device on this Mac), and the mechanism (via wacli). It effectively distinguishes from the sibling tool 'whatsapp_connect'.
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 context that this tool is for disconnecting WhatsApp from Local MCP, implying use after a connection is established. However, it does not explicitly state when to use or not use this tool, nor mention alternatives beyond the implicit 'whatsapp_connect'.
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 discloses the read-only nature by saying 'shows whether', which implies a safe status query. However, it doesn't describe output format (e.g., boolean vs. object) or any network dependencies. The definition of agent mesh is partially helpful but truncated, leaving some behavioral context missing.
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 and extremely concise. It front-loads the key action and includes a helpful definition of agent mesh. No wasted words, and the structure is appropriate for a simple status tool.
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 zero-parameter status tool with no output schema, the description mostly suffices, but it is truncated mid-sentence ('whose AI agents...'), which leaves the definition incomplete. It also doesn't state what the return value looks like. Given the full description isn't provided, the tool isn't fully self-contained.
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, so the baseline is 4. The description adds context by specifying 'THIS machine', clarifying that the status check is scoped to the local machine rather than any other machine. This is useful semantic context beyond the empty 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: it shows whether the current machine belongs to an agent mesh. This distinguishes it from sibling tools like agent_mesh_create, agent_mesh_join, and agent_mesh_revoke, which modify membership rather than check status. The specific verb 'shows whether' plus the resource 'agent mesh' leaves no 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 usage: use this tool to check if the current machine is part of an agent mesh. It doesn't explicitly state when not to use it or mention alternatives, but the context is clear enough given the sibling tools (e.g., you wouldn't use agent_mesh_create just to check status). No exclusions are stated, but the intended use is obvious.
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 bears the full burden. It discloses that credentials are removed, which is a destructive side effect, but does not detail prerequisites (e.g., must be connected), post-conditions, or idempotency. Adequate but could add more context.
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 conveys the essential information with no extraneous words. It is front-loaded and efficient.
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?
The tool is simple with no inputs or outputs, so the description is minimally complete. However, it could improve by mentioning related side effects like session invalidation or that re-authentication will be required.
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 coverage is 100% (empty). The description adds no parameter details, but none are needed. Baseline for 0 params is 4.
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 ('Disconnect from ServiceNow') and the side effect ('remove stored credentials'), making it unequivocal what the tool does. This distinguishes it from siblings like connect_servicenow.
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 when the user wants to sever the ServiceNow connection and clear credentials. It does not explicitly state when not to use or provide alternatives, but the purpose is self-explanatory given the tool's simplicity.
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 is the sole source. It lists fields but does not disclose behavioral traits such as whether it requires accessibility permissions, if it is read-only (implied but not stated), or performance characteristics. Minimal 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?
Single sentence, front-loaded with the main purpose, no redundant information. Every word 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?
For a parameterless list tool with no output schema, the description adequately covers what the tool does and what it returns. No missing critical information.
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, so schema coverage is 100% vacuously. The description adds value by enumerating the return fields, which the schema does not provide. This goes beyond the baseline of 3 for high 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 it lists on-screen windows of any app and names the specific fields returned (window_id, bundle id, name, title, bounds). This distinguishes it from sibling tools like list_displays which lists monitors.
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 use when window information is needed but gives no explicit guidance on when to use this tool vs alternatives like list_displays or when not to use it. Lacks context on prerequisites or limitations.
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 disclosure burden. It openly identifies the data source as a local cache, which implies a read-only, local operation and possible staleness. It does not detail freshness or authentication expectations, but for a parameterless list tool this 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?
The description is a single front-loaded sentence with a clear verb and object. It contains no filler, redundant qualifiers, or schema repetition, and every word earns its place.
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 simple no-parameter list tool, the description is mostly sufficient, but there is no output schema to compensate for the lack of return-value detail. It does not specify whether the result includes workspace names, IDs, or both, and the 'cached' behavior is only briefly implied. Still, the intended action is understandable.
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 the empty schema already captures everything structurally. The description adds useful context by explaining that the operation draws from cached data on this Mac, which helps an agent understand why no workspace argument 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?
The description clearly identifies the operation ('Lists') and the resource ('Notion workspaces'), and the qualifier 'cached on this Mac' distinguishes this from related tools like notion_list_databases and notion_list_pages. An agent can understand exactly what this tool does without opening the schema.
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 when the tool should be used—when a list of cached Notion workspaces is needed—but it does not explicitly state when to prefer it over sibling tools or mention alternatives. There are no exclusions or routing cues beyond the workspace-specific wording, so the agent must infer the usage context.
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 discloses that logins are persisted on disk and that the operation is a list (read-only), but does not explain return format, side effects, or whether profiles can be expired/invalid. The truncated clause may have added more, but based on visible text this is minimal.
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 and efficient, beginning with the purpose. However, the text appears truncated mid-sentence, so the structure is incomplete and a full sentence is not 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?
For a zero-parameter list tool with no output schema, the description is largely complete: it states what is listed and that entries are saved on disk. The truncated mention of web_login/web_navigate slightly reduces completeness, and return details are not specified, but the tool is simple enough.
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 is empty with zero parameters, so the baseline of 4 applies. There are no parameter semantics to document, and the description doesn't need to compensate for schema gaps.
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 'Lists your web-automation login profiles' and scopes to 'every SAVED login (persisted on disk)', clearly distinguishing this from sibling actions like web_login or web_session_close. The verb 'Lists' plus the specific resource makes 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description references web_login/web_navigate as consumers of saved logins, implying when to use the list. However, it does not explicitly state exclusions or alternative tools, so it provides clear context but not full when-not-to-use guidance.
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 discloses a prerequisite (check in first) and a time window (since last poll), but does not specify side effects such as whether messages are marked as read, whether polling state is reset, or if a separate acknowledgment (agent_ack) is needed. This is a notable gap for a tool that depends on polling state.
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 is front-loaded with the verb 'Reads', contains no filler, and conveys the essential information efficiently.
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 zero-parameter, read-only tool, the description is mostly complete, providing the purpose and a prerequisite. However, it omits details about what happens to the messages after reading (e.g., consumption, acknowledgment) and does not describe the output format, which may be important for a messaging 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 tool takes zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but none is needed since the schema is empty and fully covers the parameter space.
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 (Reads), the resource (messages other agents sent to this machine), and the scope (since your last poll). It effectively distinguishes from sibling tools like agent_send, agent_checkin, and agent_ack, which handle different aspects of agent messaging.
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 instructs to check in first with agent_checkin and clarifies that messages are those received since the last poll. This gives clear context for when to use the tool, though it does not mention exclusions or alternative tools by name.
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 discloses caching and no Mail lock, giving good insight into performance and side effects. Could mention return format or data freshness.
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 sentence with key details front-loaded (purpose, speed, caching, lock behavior). No 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 simple zero-parameter tool with no output schema, description adequately covers behavior. Lacks mention of return structure, but not critical.
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, so schema coverage is 100%. Description adds no parameter info, but baseline is 4 for zero 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?
Description clearly states it lists Mail.app account names, specifies it's fast, cached, and no Mail lock. Differentiates from sibling list_accounts by targeting Mail.app specifically.
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?
Describes performance characteristics (fast, cached) implying safe frequent use, but does not explicitly state when to use vs alternatives like list_accounts or 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions 'including nested subfolders' but does not disclose non-destructive nature or potential limitations beyond the tool's function.
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 sentence, front-loaded with the action, no unnecessary 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?
Given zero parameters and no output schema, the description is complete enough for an agent to understand the tool's purpose, though return format is not specified.
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; description adds value by specifying the tool is for Apple Mail accounts, which is not evident from the empty 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 lists the full folder tree for Apple Mail accounts, distinguishing it from siblings like create_email_folder or list_email_accounts.
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 specifies it's for Apple Mail accounts, clarifying its scope, but does not explicitly mention when not to use it or compare with other related 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?
With no annotations, the description carries the full burden. It correctly indicates a read-only operation without side effects. No contradictions. Could mention that it returns an array of tag objects, but current text is fine.
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, clear sentence with no wasted words. Perfectly concise.
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 zero-parameter list-all tool, the description is complete enough. No output schema exists, but the return value (list of tags) is implied. Slightly room for improvement by mentioning the format.
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, and schema coverage is 100%. Description adds no semantics, but none are needed. Baseline of 4 for zero-parameter tools 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 (lists) and resource (all tags defined in OmniFocus). It distinguishes from sibling tools like list_omnifocus_projects and list_omnifocus_folders.
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?
No explicit guidance on when to use this tool vs alternatives. For a simple list-all tool with no parameters, this is minimally adequate but lacks suggestions about prerequisites or 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?
The description discloses key behaviors: listing only cached pages (read-only, local), specific fields returned, and newest-first sorting. With no annotations, it sufficiently covers what the tool does, though it omits details like auth or if empty results occur.
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?
A single sentence that front-loads the verb and resource, includes key details, and has no redundant information. Every word 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 simple list tool with no parameters and no output schema, the description is complete enough. It could briefly mention the output structure, but it's not essential.
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 the baseline is 4. The description adds no parameter information, which is fine as there are none to describe.
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 Notion pages, specifies the fields (titles, last edited, hierarchy), and sorting (newest first). It distinguishes itself from sibling tools like notion_search and notion_read_page by highlighting local caching.
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?
Usage is implied by describing the tool's purpose (listing cached pages), but there is no explicit guidance on when to use this versus alternatives like notion_search or notion_list_databases.
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. The description only states that it lists incidents but does not disclose any behavioral details such as sorting order, pagination, or whether closed incidents are included. This is adequate for a simple tool but lacks depth.
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 clear sentence with no redundant words. It efficiently conveys the tool's purpose without unnecessary elaboration.
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 that there is no output schema and no parameters, the description is mostly complete. It could mention if the list includes both open and closed incidents or provide ordering hints, but for a basic personal list, it is adequate.
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 no parameters, and the schema coverage is 100% (trivially). Since there are no parameters to describe, the description does not need to add parameter semantics. Following the guidelines, the baseline is 4.
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 action (list) and resource (incidents) with a clear scope (assigned to or opened by you). It effectively distinguishes from siblings like servicenow_search_incidents which likely perform broader searches.
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 implicitly indicates when to use it (for personal incidents) vs. siblings (e.g., servicenow_search_incidents for broader search). However, it does not explicitly state when not to use it or mention alternatives.
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 carries full burden. It states it 'finds elements' but does not detail what information is returned (e.g., CSS selectors, text, coordinates) or any side effects (e.g., highlighting). Minimal 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?
Single sentence that is concise, front-loaded, and every word adds value. No wasted text.
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 no parameters and no output schema, the description is reasonably complete. It explains the tool's purpose and typical workflow placement. However, it could benefit from describing the return type or format.
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 baseline is 4. The description does not need to add parameter info. It hints at output usage but lacks details on return format, which is acceptable given 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 finds elements on the current web page, using a specific verb ('find') and resource ('elements on the current page'). It distinguishes itself from siblings like web_click or web_type by indicating it is a precursor step.
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 before clicking or typing ('so you can decide what to click or type into'), providing context. However, it does not explicitly mention when not to use it or list alternatives among sibling tools.
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 full burden. It indicates the tool reports state and next steps, implying read-only behavior, but it does not explicitly state whether any changes are made, what permissions are needed, or what potential side effects exist. This is acceptable for a diagnostic tool but leaves room for more detail.
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?
A single sentence that is front-loaded with the action and resource, immediately followed by the use case. No unnecessary words or repetition. Highly concise 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?
For a simple diagnostic tool with no parameters and no output schema, the description provides sufficient context: purpose and when to use it. It could elaborate on what 'link state' means or the format of the report, but the current text covers the essentials adequately.
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 coverage is 100% (vacuously). The description doesn't need to explain parameters, so the baseline of 4 applies. It avoids adding irrelevant parameter details.
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 a specific action ('Reports') on a specific resource ('Zalo's link state') and adds the purpose of guiding next steps if Zalo tools fail. This distinguishes it from sibling tools like zalo_connect and zalo_send_message, which have different functions.
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 phrase 'if Zalo tools aren't working' provides a clear condition for when to use this diagnostic tool. While it doesn't explicitly name alternatives, the context implies it is for troubleshooting Zalo connectivity, setting it apart from other diagnose tools (e.g., whatsapp_diagnose) or connection 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the action (announcing yourself) and its target (the mesh), including the specific data shared. It does not mention reversibility or side effects, but for a simple check-in, the core behavior is well 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 a single, well-structured sentence that front-loads the purpose ('Announces YOU') and provides necessary detail without any filler. Every word 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?
For a tool with no parameters and no output schema, the description is complete. It explains the tool's purpose, the target (mesh), and the content of the announcement. The simple nature of the tool means nothing else is required.
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 baseline is 4. The description adds context about what the announcement includes (role, repo, capabilities), which is sufficient. No parameter-specific details 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 clearly states the tool's function with a specific verb ('Announces') and resource ('to the mesh'), and enumerates the content of the announcement (your role, repo, capabilities). This clearly distinguishes it from sibling tools like agent_ack or agent_send.
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 when to use the tool (when you need to announce your agent session to the mesh), but it does not explicitly state when to use it vs alternatives or mention any exclusions. No conflicting alternative is mentioned, so usage is inferred 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 provided, the description carries full responsibility for disclosing side effects. It explicitly warns that the operation deletes the list plus all contained reminders and that it 'cannot be undone,' which is essential for a destructive action. It lacks permission/authentication context, but the irreversibility caveat 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single well-structured sentence that front-loads the action and consequence. Every word contributes; 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 zero-parameter destructive operation with no output schema, the description is essentially complete: it identifies the target, the cascading effect, and irreversibility. It does not describe the return value, but for a delete operation with no parameterization this is a minor gap given other contextual richness.
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 schema fully covers all inputs (an empty object). There are no parameters to explain; the description's emphasis on the list-and-contents scope is more relevant than parameter semantics. Baseline of 4 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 identifies the destructive action ('Deletes'), the target resource ('Apple Reminders list'), and the cascading scope ('and all reminders inside it'). Distinguishes itself from sibling 'delete_reminder' which targets a single reminder, and 'rename_reminder_folder' which mutates rather than deletes.
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?
Description does not explicitly state when to choose this over alternatives such as 'delete_reminder' or 'complete_reminder'. The scoping phrase implies it is for whole-list deletion, but no explicit guidance or exclusion criteria are provided.
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 tool removes the stored API token, which is a destructive action, and states the disconnect behavior. It could add context about irreversibility or prerequisites but covers the core effect.
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 clear sentence, front-loaded with the action and resource. Every word contributes meaning, 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 zero-parameter disconnect operation with no output schema, the description is sufficiently complete. It explains what happens (disconnect) and the side effect (token removal), covering the essential context an agent needs.
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, so the description is not required to explain parameter meaning. The baseline of 4 applies, and the description adds no unnecessary parameter details.
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: 'Disconnect Todoist and remove the stored API token.' It uses specific verbs (disconnect, remove) and identifies both the target service and the concrete effect, distinguishing it from connect_todoist and other disconnect tools.
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?
Usage context is implied by the name and description but not explicitly stated. It does not mention when to use this tool versus alternatives like connect_todoist or how to re-establish the connection. The guidance is minimal but sufficient for a straightforward disconnect operation.
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 must carry full transparency burden. It correctly discloses read-only nature and local source (cache). Missing potential caveats like staleness or missing cache, but adequate for a simple read.
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 sentence front-loads the action and key constraints (local cache, no API). Every word earns its place; no redundancy.
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?
Given no output schema and no annotations, description only states source and action. Missing return format, potential errors, or caveats. Adequate but could add details like 'returns list of call/meeting records with timestamps and participants' to fully inform the 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?
No parameters in schema (0 params), so description needs no parameter details. Per guidelines, baseline for 0 parameters is 4. Schema covers 100% (trivially).
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 it reads Microsoft Teams call & meeting history from the Mac's local Teams cache, avoiding Graph API. This specific verb and resource distinguish it from sibling tools like teams_list_chats or teams_send_message that use the cloud API.
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?
Description implies use for local cache data without tokens, contrasting with cloud-based sibling tools (e.g., teams_list_channels). However, it does not explicitly state when to avoid or provide alternatives, so a slight deduction.
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 carries the full burden. 'Lists' indicates a read-only operation, which is a useful behavioral trait. However, it does not disclose any prerequisites (e.g., needing a connected Microsoft account) or return format details. For a simple listing tool this is acceptable but not rich.
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, focused sentence with no redundant words. It is front-loaded and appropriately sized for the tool's simplicity.
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 (no parameters, no output schema, straightforward listing operation), the description is complete. An agent can accurately infer what the tool returns and when to invoke it based on the name and description alone.
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, so schema coverage is trivially 100%. The description does not need to explain parameters. This matches the baseline of 4 for parameterless tools.
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 ('Lists') and the specific resource ('Microsoft To Do task lists'). This distinguishes it from sibling tools like 'todo_list_tasks' (which lists tasks, not task lists) and similar tools for other systems (e.g., 'get_reminder_folders'). The purpose is unambiguous.
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 usage context: when an agent needs to retrieve all Microsoft To Do task lists. However, it does not explicitly mention alternatives or when not to use it (e.g., for tasks specifically). Since the context is clear but exclusions are absent, it earns a 4.
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 of behavior disclosure. It states the output includes id and name, but does not mention prerequisites (such as a connected Todoist account), whether archived projects are included, or any side effects. For a simple read-only list, this is adequate but minimal.
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 wasted words. It immediately states the action, resource, and output format.
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 zero-parameter, no-output-schema tool, the description is complete. It specifies the resource (projects), the scope (your Todoist), and the returned data (id + name). No additional context is necessary 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per the rubric the baseline is 4. The description does not need to explain parameter semantics, and the empty input schema is unambiguous.
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 ('List') and resource ('Todoist projects'), and explicitly states the return fields (id + name). It clearly differentiates from siblings like todoist_list_tasks and connects to the Todoist domain.
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 clearly implies when to use this tool (when you need an overview of Todoist projects), but does not explicitly mention alternatives or exclusions. Sibling tools like todoist_list_tasks and connect_todoist exist, but no direct comparison is made.
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 discloses the key behavioral trait: it removes the saved session locally. No annotations are provided, so the description carries full burden. It does not mention whether server-side disconnection occurs, but the local effect is explicitly stated.
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, concise sentence that efficiently conveys the tool's purpose with 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?
Given the tool's simplicity (no parameters, no output schema, low complexity), the description is complete. It sufficiently explains what the tool does and the outcome.
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 no properties, so there are no parameters to describe. The description adds no parameter information, which is acceptable as schema coverage is 100% and no parameters 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 action ('Unlink Zalo from Local MCP') and the effect ('removes the saved session on this Mac'). It distinguishes from sibling tools like 'zalo_connect' by implying the opposite action.
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?
No explicit guidance on when to use this tool versus alternatives, but the purpose is straightforward. The description implies it is used when disconnecting Zalo from the local system, but lacks details on prerequisites or side effects.
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 fully describes the behavior: it retrieves connection status and related details. No contradictory 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?
Single sentence that is efficient and front-loaded with the key action. 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?
Description lists the returned fields adequately for a status check tool. No output schema, but the description compensates. Could optionally mention that it requires network access, but not critical.
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, so baseline score of 4 applies. Schema coverage is 100%, no additional info 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?
Description clearly states the tool checks NordVPN connection status, listing specific fields. Distinguishes from sibling tools like nordvpn_diagnose and nordvpn_servers.
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?
No explicit when-to-use or alternatives, but the purpose is self-evident. The description is sufficient for an agent to know when to call it (when VPN status info is needed).
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 burden. It discloses that data comes 'from the local store,' implying a cached/local snapshot rather than live data, and warns about the need to sync. This is meaningful behavioral context beyond the tool's name.
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, focused sentence with a critical usage hint. Every word earns its place, and the structure is front-loaded with the main purpose.
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 zero-parameter list tool without an output schema, the description is adequately complete. It explains what it lists and adds a sync prerequisite. It could mention the return format, but that is less critical for a list 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?
The tool has zero parameters, and the schema coverage is trivially 100%. The description adds no parameter details because none exist. Per the rubric, a 4 is the baseline for 0 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?
The description clearly states the tool 'Lists the WhatsApp groups this account is in,' which is a specific verb+resource+scope. It distinguishes from sibling tools like whatsapp_list_chats by explicitly focusing on groups rather than all chats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a clear prerequisite: 'run whatsapp_sync first if a just-crea...' This tells the user when additional setup is needed. However, it does not mention alternatives like whatsapp_group_info or explicitly state when NOT to use this tool, so it loses a point.
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 discloses that it returns the local machine's current datetime, including timezone and UTC offset. This is sufficient for a simple read-only tool; no annotation is available, but the description fills in the key behavioral trait.
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, front-loaded with the action and resource, and contains no unnecessary words. It is perfectly concise.
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 (no parameters, no output schema), the description provides all necessary context: it returns the current date and time with timezone and UTC offset. Nothing more is required.
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 zero parameters and 100% schema coverage, the description adds value by explaining the output will include timezone and UTC offset, beyond what the empty schema conveys.
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 ('Get'), the resource ('current date and time'), and specifies additional details about timezone and UTC offset. It uniquely identifies the tool among siblings with no 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?
Though no explicit when-to-use advice is given, the purpose is self-evident: whenever the current date and time with timezone info is needed. No alternative tools exist, so exclusions are unnecessary.
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?
Even without annotations, the description fully discloses that the tool queries recording status and returns specific fields (session_id, elapsed_ms, etc.), which provides adequate behavioral 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 a single sentence that front-loads the main action and lists return fields succinctly. 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, the description completely covers the return values and the tool's purpose. It is fully adequate for the agent to understand and invoke the 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?
There are no parameters, so the description does not need to add parameter semantics. The schema coverage is 100% trivial, and the description is not burdened with parameter details.
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 reports whether a recording is active and lists the returned fields. It distinguishes itself from sibling tools like screen_record_start and screen_record_stop by focusing on status checking.
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 use for checking recording status, but does not explicitly state when to use it or mention alternatives. Given the sibling context, usage 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?
The description discloses the primary behavioral trait: it shows a QR code in the chat, requiring user action to scan. No annotations are provided, so the description carries the full burden. It effectively communicates the non-destructive, user-interactive nature of the 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 a single, front-loaded sentence that efficiently communicates the tool's action and benefit. It contains no unnecessary words and 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?
Given the tool's simplicity (no parameters, no output schema), the description is nearly complete. It explains what it does and how, though it could explicitly mention that the user needs to scan the QR code with their phone. Still, it provides sufficient context for an AI 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description adds meaningful context beyond the schema by explaining that a QR code is displayed in the chat, which is the core mechanism. This fully compensates for the lack of parameters, exceeding the baseline of 4.
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: linking WhatsApp to Local MCP via a QR code shown in the chat. It uses a specific verb ('Link') and resource ('WhatsApp'), and it distinguishes itself from other WhatsApp-related sibling tools like whatsapp_disconnect, whatsapp_list_chats, etc.
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 implicitly tells when to use the tool: when you want to connect WhatsApp without using the terminal. It does not provide explicit exclusions or alternatives, but given the lack of other WhatsApp connect tools among siblings, the usage context is clear enough.
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/lanchuske/local-mcp-releases'
If you have feedback or need assistance with the MCP directory API, please join our Discord server