Skip to main content
Glama
SuperCrazyKaizen

macOS Automator MCP Server

macOS Automator MCP Server

macOS Automator MCP Server

Overview

This project provides a Model Context Protocol (MCP) server, macos_automator, that allows execution of AppleScript and JavaScript for Automation (JXA) scripts on macOS. It features a knowledge base of pre-defined scripts accessible by ID and supports inline scripts, script files, and argument passing. The knowledge base is loaded lazily on first use for fast server startup.

Related MCP server: macOS Automator MCP Server

Benefits

  • Execute AppleScript/JXA scripts remotely via MCP.

  • Utilize a rich, extensible knowledge base of common macOS automation tasks.

  • Control macOS applications and system functions programmatically.

  • Integrate macOS automation into larger AI-driven workflows.

Prerequisites

  • Node.js (version >=18.0.0 recommended, see package.json engines).

  • macOS.

  • CRITICAL PERMISSIONS SETUP:

    • The application running THIS MCP server (e.g., Terminal, your Node.js application) requires explicit user permissions on the macOS machine where the server is running.

    • Automation Permissions: To control other applications (Finder, Safari, Mail, etc.).

      • Go to: System Settings > Privacy & Security > Automation.

      • Find the application running the server (e.g., Terminal) in the list.

      • Ensure it has checkboxes ticked for all applications it needs to control.

      • See example: docs/automation-permissions-example.png (placeholder image).

    • Accessibility Permissions: For UI scripting via "System Events" (e.g., simulating clicks, keystrokes).

      • Go to: System Settings > Privacy & Security > Accessibility.

      • Add the application running the server (e.g., Terminal) to the list and ensure its checkbox is ticked.

    • First-time attempts to control a new application or use accessibility features may still trigger a macOS confirmation prompt, even if pre-authorized. The server itself cannot grant these permissions.

Installation & Usage

The primary way to run this server is via npx. This ensures you're using the latest version without needing a global install.

Add the following configuration to your MCP client's mcp.json (or equivalent configuration):

{
  "mcpServers": {
    "macos_automator": {
      "command": "npx",
      "args": [
        "-y",
        "@steipete/macos-automator-mcp@latest"
      ]
    }
  }
}

Running Locally (for Development or Direct Use)

Alternatively, for development or if you prefer to run the server directly from a cloned repository, you can use the provided start.sh script. This is useful if you want to make local modifications or run a specific version.

  1. Clone the repository:

    git clone https://github.com/steipete/macos-automator-mcp.git
    cd macos-automator-mcp
    npm install # Ensure dependencies are installed
  2. Configure your MCP client: Update your MCP client's configuration to point to the absolute path of the start.sh script within your cloned repository.

    Example mcp.json configuration snippet:

    {
      "mcpServers": {
        "macos_automator_local": {
          "command": "/absolute/path/to/your/cloned/macos-automator-mcp/start.sh",
          "env": {
            "LOG_LEVEL": "DEBUG"
          }
        }
      }
    }

    Important: Replace /absolute/path/to/your/cloned/macos-automator-mcp/start.sh with the correct absolute path on your system.

    The start.sh script will automatically use tsx to run the TypeScript source directly if a compiled version is not found, or run the compiled version from dist/ if available. It respects the LOG_LEVEL environment variable.

    Note for Developers: The start.sh script, particularly if modified to remove any pre-existing compiled dist/server.js before execution (e.g., by adding rm -f dist/server.js), is designed to ensure you are always running the latest TypeScript code from the src/ directory via tsx. This is ideal for development to prevent issues with stale builds. For production deployment (e.g., when published to npm), a build process would typically create a definitive dist/server.js which would then be the entry point for the published package.

Tools Provided

1. execute_script

Executes an AppleScript or JavaScript for Automation (JXA) script on macOS. Scripts can be provided as inline content (script_content), an absolute file path (script_path), or by referencing a script from the built-in knowledge base using its unique kb_script_id.

Script Sources (mutually exclusive):

  • script_content (string): Raw script code.

  • script_path (string): Absolute POSIX path to a script file (e.g., .applescript, .scpt, .js).

  • kb_script_id (string): The ID of a pre-defined script from the server's knowledge base. Use the get_scripting_tips tool to discover available script IDs and their functionalities.

Language Specification:

  • language (enum: 'applescript' | 'javascript', optional): Specify the language.

    • If using kb_script_id, the language is inferred from the knowledge base script.

    • If using script_content or script_path and language is omitted, it defaults to 'applescript'.

Passing Inputs to Scripts:

  • arguments (array of strings, optional):

    • For script_path: Passed as standard arguments to the script's on run argv (AppleScript) or run(argv) (JXA) handler.

    • For kb_script_id: Used if the pre-defined script is designed to accept positional string arguments (e.g., replaces placeholders like --MCP_ARG_1, --MCP_ARG_2). Check the script's argumentsPrompt from get_scripting_tips.

  • input_data (JSON object, optional):

    • Primarily for kb_script_id scripts designed to accept named, structured inputs.

    • Values from this object replace placeholders in the script (e.g., --MCP_INPUT:yourKeyName). See argumentsPrompt from get_scripting_tips.

    • Values (strings, numbers, booleans, simple arrays/objects) are converted to their AppleScript literal equivalents.

Other Options:

  • timeout_seconds (integer, optional, default: 60): Maximum execution time.

  • output_format_mode (enum, optional, default: 'auto'): Controls osascript output formatting flags.

    • 'auto': (Default) Uses human-readable for AppleScript (-s h), and direct output (no -s flags) for JXA.

    • 'human_readable': Forces -s h (human-readable output, mainly for AppleScript).

    • 'structured_error': Forces -s s (structured error reporting, mainly for AppleScript).

    • 'structured_output_and_error': Forces -s ss (structured output for main result and errors, mainly for AppleScript).

    • 'direct': No -s flags are used (recommended for JXA, also the behavior for JXA in auto mode).

  • include_executed_script_in_output (boolean, optional, default: false): If true, the output will include the full script content (after any placeholder substitutions for knowledge base scripts) or the script path that was executed. This is appended as an additional text part in the output content array.

  • include_substitution_logs (boolean, optional, default: false): If true, detailed logs of placeholder substitutions performed on knowledge base scripts are included in the output. This is useful for debugging how input_data and arguments are processed and inserted into the script. The logs are prepended to the script output on success or appended to the error message on failure.

  • report_execution_time (boolean, optional, default: false): If true, an additional message with the formatted script execution time will be included in the response content array.

SECURITY WARNING & MACOS PERMISSIONS: (Same critical warnings as before about arbitrary script execution and macOS Automation/Accessibility permissions).

Examples:

  • (Existing examples for inline/file path remain relevant)

  • Using Knowledge Base Script by ID:

    {
      "toolName": "execute_script",
      "input": {
        "kb_script_id": "safari_get_active_tab_url",
        "timeout_seconds": 10
      }
    }
  • Using Knowledge Base Script by ID with input_data:

    {
      "toolName": "execute_script",
      "input": {
        "kb_script_id": "finder_create_folder_at_path",
        "input_data": {
          "folder_name": "New MCP Folder",
          "parent_path": "~/Desktop"
        }
      }
    }

Response Format:

The execute_script tool returns a response in the following format:

{
  content: Array<{
    type: 'text';
    text: string;
  }>;
  isError?: boolean;
}
  • content: An array of text content items containing the script output

  • isError: (boolean, optional) Set to true when the script execution produced an error. This flag is set when:

    • The script output (stdout) starts with "Error" (case-insensitive)

    • This helps clients easily determine if the execution failed without parsing the output text

Example Response (Success):

{
  "content": [{
    "type": "text",
    "text": "Script executed successfully"
  }]
}

Example Response (Error):

{
  "content": [{
    "type": "text",
    "text": "Error: Cannot find application 'Safari'"
  }],
  "isError": true
}

2. get_scripting_tips

Retrieves AppleScript/JXA tips, examples, and runnable script details from the server's knowledge base. Useful for discovering available scripts, their functionalities, and how to use them with execute_script (especially kb_script_id).

Arguments:

  • list_categories (boolean, optional, default: false): If true, returns only the list of available knowledge base categories and their descriptions. Overrides other parameters.

  • category (string, optional): Filters tips by a specific category ID (e.g., "finder", "safari").

  • search_term (string, optional): Searches for a keyword within tip titles, descriptions, script content, keywords, or IDs.

  • refresh_database (boolean, optional, default: false): If true, forces a reload of the entire knowledge base from disk before processing the request. This is useful during development if you are actively modifying knowledge base files and want to ensure the latest versions are used without restarting the server.

  • limit (integer, optional, default: 10): Maximum number of results to return.

Output:

  • Returns a Markdown formatted string containing the requested tips, including their title, description, script content, language, runnable ID (if applicable), argument prompts, and notes.

Example Usage:

  • List all categories: { "toolName": "get_scripting_tips", "input": { "list_categories": true } }

  • Get tips for "safari" category: { "toolName": "get_scripting_tips", "input": { "category": "safari" } }

  • Search for tips related to "clipboard": { "toolName": "get_scripting_tips", "input": { "search_term": "clipboard" } }

Key Use Cases & Examples

  • Application Control:

    • Get the current URL from Safari: { "input": { "script_content": "tell application \"Safari\" to get URL of front document" } }

    • Get subjects of unread emails in Mail: { "input": { "script_content": "tell application \"Mail\" to get subject of messages of inbox whose read status is false" } }

  • File System Operations:

    • List files on the Desktop: { "input": { "script_content": "tell application \"Finder\" to get name of every item of desktop" } }

    • Create a new folder: { "input": { "script_content": "tell application \"Finder\" to make new folder at desktop with properties {name:\"My New Folder\"}" } }

  • System Interactions:

    • Display a system notification: { "input": { "script_content": "display notification \"Important Update!\" with title \"System Alert\"" } }

    • Set system volume: { "input": { "script_content": "set volume output volume 50" } } (0-100)

    • Get current clipboard content: { "input": { "script_content": "the clipboard" } }

Troubleshooting

  • Permissions Errors: If scripts fail to control apps or perform UI actions, double-check Automation and Accessibility permissions in System Settings for the application running the MCP server (e.g., Terminal).

  • Script Syntax Errors: osascript errors will be returned in the stderr or error message. Test complex scripts locally using Script Editor (for AppleScript) or a JXA runner first.

  • Timeouts: If a script takes longer than timeout_seconds (default 60s), it will be terminated. Increase the timeout for long-running scripts.

  • File Not Found: Ensure script_path is an absolute POSIX path accessible by the user running the MCP server.

  • Incorrect Output/JXA Issues: For JXA scripts, especially those using Objective-C bridging, ensure output_format_mode is set to 'direct' or 'auto' (default). Using AppleScript-specific formatting flags like human_readable with JXA can cause errors. If AppleScript output is not parsing correctly, try structured_output_and_error or structured_error.

Configuration via Environment Variables

  • LOG_LEVEL: Set the logging level for the server.

    • Values: DEBUG, INFO, WARN, ERROR

    • Example: LOG_LEVEL=DEBUG npx @steipete/macos-automator-mcp@latest

  • KB_PARSING: Controls when the knowledge base (script tips) is parsed.

    • Values:

      • lazy (default): The knowledge base is parsed on the first request to get_scripting_tips or when a kb_script_id is used in execute_script. This allows for faster server startup.

      • eager: The knowledge base is parsed when the server starts up. This may slightly increase startup time but ensures the KB is immediately available and any parsing errors are caught early.

    • Example (when running via start.sh or similar):

      KB_PARSING=eager ./start.sh
    • Example (when configuring via an MCP runner that supports env, like mcp-agentify):

      {
        "env": {
          "LOG_LEVEL": "INFO",
          "KB_PARSING": "eager"
        }
      }

For Developers

For detailed instructions on local development, project structure (including the knowledge_base), and contribution guidelines, please see DEVELOPMENT.md.

Development

See DEVELOPMENT.md for details on the project structure, building, and testing.

Local Knowledge Base

You can supplement the built-in knowledge base with your own local tips and shared handlers. Create a directory structure identical to the knowledge_base in this repository (or a subset of it).

By default, the application will look for this local knowledge base at ~/.macos-automator/knowledge_base. You can customize this path by setting the LOCAL_KB_PATH environment variable.

Example:

Suppose you have a local knowledge base at /Users/yourname/my-custom-kb. Set the environment variable: export LOCAL_KB_PATH=/Users/yourname/my-custom-kb

Or, if you are running the validator script, you can use the --local-kb-path argument: npm run validate:kb -- --local-kb-path /Users/yourname/my-custom-kb

Structure and Overrides:

  • Your local knowledge base should mirror the category structure of the main knowledge_base (e.g., 01_applescript_core, 05_web_browsers/safari, etc.).

  • You can add new .md tip files or _shared_handlers (e.g., .applescript or .js files).

  • If a tip ID (either from frontmatter id: or generated from filename/path) in your local knowledge base matches an ID in the embedded knowledge base, your local version will override the embedded one.

  • Similarly, shared handlers with the same name and language (e.g., my_utility.applescript) in your local _shared_handlers directory will override any embedded ones with the same name and language within the same category (or globally if you place them at the root of your local KB's _shared_handlers).

  • Category descriptions from _category_info.md in your local KB can also override those from the embedded KB for the same category.

This allows for personalization and extension of the available automation scripts and tips without modifying the core application files.

Contributing

Contributions are welcome! Please submit issues and pull requests to the GitHub repository.

Automation Capabilities

This server provides powerful macOS automation capabilities through AppleScript and JavaScript for Automation (JXA). Here are some of the most useful examples:

Terminal Automation

  • Run commands in new Terminal tabs:

    { "input": { "kb_script_id": "terminal_app_run_command_new_tab", "input_data": { "command": "ls -la" } } }
  • Execute commands with sudo and provide password securely

  • Capture command output for processing

Browser Control

  • Chrome/Safari automation:

    { "input": { "kb_script_id": "chrome_open_url_new_tab_profile", "input_data": { "url": "https://example.com", "profile_name": "Default" } } }
    { "input": { "kb_script_id": "safari_get_front_tab_url" } }
  • Execute JavaScript in browser context:

    { "input": { "kb_script_id": "chrome_execute_javascript", "input_data": { "javascript_code": "document.title" } } }
  • Extract page content, manipulate forms, and automate workflows

  • Take screenshots of web pages

System Interaction

  • Toggle system settings (dark mode, volume, network):

    { "input": { "kb_script_id": "systemsettings_toggle_dark_mode_ui" } }
  • Get/set clipboard content:

    { "input": { "kb_script_id": "system_clipboard_get_file_paths" } }
  • Open/control system dialogs and alerts

  • Create and manage system notifications

File Operations

  • Create, move, and manipulate files/folders:

    { "input": { "kb_script_id": "finder_create_new_folder_desktop", "input_data": { "folder_name": "My Project" } } }
  • Read and write text files:

    { "input": { "kb_script_id": "fileops_read_text_file", "input_data": { "file_path": "~/Documents/notes.txt" } } }
  • List and filter files in directories

  • Get file metadata and properties

Application Integration

  • Calendar/Reminders management:

    { "input": { "kb_script_id": "calendar_create_event", "input_data": { "title": "Meeting", "start_date": "2023-06-01 10:00", "end_date": "2023-06-01 11:00" } } }
  • Email automation with Mail.app:

    { "input": { "kb_script_id": "mail_send_email_direct", "input_data": { "recipient": "user@example.com", "subject": "Hello", "body_content": "Message content" } } }
  • Control music playback:

    { "input": { "kb_script_id": "music_playback_controls", "input_data": { "action": "play" } } }
  • Work with creative apps (Keynote, Pages, Numbers)

Use the get_scripting_tips tool to explore all available automation capabilities organized by category.

License

This project is licensed under the MIT License. See the LICENSE file for details.

Available Tools

2 tools
execute_scriptA

Automate macOS tasks using AppleScript or JXA (JavaScript for Automation) to control applications like Terminal, Chrome, Safari, Finder, etc.

1. Script Source (Choose one):

  • kb_script_id (string): Preferred. Executes a pre-defined script from the knowledge base by its ID. Use get_scripting_tips to find IDs and inputs. Supports placeholder substitution via input_data or arguments. Ex: kb_script_id: "safari_get_front_tab_url".

  • script_content (string): Executes raw AppleScript/JXA code. Good for simple or dynamic scripts. Ex: script_content: "tell application \"Finder\" to empty trash".

  • script_path (string): Executes a script from an absolute POSIX path on the server. Ex: /Users/user/myscripts/myscript.applescript.

2. Script Inputs (Optional):

  • input_data (JSON object): For kb_script_id, provides named inputs (e.g., --MCP_INPUT:keyName). Values (string, number, boolean, simple array/object) are auto-converted. Ex: input_data: { "folder_name": "New Docs" }.

  • arguments (array of strings): For script_path (passes to on run argv / run(argv)). For kb_script_id, used for positional args (e.g., --MCP_ARG_1).

3. Execution Options (Optional):

  • language ('applescript' | 'javascript'): Specify for script_content/script_path (default: 'applescript'). Inferred for kb_script_id.

  • timeout_seconds (integer, optional, default: 60): Sets the maximum time (in seconds) the script is allowed to run. Increase for potentially long-running operations.

  • output_format_mode (enum, optional, default: 'auto'): Controls osascript output formatting.

    • 'auto': Smart default - resolves to 'human_readable' for AppleScript and 'direct' for JXA.

    • 'human_readable': For AppleScript, uses -s h flag.

    • 'structured_error': For AppleScript, uses -s s flag (structured errors).

    • 'structured_output_and_error': For AppleScript, uses -s ss flag (structured output & errors).

    • 'direct': No special output flags (recommended for JXA).

  • include_executed_script_in_output (boolean, optional, default: false): If true, the final script content (after any placeholder substitutions) or script path that was executed will be included in the response. This is useful for debugging and understanding exactly what was run. Defaults to false.

  • include_substitution_logs (boolean, default: false): For kb_script_id, includes detailed placeholder substitution logs.

  • report_execution_time (boolean, optional, default: false): If true, an additional message with the formatted script execution time will be included in the response. Defaults to false.

ParametersJSON Schema
NameRequiredDescriptionDefault
script_contentNo
script_pathNo
kb_script_idNo
languageNo
argumentsNo
input_dataNo
timeout_secondsNo
include_executed_script_in_outputNo
include_substitution_logsNo
report_execution_timeNo
output_format_modeNo

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does an excellent job describing execution characteristics: timeout behavior (default 60 seconds, 'Increase for potentially long-running operations'), output formatting options with detailed enum explanations, debugging features (include_executed_script_in_output, include_substitution_logs), and performance reporting (report_execution_time). The only gap is it doesn't mention security implications or permission requirements for executing scripts.

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 perfectly structured and appropriately sized. It begins with a clear purpose statement, then organizes complex parameter information into logical sections with bold headers. Every sentence adds value: examples illustrate usage, notes explain defaults and recommendations, and technical details are presented clearly. Despite the complexity, there's no wasted text 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 high complexity (11 parameters, nested objects, no annotations, no output schema), the description is remarkably complete. It covers all parameters thoroughly, explains execution behavior, provides usage examples, and references the sibling tool. The only minor gap is the lack of information about return values or error handling since there's no output schema. For a tool with this level of complexity, it's nearly comprehensive.

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?

With 0% schema description coverage for 11 parameters, the description must and does fully compensate. It provides comprehensive semantic explanations for all parameters organized into logical groups: Script Source (kb_script_id, script_content, script_path), Script Inputs (input_data, arguments), and Execution Options (language, timeout_seconds, output_format_mode, include_executed_script_in_output, include_substitution_logs, report_execution_time). Each parameter gets clear usage guidance, examples, and relationships 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: 'Automate macOS tasks using AppleScript or JXA (JavaScript for Automation) to control applications like Terminal, Chrome, Safari, Finder, etc.' It specifies the verb ('automate'), resource ('macOS tasks'), technology ('AppleScript or JXA'), and target applications. This distinguishes it from the sibling tool 'get_scripting_tips' which is for finding script IDs rather than execution.

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

Usage Guidelines4/5

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

The description provides clear context for when to use different script sources: 'kb_script_id' is 'Preferred' for pre-defined scripts, 'script_content' is 'Good for simple or dynamic scripts', and 'script_path' is for scripts from server paths. It references the sibling tool 'get_scripting_tips' to find IDs. However, it doesn't explicitly state when NOT to use this tool or what alternatives might exist beyond the sibling.

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

get_scripting_tipsA

Discover how to automate any app on your Mac with this comprehensive knowledge base of AppleScript/JXA tips and runnable scripts. This tool is essential for discovery and should be the FIRST CHOICE when aiming to automate macOS tasks, especially those involving common applications or system functions, before attempting to write scripts from scratch. It helps identify pre-built, tested solutions, effectively teaching you how to control virtually any aspect of your macOS experience.

Primary Use Cases & Parameters:

  • Discovering Solutions (Use search_term):

    • Parameter: search_term (string, optional).

    • Functionality: Performs a fuzzy search across all tip titles, descriptions, keywords, script content, and IDs. Ideal for natural language queries like "how to..." (e.g., search_term: "how do I get the current Safari URL and title?"). This is the most common way to find relevant tips.

    • Output: Returns a list of matching tips in Markdown format.

  • Limiting Search Results (Use limit):

    • Parameter: limit (integer, optional, default: 10).

    • Functionality: Specifies the maximum number of script tips to return when using search_term or browsing a specific category (without list_categories: true). Does not apply if list_categories is true.

  • Browsing by Category (Use category):

    • Parameter: category (string, optional).

    • Functionality: Shows tips from a specific category. Combine with limit to control result count.

    • Example: category: "01_intro" or category: "07_browsers/chrome".

  • Listing All Categories (Use list_categories: true):

    • Parameter: list_categories (boolean, optional).

    • Functionality: Returns a structured list of all available categories with their descriptions. This helps you understand what automation areas are covered.

    • Output: Category tree in Markdown format.

  • Refreshing Database (Use refresh_database: true):

    • Parameter: refresh_database (boolean, optional).

    • Functionality: Forces a reload of the knowledge base if new scripts have been added. Typically not needed as the database refreshes automatically.

Best Practices:

  1. Always start with search: Use natural language queries to find solutions (e.g., "send email from Mail app").

  2. Browse categories when exploring: Use list_categories: true to see available automation areas.

  3. Use specific IDs for execution: Once you find a script, use its ID with execute_script tool for precise execution.

ParametersJSON Schema
NameRequiredDescriptionDefault
categoryNo
search_termNo
list_categoriesNo
refresh_databaseNo
limitNo

TDQS

A4.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it's a read-only discovery tool (implied by 'discover' and 'knowledge base'), outputs results in Markdown format, and mentions database refresh functionality. However, it lacks details on rate limits, error handling, or authentication needs, which are minor gaps.

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 well-structured with sections like 'Primary Use Cases & Parameters' and 'Best Practices,' making it easy to scan. However, it is lengthy (over 300 words), which may be excessive for a tool description. Some details could be condensed without losing clarity, though all content is relevant and front-loaded with key purpose.

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 complexity (5 parameters, 0% schema coverage, no output schema, no annotations), the description is highly complete. It covers purpose, usage, parameters, outputs (Markdown format), and integration with sibling tools. No significant gaps remain for an agent to understand and invoke the tool correctly in context.

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 schema description coverage is 0%, so the description must fully compensate. It does so comprehensively: each of the 5 parameters is explained with clear semantics, including functionality, examples (e.g., for 'search_term'), and interactions (e.g., 'limit' applies to 'search_term' or 'category' but not 'list_categories'). This adds significant value beyond the bare 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 tool's purpose: to 'discover how to automate any app on your Mac' using a 'knowledge base of AppleScript/JXA tips and runnable scripts.' It specifies the verb 'discover' and resource 'tips and scripts,' distinguishing it from the sibling tool 'execute_script' which is for execution rather than discovery. This is specific and avoids tautology.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool: it states it 'should be the FIRST CHOICE when aiming to automate macOS tasks... before attempting to write scripts from scratch.' It also mentions alternatives, advising to 'use its ID with `execute_script` tool for precise execution' after discovery. This includes clear when-to-use and when-not-to-use scenarios.

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

TDQS

A4.4/5.0
Disambiguation5/5

The two tools have completely distinct purposes with no overlap: execute_script runs automation scripts, while get_scripting_tips provides discovery and learning resources. An agent would never confuse these tools as one performs actions and the other provides information.

Naming Consistency5/5

Both tools follow a consistent verb_noun naming pattern (execute_script, get_scripting_tips) with clear action-oriented verbs. The naming is perfectly consistent across the minimal tool set.

Tool Count2/5

With only 2 tools, this server feels severely underpowered for the ambitious scope of 'macOS automation.' While the tools are well-designed, a comprehensive automation server would typically need tools for managing workflows, monitoring automation status, or handling different automation technologies beyond just scripts.

Completeness3/5

The server covers the basic execute/discover workflow well, but lacks tools for managing automation workflows, scheduling tasks, or monitoring running automations. For a macOS automation server, there are notable gaps in lifecycle management and broader automation capabilities beyond script execution.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    A
    maintenance
    Provides a Model Context Protocol server for executing AppleScript and JavaScript for Automation scripts on macOS, featuring a knowledge base of pre-defined scripts and supporting automation of macOS applications and system functions.
    2
    1,294
    874
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    A Model Context Protocol server that enables AI assistants to control Apple Keynote presentations through AppleScript automation, supporting comprehensive slide creation, management, and content operations.
    74
    MIT

Latest Blog Posts

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/SuperCrazyKaizen/macos-automator-mcp'

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