macOS Automation MCP Server

by matthewdcage

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes, and the descriptions help differentiate them. A few pairs like toggle_mute and set_volume, or set_dark_mode and toggle_dark_mode, have some functional overlap but remain distinguishable. Overall, an agent can reliably select the correct tool.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern in snake_case, such as get_volume, set_volume, toggle_mute, and create_calendar_event. Prefixes like get_, set_, toggle_, list_, create_, and is_ are used predictably across domains. This makes the API easy to navigate.
Tool Count2/5
With 45 tools, the server is excessively large for a single coherent MCP server. While the macOS automation scope is broad, many tools (e.g., calendar and reminder management) could be separated into focused servers. This volume overwhelms an agent's ability to efficiently select among them.
Completeness4/5
The server covers a wide range of macOS automation tasks including system controls, app management, file operations, calendar, reminders, and scripting. Minor gaps exist such as lack of file read/write operations or direct control of display brightness, but the core workflows are well-supported. Overall, the surface is fairly complete for its domain.
Average 3.6/5 across 45 of 45 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- 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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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?
With no annotations, the description carries the full burden of disclosing behavior. It fails to mention that emptying the Trash permanently deletes all items and is irreversible, which is critical safety 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and free of fluff, but it is under-specified. While a one-sentence description is appropriate for a simple no-arg tool, this sentence omits essential information about permanence and scope, making it too minimal to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's low complexity and presence of an output schema, the description is incomplete for a destructive action. It does not state that all items are removed permanently or that the operation cannot be undone, which are essential contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description does not need to explain parameter meanings, and no parameters are left undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Empty the Trash' uses a specific verb and resource, clearly indicating the action of removing all items from the Trash. It is distinguishable from sibling tools like move_to_trash, though it does not explicitly describe the permanent deletion nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as move_to_trash, nor any mention of prerequisites or warnings. It does not say 'use this to permanently delete all trashed items' or caution against selective 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?
No annotations are provided, and the description does not disclose any behavioral traits beyond the operation. It doesn't state that the action is destructive, irreversible, what happens if the task doesn't exist, or whether confirmation is required. For a deletion tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief: two lines. It is not verbose, and every sentence earns its place. However, it is minimal to the point of under-specification for a destructive operation, so I rate it 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, 1 parameter, and no annotation coverage, the description is insufficient. It does not cover error cases, side effects, or prerequisites. The output schema exists, so return values are not needed, but behavioral context is missing. Overall, the tool is minimum viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'name' parameter. The description says 'Name of the task to remove' but adds little beyond the parameter title. It doesn't specify format, validity, or how to discover valid names. Since coverage is 0%, the description should compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Remove a scheduled task.' It uses the specific verb 'remove' and identifies the resource, distinguishing it from sibling tools like create_scheduled_task and list_scheduled_tasks. However, it doesn't elaborate on what a scheduled task is or provide any scope context, so it's 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It doesn't mention that tasks can be listed with list_scheduled_tasks before removal, nor does it state any prerequisites or exclusions. The only context is the operation itself.
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 core check without mentioning return type, case sensitivity, or behavior when the app is not running. The verb 'check' implies read-only, but that is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one sentence for the purpose and one for the parameter. It is front-loaded and every word earns its place. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and an output schema exists, the description omits important context for an agent, such as matching behavior, differences from list_running_apps, and any prerequisites. The lack of usage guidance and behavioral detail makes it incomplete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the undocumented parameter. The description merely restates 'Name of the application to check,' which adds minimal value beyond the property name and title. It lacks details on format, matching semantics, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if an application is running, using a specific verb and resource. It is unambiguous and not a tautology, but it does not explicitly differentiate from sibling tools like list_running_apps or get_frontmost_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that it is for checking a specific app by name as opposed to listing all running apps, nor does it provide any context 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 are provided, so the description bears the full burden. It does not disclose the default calendar scope (all calendars vs. one), sorting order, or behavior when calendar_name is invalid. The phrase 'upcoming' implies a time filter but lacks specifics like timezone handling or recurrence expansion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one lead sentence and a clean Arg list. Every word earns its place, with no fluff or repetition. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema that likely covers return values, the description lacks essential behavioral details for a listing tool, such as whether events from all calendars are included when calendar_name is omitted, or if the default is a specific calendar. The tool's interaction with siblings (list_calendars, create_calendar_event) is not clarified, leaving a sense of incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. The Args section does add meaning: days_ahead is described as 'Number of days to look ahead' with a default, and calendar_name as 'Optional specific calendar name.' This adds value, but it omits edge cases (e.g., negative days, invalid calendar names) and does not reference list_calendars for valid names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does 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 and resource: 'List upcoming calendar events.' It is distinct from siblings like list_calendars (which lists calendars) but does not explicitly reference alternatives, so it slightly misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as list_calendars or create_calendar_event, nor any exclusions. The description merely explains what it does without 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, and the description only says 'Open a file...' without disclosing potential side effects, permissions required, or what happens if the application is not found. This is a side-effecting action but the description carries no additional 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by the args section. It is two lines and wastes no words, though the args section repeats schema titles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that opens a file, the description is minimal. It does not explain the outcome, error states, or whether a GUI app will be launched. Despite having an output schema, the description does not clarify return behavior, and without annotations, the tool's side effects remain opaque.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists both parameters with brief explanations: 'path: Path to the file' and 'app_name: Optional application name to open with.' The schema itself has no property descriptions, so the description adds basic semantic value, but it lacks details like path format or app name resolution.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Open a file with the default or specified application,' which specifies the action and resource. However, it does not explicitly differentiate from sibling tools like launch_app, though the file vs app distinction 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only states what the tool does, with no mention of when to use it or when to use a different 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 provided, the description bears the full burden of behavioral disclosure. It says 'arbitrary' but fails to mention that executing AppleScript can have side effects, modify files, control applications, or pose security risks. It also does not describe what the tool returns or how errors are handled. This is a significant gap for a tool that runs arbitrary code.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with no extraneous words. The argument list is structured clearly. However, it is perhaps too terse for a tool with such broad execution capability, but conciseness is not the issue; missing content is captured in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema being present, the description lacks essential context for safe and effective use. It does not warn about the potential consequences of running arbitrary AppleScript, nor does it mention that the tool can interact with applications and file system. It provides minimal guidance for an agent deciding when to invoke this powerful tool among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the lack of parameter documentation. The description restates 'script' as 'AppleScript code to execute', adding little beyond the schema. It does add meaningful meaning for 'timeout' by explaining 'Maximum execution time in seconds', but this is insufficient for two parameters, one of which is a code string with no syntax guidance or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute arbitrary AppleScript code' clearly identifies the tool's purpose with a specific verb and resource. It distinguishes itself from siblings like run_shell_command, which is for shell commands. The name and description together leave no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that for shell commands, run_shell_command should be used, nor does it provide any context like 'use this for automating macOS applications'. The description simply states the function without clarifying the appropriate 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.
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 action without any details about error handling, confirmation, or whether the operation is reversible. The description is essentially a restatement of the tool name and adds little 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, stating the purpose in the first line. The 'Args' section is somewhat redundant with the schema but does not add significant clutter, keeping the description concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description need not explain return values. However, it lacks usage guidance and behavioral transparency, leaving gaps in understanding when to use it and what to expect. It is minimally viable but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The only parameter 'paths' is described as 'List of paths to move to trash', which is redundant with the tool action and schema type. It adds no additional semantics such as path format, allowed types, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Move files or folders to the Trash') with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like empty_trash, though the uniqueness is evident from the name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: when you want to move files or folders to the Trash. The description provides no explicit when-to-use vs alternatives or exclusions, but the purpose is unambiguous and no sibling tool serves the same function directly.
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 says 'Show a list selection dialog' and does not mention blocking behavior, cancellation semantics, return value flow, or whether multiple selections affect interaction. This 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core statement. The Args list is well-structured and adds value without unnecessary prose. Every sentence and item earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, some details (like return format) are covered by structured data. However, the description omits critical behavioral context such as whether the dialog blocks, how selections are returned, and what happens on cancel. This makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 0%, the description's Args section adds practical meaning to each parameter (e.g., 'items: List of items to choose from', 'prompt: Optional prompt message'). This compensates for the bare schema and helps an agent understand parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show a list selection dialog' with a specific verb and resource. It distinguishes itself from sibling tools, which are system/file/task utilities, by focusing on user interaction. However, it does not explicitly mention what the tool returns, leaving some purpose 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or context. The usage is only implied by the name and the one-line description, which is insufficient for an agent deciding between this and other 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 the full burden of explaining behavior, but it only states 'List reminders' and describes parameters. It does not disclose default filtering behavior (e.g., whether completed reminders are excluded by default), sorting, or what happens when list_name is invalid. The parameter defaults are only in the schema, not in 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with 'List reminders'. The Args section is small and directly maps to the schema parameters. Every sentence earns its place, with no redundancy or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with two optional parameters and an output schema (not shown here), so the description doesn't need to explain return values. However, it lacks usage guidance and behavioral details such as default filtering, making it adequate but not fully complete for an agent to select it confidently among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides brief but meaningful explanations for both parameters: list_name as an optional specific reminder list and include_completed as a flag to include completed reminders. This adds value beyond the raw schema, though it lacks examples or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List reminders', which clearly identifies the action and resource. It does not explicitly distinguish itself from sibling tools like list_reminder_lists or get_overdue_reminders, but the resource and parameters make the purpose reasonably 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. For example, it doesn't mention using list_reminder_lists to discover available lists or get_overdue_reminders for overdue-only queries. The Args section only explains parameters, not 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 carries full responsibility for disclosing behavior. It only states the basic action and provides no insight into side effects (e.g., browser focus, network activity), error handling, or whether the call is synchronous. This is a significant gap for a tool that has external 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence plus a redundant args line), front-loading the purpose. There is no wasted text, but the redundant parameter repetition mildly detracts from efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool this simple, the description covers the core purpose and parameter. However, it lacks usage context, behavioral detail, and failure semantics. The presence of an output schema mitigates some return-value ambiguity, but overall the description is merely functionally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage from the description, so the description must compensate. It merely repeats 'URL to open' without adding format details (e.g., http/https requirement), validation rules, or examples. The description adds no value beyond the schema's 'url' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a URL') and the target ('default browser'), which is specific and distinguishes it from sibling tools like open_file or launch_app. The verb+resource combination 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to open a URL in the default browser) but provides no explicit guidance on when to choose it over alternatives, nor any exclusions. It relies on the user's inference from the tool name and description.
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 bear the full burden. It only mentions 'safety checks' without detailing what checks are performed, whether the command runs in a specific shell, or what happens on failure. It fails to disclose risks such as destructive potential or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence followed by a short parameter list. Every line earns its place, and the key purpose is front-loaded. This is an appropriate size for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool executes arbitrary shell commands, which can have broad system impact. The description is missing critical context such as what types of commands are allowed, how environment variables are handled, whether the command runs asynchronously, and the nature of 'safety checks'. Even with an output schema, the operational context is thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description must compensate. It provides brief explanations for all three parameters (command, timeout, working_dir), which adds basic meaning beyond the schema. However, it lacks additional context such as accepted formats, default shell behavior, or interaction between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Execute a shell command (with safety checks)', using a specific verb and resource. This distinguishes it from sibling tools like run_applescript, which executes AppleScript instead of shell commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating 'Execute a shell command', which naturally indicates it should be used for shell commands. However, it does not explicitly mention when not to use it or compare to alternatives like run_applescript. The safety check mention is a hint but not explicit 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 states the action but does not explicitly disclose that the clipboard is overwritten, nor does it mention return values or error cases. However, for a simple setter, the implied behavior is clear enough, so this is adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with a single sentence for the tool and a compact argument list. However, the 'Args:' section is redundant given the schema already documents the parameter, so it is not maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no annotations and an output schema that is not shown, the description is sufficient to understand the core function. It lacks details about output or side effects, but the tool's simplicity keeps the missing information minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The 'Args:' line repeats the parameter name and essentially rephrases the tool's purpose ('Text to copy to clipboard') without adding meaningful detail beyond the schema's type and title. It provides little additional semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Copy text to the clipboard' clearly states a specific verb ('Copy') and resource ('clipboard'), and it distinguishes from sibling tools like get_clipboard ('Get') and clear_clipboard ('Clear') by the verb used. This is a clear and specific 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_clipboard or clear_clipboard, nor does it mention any prerequisites or exclusions. It simply states the action with no contextual usage advice.
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 the full burden of behavioral disclosure. It does not mention whether toggling requires permissions, what happens if WiFi is already in the requested state, or any side effects like disconnecting existing networks. This 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loading the purpose and then clearly explaining the parameter. Every word earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description sufficiently covers the core action and parameter for correct invocation. However, it lacks any mention of when to use it or alternatives, which would enhance completeness for an agent navigating many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the 'enabled' parameter as 'True to enable WiFi, False to disable', which adds meaning beyond the schema's bare type and title. With schema description coverage at 0%, this explanation is essential and effectively compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Enable or disable WiFi.' which is a clear, specific verb+resource action. This distinguishes it from sibling tools like get_wifi_network, which presumably retrieves network information, and other toggle tools like toggle_mute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It simply states the action without contextualizing it relative to get_wifi_network or other network-related 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 side effects and edge behavior. It only states that the tool marks a reminder complete, omitting what happens when list_name is omitted, how duplicate titles are handled, or whether the action is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the main action in the first sentence and a compact Args block. Every sentence adds necessary information without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The simple two-parameter tool is adequately described for basic invocation, and an output schema exists to cover return values. Nevertheless, the lack of detail about list_name omission and ambiguous titles leaves some contextual gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds semantic meaning by identifying title as the reminder to complete and list_name as an optional search scope. However, it does not fully compensate by explaining default list behavior or matching rules, leaving the parameter semantics only partially clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact action 'Mark a reminder as complete,' with a clear verb and resource, making its purpose unambiguous. It also distinguishes itself from sibling reminder tools like create_reminder and list_reminders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case—completing a reminder—and provides the optional list_name scoping, but it does not explicitly state when to use this tool over alternatives or 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.
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 disclosing behavior. It only states the action without explaining outcomes (e.g., success/failure), error handling, or side effects. Critical details such as whether it fails if the folder exists or if it creates intermediate directories are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using a single sentence plus a clearly labeled Args section. Every piece of text serves a purpose with no filler or repetition, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple one-parameter tool, but the description lacks essential behavioral context such as error handling and whether intermediate directories are created. The presence of an output schema is noted, but without knowing its content, the description alone does not fully cover operational expectations. It is minimally viable but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines only 'path' as a string with no description. The description adds meaning by stating 'Full path for the new folder,' which clarifies that the path must be absolute rather than relative. This is valuable context for a single parameter, though it does not cover all possible constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Create a new folder.' This is a specific verb and resource that unambiguously differentiates it from sibling tools, none of which create folders. No further clarification is needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any prerequisites or exclusions. While there are no direct siblings for folder creation, the description does not mention conditions like whether the folder already exists or if parent directories are required.
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 restates the action without revealing details like whether completed reminders are included, sorting order, or the default reminder list 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is mostly sufficient, but it leaves gaps such as what 'overdue' means (e.g., due date before now) and whether it aggregates across all reminder lists. These ambiguities could affect correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description adds semantic meaning by clarifying that the result includes 'all' overdue reminders, which is sufficient given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does 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 ('Get') and a specific resource ('all overdue reminders'), distinguishing it from sibling tools like list_reminders. The scope is unambiguous and directly tied to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 list_reminders or complete_reminder. The description does not mention exclusions, context, or selection criteria.
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, but it only states the core action without disclosing side effects, prerequisites, or error behaviors. For example, it does not say what happens if the app is not running or whether all windows are hidden. This is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise two-sentence definition with no filler, front-loading the core action in the first sentence. The parameter breakdown is structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-action tool with an output schema present, the description provides the essential information—what the tool does and what the input means. However, it omits behavioral caveats and usage guidance, leaving some gaps for an agent that may need to handle edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so by providing a one-line explanation for the app_name parameter ('Name of the application to hide'), which adds context beyond the schema's title 'App Name'. However, it lacks details such as whether it accepts a process name or display name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'hide' with a clear resource 'an application's windows', distinguishing it from sibling tools like launch_app, quit_app, and list_running_apps. There is no ambiguity about 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention any prerequisites or exclusion cases. However, the tool's purpose is self-evident, and the usage context is implied by the description.
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 mentions the new_instance parameter behavior. It does not state side effects like bringing the app to the foreground, behavior when the app is already running, or potential permission requirements. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single clear action statement followed by a structured Args section. Every word serves a purpose, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers the core action and parameters, and an output schema exists so return values need not be described. However, it lacks any context about checking app status or behavior when an app is already running, and it does not relate to sibling tools, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by providing example app names for app_name and explaining the new_instance behavior. Since schema description coverage is 0%, this compensation is essential and well executed for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with 'Launch an application' and provides concrete examples of app names. This verb+resource structure distinguishes it from sibling tools like quit_app, hide_app, and list_running_apps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 is_app_running or list_running_apps. There is no mention of prerequisites (e.g., app must be installed) or scenarios where launching might not be appropriate.
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 accurately indicates a read-only listing operation, but does not disclose details such as whether archived lists are included, ordering, or any side effects. For a simple list operation, this is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is front-loaded and appropriate for the simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter schema and presence of an output schema, the description covers the essential purpose. It doesn't explain return structure, but that's handled by the output schema. For a simple list operation, it's reasonably complete, though not as rich as the best examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter semantics to clarify. The baseline of 4 applies; no additional description needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'reminder lists', clearly indicating the tool's function. It distinguishes from sibling 'list_reminders' by focusing on lists rather than individual reminders, though it doesn't explicitly name the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like 'list_reminders' or 'create_reminder'. The description simply states the action without context 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 are provided, so the description carries the full burden of behavioral disclosure. It fails to mention that clearing the clipboard is destructive and irreversible, nor does it note any potential side effects or permissions needed. The sentence merely restates the action without additional 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, directly and efficiently conveying the tool's purpose. It earns its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters) and the presence of an output schema, the description covers the essential operation. However, it omits any warning about the irreversible destruction of clipboard data, which would make it more complete for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not explain any parameter semantics. The baseline for 0-parameter tools is 4, and the description appropriately focuses solely on the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Clear' and a clear resource 'clipboard contents', distinguishing it from sibling tools like get_clipboard and set_clipboard. It is unambiguous and precisely states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like set_clipboard (to overwrite) or get_clipboard (to read). It simply states the action without any contextual or conditional advice.
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 action and target, with no mention of side effects, return behavior, or error conditions, adding little 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly worded sentence with no wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's minimal complexity and the existence of an output schema, the description covers the essential purpose. It lacks an explicit note about behavior when WiFi is unavailable, but this is not critical for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially complete. The description needs to add no parameter information, and a baseline of 4 is appropriate for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the current WiFi network name' with a specific verb and resource. It clearly distinguishes from sibling tools like toggle_wifi by indicating a read 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/5
Does 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 such as WiFi being enabled. The agent must infer usage solely from the tool 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, the description carries the full burden of behavioral disclosure. It merely says 'Reveal a file or folder in Finder' but does not mention side effects like bringing Finder to the front, opening a new window, or behavior for invalid paths. This leaves an agent unaware of UI impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one clear sentence and a simple Args block. It avoids fluff and is front-loaded with the core purpose, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is largely sufficient. However, it lacks any contextual guidance about when to use it relative to sibling tools, which could be important given the large set of candidates. Overall, it is adequate for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no parameter descriptions (0% coverage), but the description compensates by specifying that 'path' refers to a file or folder. This adds semantic meaning beyond the schema's title, though it omits details like absolute vs relative path requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'reveal' and specifies the resource 'a file or folder in Finder', clearly distinguishing it from sibling tools like open_file or search_files. The action is clear 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as open_file or get_selected_files. The description only states the action without any 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.
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, but it only states that it searches using Spotlight. It does not mention return format, whether results are paths or file objects, potential limitations of Spotlight, or any side effects. The absence of this information forces the agent to infer behavior from the tool name and 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the primary sentence, followed by a compact Args list. Every sentence adds value, with no filler or repetition. The structure is easy to parse and directly supports invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the return format is presumably covered elsewhere. However, the description omits context such as the default search scope when 'location' is omitted, how results are sorted, and any prerequisites. While it is adequate for basic invocation, it feels incomplete for a thorough agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section explicitly explains 'query' (search query), 'location' (optional folder path), and 'kind' (optional file type filter with example values). This adds significant meaning beyond the schema's bare property names and types, fully covering all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for files using Spotlight.' This provides a specific verb (search), resource (files), and method (Spotlight), making it distinct from all sibling tools. It is immediately obvious what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 does not mention related tools like reveal_in_finder or get_selected_files, nor does it specify scenarios where the user should prefer search_files over other file-related tools. This leaves the decision solely to the agent.
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 transparency burden. It does add sound name choices and notes that None makes the notification silent, but it omits macOS permission requirements, error behavior for invalid sounds, and what the function returns or whether it blocks. These are notable gaps for a side-effectful 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: a one-sentence purpose followed by a compact Args list. Every line contributes necessary information and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has low complexity, a simple parameter set, and an output schema, so the description covers the essentials needed for invocation. It lacks only usage-sibling differentiation and permission caveats, which prevents a 5 but keeps it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the Args section compensates. It lists all four parameters and adds real meaning: sound includes examples and explains 'None for silent,' while title/message/subtitle are plainly defined. This goes beyond the schema's minimal property names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Send a macOS notification,' using a specific verb and resource. This clearly distinguishes it from siblings like say_text (speech) and send_alert (likely a dialog) even without naming 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternative tool mentions are provided. The description only states what the tool does and lists arguments, leaving it to the agent to infer context from siblings like send_alert and say_text.
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 responsibility for behavioral disclosure. It states the action but omits any details about reversibility, permission requirements, or side effects like display lock or system sleep. For a mutating action, this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, extremely concise and front-loaded with the action verb and target. There is no wasted verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema present, the description is nearly sufficient for an agent to invoke the tool correctly. However, it lacks any context about when to use it or what the system state change entails, which is a minor gap 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/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is effectively complete. The description adds nothing about parameters, but none exist to explain, and 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear imperative verb 'Put' and specifies the resource 'display', leaving no ambiguity about the tool's function. It distinguishes itself from sibling tools like toggle_dark_mode or set_volume because it specifically targets display sleep state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool relative to alternatives, nor does it mention prerequisites, side effects, or potential conflicts. An agent would have to infer usage solely from the tool's name and general 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, and the description merely restates the name's meaning. It does not disclose behavior such as what happens if already in dark mode, whether a return value is provided, or any system-wide effects beyond the basic toggle.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core action without any fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle with no parameters and an output schema present, the description is sufficient to convey the basic operation. It could be slightly more explicit about the state-transition behavior, but overall it covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to clarify. The baseline for zero-parameter tools is 4, and the description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Toggle' and clearly identifies the resource 'dark mode and light mode'. It distinguishes from siblings like set_dark_mode (which sets a specific state) and is_dark_mode (which checks state).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this toggle versus alternatives like set_dark_mode or is_dark_mode. The description simply states the action without any context 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 are provided, so the description carries the full burden for behavioral disclosure. It lists parameter meanings and formats but does not mention side effects beyond the obvious creation, error conditions, permissions, or how the system handles timezone/duplicates. This is a minimal disclosure 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact, well-structured list of arguments with brief explanations. It front-loads the main purpose in one sentence and avoids unnecessary prose. Slight redundancy with the schema exists, but it adds semantic value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all six parameters with formats and defaults, and an output schema is present, so return values need not be explained. Remaining gaps include error handling and prerequisites, but for a straightforward creation tool, the coverage is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining each parameter's purpose, providing ISO format for dates, and specifying a default for calendar_name. It adds meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new calendar event,' which is a specific verb and resource. It distinguishes from siblings like list_calendar_events (read-only) and create_reminder (different entity).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding events to a calendar but does not explicitly state when to use it versus alternatives. No exclusions or alternative recommendations are provided, so guidance is implicit rather than 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?
With no annotations, the description carries full responsibility for disclosing behavioral traits. It mentions launchd and parameter semantics but does not disclose important side effects (e.g., persistent file creation, whether duplicate names are rejected), permissions required, or what happens when both interval and calendar schedules are provided. This is a significant transparency 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured, with a terse opening line followed by a clean parameter list. Every sentence adds value; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basics and parameter meanings but omits critical scheduling semantics, such as how interval_seconds interacts with hour/minute (are they exclusive or additive?). Given the tool's moderate complexity and lack of annotations, this gap makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides meaningful explanations for all six parameters, including constraints like 'min 60' for interval_seconds and ranges for hour/minute. Since schema description coverage is 0%, this compensates well. However, it could add more nuance about the relationship between interval and calendar parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a scheduled task using launchd' with a specific verb and resource. It distinguishes itself from sibling tools like list_scheduled_tasks and remove_scheduled_task by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys the main use case (creating scheduled tasks) but does not explicitly discuss when to use this tool over alternatives or any exclusions. The context is clear, but there is no direct guidance on choosing between scheduling via interval_seconds versus calendar time parameters.
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 basic action and does not mention what happens when no files are selected, whether Finder must be running, or whether it returns file paths, URLs, or names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every word earns its place, and it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values need not be described. However, the description omits behavioral context like error handling, prerequisites, and edge cases, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema requires no parameter explanation. The description adds no parameter meaning, but none is needed; 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource: 'currently selected files in Finder.' It distinguishes itself from sibling tools like get_frontmost_app or get_volume by explicitly naming Finder and the selection context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: call when you need the current Finder selection. However, it offers no explicit alternatives, exclusions, or conditions under which this tool should not be used, and does not compare with similar file-related 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. It states the action but does not disclose whether the operation has any side effects, permissions, or other behavioral context. The read-only nature is implied 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states exactly what the tool does without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (0 params, has output schema), so the description is mostly sufficient for the basic purpose. However, it lacks any contextual guidance about when to use it relative to other calendar/reminder tools, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is 100% (empty schema). The description adds the qualifier 'all,' which clarifies the scope, but with 0 parameters, the baseline is 4 and no further parameter explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'all available calendars.' It is distinct from sibling tools like list_calendar_events, which focus on events rather than calendars.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does 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 list_calendar_events. Usage is implied by the verb and resource, but no exclusions or alternative recommendations 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?
With no annotations, the description carries the burden of disclosing side effects. It does state that force quits 'without saving', which is a meaningful behavioral detail. However, it does not explain what a normal quit does (e.g., whether it prompts to save), what happens if the app is not running, or any error/return behavior. This is partial 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence followed by a clear Args block. Every word earns its place, and the structure is front-loaded with the core action. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description covers the basic action and parameter semantics. However, it lacks usage context (e.g., when to use vs. 'hide_app') and omits behavioral details like return values (though an output schema exists). It is minimally viable but not fully complete given the sibling tools and lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions for either parameter (0% coverage). The description compensates by providing an Args section explaining 'app_name' as the name of the application and 'force' as a flag to quit without saving. This adds meaningful context that the schema alone lacks, though not deeply detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Quit an application') with a specific verb and resource. It distinguishes from sibling tools like 'launch_app' and 'hide_app' by explicitly indicating termination, not launching or hiding. The tool name 'quit_app' is effectively clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 'hide_app' (which hides without terminating) or 'launch_app'. The description simply states what it does but gives no context about prerequisites, preferred scenarios, or when to avoid 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 the full burden. It only states the basic read operation and text format; it does not disclose behavior for empty clipboard, non-text content, potential errors, or permissions. This is insufficient for full 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence. Every word contributes meaning, and the key information is front-loaded. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter getter with an output schema, the description covers the essential functionality. However, it lacks mention of edge cases like empty clipboard or non-text content, which prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description correctly omits parameter details. Per rubric, a baseline of 4 applies when no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('current clipboard contents'), with an explicit format ('as text'). It is specific and distinguishable from sibling tools like set_clipboard and clear_clipboard.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when clipboard content is needed) but provides no explicit guidance on when to use this tool over alternatives, nor does it mention exclusions or prerequisites. It is adequate but lacks directiveness.
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 states the basic action without clarifying what counts as a 'running application' (e.g., user apps vs. system processes), any permission requirements, or whether the operation is non-destructive. This is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tight sentence with no redundant wording. It is perfectly concise and front-loaded with the key verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter tool with an output schema, this description covers the essential purpose. Slight ambiguity about which processes are considered 'running applications' leaves a small gap, but overall the description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema trivially provides 100% coverage. The description adds no parameter-specific meaning, but none is needed; the baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'List' and the resource 'all currently running applications.' This distinguishes it from sibling tools like get_frontmost_app (single app) and is_app_running (existence check).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a list of running apps, but it offers no explicit guidance on when to use this tool versus alternatives like get_frontmost_app or is_app_running. 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 carries the full burden of behavioral disclosure. It discloses the state change but does not mention any side effects, error conditions (e.g., unsupported system), persistence, or permission requirements. For a mutation operation with zero annotation coverage, this 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two sentences that state the purpose and the parameter semantics without any extraneous text. Every sentence earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only one parameter, and the description covers the core purpose and parameter. However, it lacks explicit usage guidance and behavioral caveats. Given that an output schema exists, return values are likely covered, but the absence of any mention of when to use this over toggle_dark_mode or potential failure modes leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains the only parameter 'enabled': 'True for dark mode, False for light mode.' This adds meaning beyond the schema, which only lists the property as a boolean without semantic context, and schema description coverage is 0%. The single parameter is completely clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set dark mode to a specific state.' This distinguishes it from the sibling tool toggle_dark_mode, which flips the current state, and is_dark_mode, which queries it. The verb 'set' plus resource 'dark mode' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you want to explicitly set dark mode to on or off. However, it does not explicitly mention alternatives or exclusions, such as using toggle_dark_mode when you simply want to invert the current state. The context is present but not fully articulated.
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 mutation ('set') but does not disclose potential side effects, reversibility, error handling for out-of-range levels, or any permission requirements. This is a minimal disclosure for a system-mutating 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a single clear purpose sentence followed by an Args section documenting the parameter. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and an output schema, this is reasonably complete. It explains the tool's purpose and parameter semantics. However, it does not mention behavior for invalid inputs (e.g., clamping vs error), which could be valuable, but the simplicity keeps this from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines 'level' as an integer with no description. The description compensates by explaining that the level ranges from 0 (mute) to 100 (max), adding crucial semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the target (system volume level). It is specific and distinguishes from sibling tools like get_volume (retrieves) and toggle_mute (toggles between states).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific volume level needs to be set, but it does not explicitly mention when not to use it or provide alternatives like toggle_mute for muting. No exclusions or context 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?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose defaults (path defaults to Desktop with timestamp) and parameter behaviors (region enables interactive selection, to_clipboard saves to clipboard instead of file). However, it omits return value information, potential permission requirements (e.g., screen recording), and whether the capture is full-screen or window-specific.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, beginning with a one-sentence summary followed by a clear Args block. Every sentence provides useful information without redundant or excessive detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no annotations, the description covers core behavior and parameter effects. However, it lacks details on return values (though an output schema exists), required permissions, and the default capture scope (full screen vs. active window), leaving some context gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by explaining each parameter's purpose and behavior: path specifies save location, region toggles interactive selection, and to_clipboard changes the output target. This adds meaning beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Capture a screenshot.' with a specific verb and resource, clearly distinguishing it from sibling tools which do not include screenshot functionality. The parameter details further clarify capture modes such as region selection and clipboard output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the tool's name and summary but does not explicitly state when to use it versus alternatives or any exclusions. It provides no guidance on choosing between full-screen and region capture or when clipboard output is preferable.
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 states 'Create a new reminder' and lists parameters, but does not disclose any side effects, permissions, error behavior, or whether the operation is idempotent. This is 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose followed by a short argument list. Every sentence earns its place with no redundant or filler content. The front-loaded purpose helps the agent quickly grasp the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, an output schema is present (per context signals), and the description covers the purpose and all parameters adequately. It does not describe behavioral caveats, but for a straightforward 'create' operation with an output schema, the essential context is provided. However, some behavioral details (e.g., what happens if list_name doesn't exist) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description's parameter explanations are crucial. It provides meaning for all four parameters: title, list_name, due_date (including ISO format), and notes, along with defaults. This adds significant value beyond the schema's property types and required flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new reminder.' which is a specific verb and resource, clearly indicating the tool's function. It distinguishes itself from sibling reminder tools like list_reminders, complete_reminder, and get_overdue_reminders by focusing on the creation action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does 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 a new reminder needs to be created) through its direct statement. However, it does not explicitly mention alternatives or when not to use it, but the context is clear enough given the tool's distinct purpose 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?
With no annotations provided, the description carries the full burden. It indicates the tool is a read-only operation via the verb 'Get' and adds scoping (currently active/frontmost). However, it does not explicitly state that it has no side effects, what information is returned, or any edge cases. This is adequate for a simple getter 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. No unnecessary words or filler. It earns its place perfectly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description is mostly complete. It defines what the tool does and its target (frontmost app). It falls slightly short of 5 because it doesn't mention any possible return values or error conditions, but the output schema likely covers the return shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to explain. The baseline for 0 params is 4, and no additional parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving information about the currently active (frontmost) application. The verb 'Get' is specific, the resource is well-defined, and it distinguishes itself from sibling tools like list_running_apps and is_app_running by focusing on the frontmost app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining info about the active app but provides no explicit guidance on when to use it vs. alternatives (e.g., list_running_apps). The context is self-evident from the name and description, but there is no mention of exclusions or 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 present, so the description carries full responsibility for behavioral disclosure. It indicates a read operation ('get'), which implies non-destructive behavior, but does not explicitly state that there are no side effects, whether permissions are needed, or what happens on error. For a simple getter, this is minimally adequate 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of eight words, 'Get the current system volume level.' It is perfectly concise, front-loaded, and contains no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with an output schema, the description is nearly complete. It clearly identifies the action and resource, and the output schema presumably covers the return format. A minor gap is the lack of any mention of volume scale or units, but that is not essential given the output schema and simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The schema is empty, and the description does not need to explain any parameter details. The tool takes no input, so nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'get' and the resource 'system volume level', clearly distinguishing this read operation from sibling tools like set_volume and toggle_mute. It is unambiguous and exactly states what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that it retrieves the current volume level, which implies usage when a read of the volume is needed. However, it does not explicitly compare against set_volume, toggle_mute, or other alternatives, nor does it provide any 'when not to use' guidance. Usage is only implied by the name and the get verb.
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. The term 'toggle' transparently indicates a state flip, but it does not elaborate on side effects (e.g., whether it affects volume level), system-wide impact, or permissions needed. It provides basic behavioral insight but no extra 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that immediately states the action and resource. Every word earns its place—no filler, no redundancy—making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter toggle tool, the description is adequate. An output schema exists to cover return values, and the description explains the core behavior sufficiently. It could mention edge cases (e.g., if no audio device is present), but this is a minor gap for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema is fully covered by definition. The description adds no param-specific meaning, but none is needed. Per the rubric, a zero-parameter tool earns a baseline 4, which is appropriately high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'toggle' and the resource 'system audio mute', clearly indicating the action. It distinguishes from sibling tools like 'set_volume' and 'get_volume' by focusing exclusively on mute state, leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: it toggles mute on/off, so an agent can infer when to use it. However, it does not explicitly explain when to prefer this over 'set_volume' (e.g., for adjusting volume) or how to check the current mute state, lacking explicit 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 are provided, so the description must carry the full burden of behavioral disclosure. It identifies the operation as a read ('Get') and lists output fields, but does not explicitly state that it is read-only, requires no permissions, has no side effects, or describe the response format. This leaves the agent without confirmation of safety or behavioral expectations beyond the basic verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is 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 a compact list of key fields. There is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description only needs to orient the agent. Listing four key fields (hostname, version, user, uptime) is sufficient for a straightforward system info getter; the 'including' qualifier and output schema cover the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema inherently covers all parameter needs. The description adds no parameter-level semantics, but with no parameters, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'macOS system information', listing concrete fields (hostname, version, user, uptime). This clearly distinguishes it from sibling getters that target other domains, such as get_wifi_network or get_frontmost_app.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when macOS-level system details are needed by enumerating the specific fields returned. It does not explicitly discuss alternatives or exclusions, but there is no sibling tool with overlapping functionality, so the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the essential behavioral trait of waiting for user response (implying blocking) and includes the constraint of maximum 3 buttons. However, it does not mention potential side effects (e.g., whether the dialog blocks the entire app or just the tool) or what happens if no buttons are supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a clean Args list. Every sentence earns its place, and it avoids redundant prose or filler. The format is easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (so return values need not be described), the description provides sufficient context. It covers the core behavior and every parameter. A brief example or clarification of default_button semantics would make it more complete, but it is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The Args section adds meaning beyond the schema: 'List of button names (max 3)' introduces a max-items constraint not present in the schema, and 'Name of the default button' clarifies the parameter's purpose. However, the descriptions are terse and do not explain the relationship between buttons and default_button (e.g., default_button must be one of the buttons).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and resource ('alert dialog') and adds the critical behavior 'wait for user response,' which clearly distinguishes it from passive notification tools like send_notification and list-based selection tools like choose_from_list. This is a clear and precise purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for interactive prompts ('wait for user response') but does not explicitly contrast it with sibling tools such as send_notification or choose_from_list. No exclusions or alternative recommendations are provided, so an agent might not know when to prefer this tool over a notification.
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 states the action but does not disclose additional behavioral traits such as read-only status, response format, or behavior when no tasks exist. The verb 'list' implies a non-destructive operation, and no annotations are provided to cover safety, so the description carries the burden but only partially fulfills it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the verb and resource, with no wasted words. It is 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with an output schema, the description sufficiently identifies the tool's purpose and scope. It doesn't need to explain return values since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does 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 explain beyond what the schema already shows. The baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with the specific resource 'MCP-managed scheduled tasks', clearly distinguishing it from sibling list tools that target calendars, reminders, or running apps. The scope ('all') is also explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that this tool lists scheduled tasks, but does not explicitly state when to use it over alternatives like create_scheduled_task or remove_scheduled_task. The resource name implies the use case, but no exclusions or 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?
No annotations are provided, so the description must carry the burden. It states the basic action but does not disclose potential side effects (e.g., audible output, blocking behavior, effects of invalid voice). 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a one-sentence purpose followed by an Args block. Every element contributes useful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and the description covers parameters adequately. It could add minor behavioral context (e.g., whether it blocks until speech finishes), but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description compensates fully by explaining each parameter: text, voice with examples, and rate with units. This adds significant meaning beyond the bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Speak text using text-to-speech.' It uses a specific verb and resource, and no sibling tool performs text-to-speech, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for speech synthesis and provides optional parameters. It does not explicitly mention when not to use it, but with no competing TTS siblings, this is acceptable and remains clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior itself. 'Check if dark mode is currently enabled' clearly indicates a read-only operation with no side effects. It doesn't detail output format or edge cases, but for a no-parameter system query, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word contributes to conveying the tool's function, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given 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 nested objects), the description fully captures what it does. An output schema exists to specify the return type, so the description needn't elaborate further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, making parameter semantics trivially clear. The input schema is an empty object, and no parameter-specific explanation is needed. 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/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and identifies the resource 'dark mode' with an explicit condition 'currently enabled'. It clearly distinguishes itself from sibling tools like toggle_dark_mode or set_dark_mode, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The verb 'Check' clearly implies this tool is for querying the current state, not modifying it. It lacks explicit references to alternative tools or 'when-not-to-use' guidance, so it doesn't reach a perfect 5, but the usage context is very clear.
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:

[![mcp-applescript-automation MCP server](https://glama.ai/mcp/servers/matthewdcage/mcp-applescript-automation/badges/card.svg)](https://glama.ai/mcp/servers/matthewdcage/mcp-applescript-automation)

Score Badge

Copy to your README.md:

[![mcp-applescript-automation MCP server](https://glama.ai/mcp/servers/matthewdcage/mcp-applescript-automation/badges/score.svg)](https://glama.ai/mcp/servers/matthewdcage/mcp-applescript-automation)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/matthewdcage/mcp-applescript-automation'

If you have feedback or need assistance with the MCP directory API, please join our Discord server