macOS Automator MCP Server
Interacts with Apple applications like Mail, Calendar, Reminders, Keynote, Pages, and Numbers for email automation, calendar management, and content creation.
Executes JavaScript for Automation (JXA) scripts on macOS, enabling automation of applications and system functions using JavaScript syntax.
Executes AppleScript and JavaScript for Automation (JXA) scripts on macOS, allowing control of system functions, file operations, and application automation.
Controls Safari browser by getting URLs, executing JavaScript in the browser context, extracting page content, and automating browser workflows.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@macOS Automator MCP Serveropen a new Safari window and navigate to apple.com"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.jsonengines).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.
Clone the repository:
git clone https://github.com/steipete/macos-automator-mcp.git cd macos-automator-mcp npm install # Ensure dependencies are installedConfigure your MCP client: Update your MCP client's configuration to point to the absolute path of the
start.shscript within your cloned repository.Example
mcp.jsonconfiguration 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.shwith the correct absolute path on your system.The
start.shscript will automatically usetsxto run the TypeScript source directly if a compiled version is not found, or run the compiled version fromdist/if available. It respects theLOG_LEVELenvironment variable.Note for Developers: The
start.shscript, particularly if modified to remove any pre-existing compileddist/server.jsbefore execution (e.g., by addingrm -f dist/server.js), is designed to ensure you are always running the latest TypeScript code from thesrc/directory viatsx. 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 definitivedist/server.jswhich 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 theget_scripting_tipstool 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_contentorscript_pathandlanguageis omitted, it defaults to 'applescript'.
Passing Inputs to Scripts:
arguments(array of strings, optional):For
script_path: Passed as standard arguments to the script'son run argv(AppleScript) orrun(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'sargumentsPromptfromget_scripting_tips.
input_data(JSON object, optional):Primarily for
kb_script_idscripts designed to accept named, structured inputs.Values from this object replace placeholders in the script (e.g.,
--MCP_INPUT:yourKeyName). SeeargumentsPromptfromget_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'): Controlsosascriptoutput formatting flags.'auto': (Default) Uses human-readable for AppleScript (-s h), and direct output (no-sflags) 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-sflags are used (recommended for JXA, also the behavior for JXA inautomode).
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 howinput_dataandargumentsare 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): Iftrue, 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 outputisError: (boolean, optional) Set totruewhen 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:
osascripterrors will be returned in thestderror 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_pathis 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_modeis set to'direct'or'auto'(default). Using AppleScript-specific formatting flags likehuman_readablewith JXA can cause errors. If AppleScript output is not parsing correctly, trystructured_output_and_errororstructured_error.
Configuration via Environment Variables
LOG_LEVEL: Set the logging level for the server.Values:
DEBUG,INFO,WARN,ERRORExample:
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 toget_scripting_tipsor when akb_script_idis used inexecute_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.shor similar):KB_PARSING=eager ./start.shExample (when configuring via an MCP runner that supports
env, likemcp-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
.mdtip files or_shared_handlers(e.g.,.applescriptor.jsfiles).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_handlersdirectory 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.mdin 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 toolsexecute_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. Useget_scripting_tipsto find IDs and inputs. Supports placeholder substitution viainput_dataorarguments. 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): Forkb_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): Forscript_path(passes toon run argv/run(argv)). Forkb_script_id, used for positional args (e.g.,--MCP_ARG_1).
3. Execution Options (Optional):
language('applescript' | 'javascript'): Specify forscript_content/script_path(default: 'applescript'). Inferred forkb_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'): Controlsosascriptoutput formatting.'auto': Smart default - resolves to'human_readable'for AppleScript and'direct'for JXA.'human_readable': For AppleScript, uses-s hflag.'structured_error': For AppleScript, uses-s sflag (structured errors).'structured_output_and_error': For AppleScript, uses-s ssflag (structured output & errors).'direct': No special output flags (recommended for JXA).
include_executed_script_in_output(boolean, optional, default: false): Iftrue, 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): Forkb_script_id, includes detailed placeholder substitution logs.report_execution_time(boolean, optional, default: false): Iftrue, an additional message with the formatted script execution time will be included in the response. Defaults to false.
| Name | Required | Description | Default |
|---|---|---|---|
| script_content | No | ||
| script_path | No | ||
| kb_script_id | No | ||
| language | No | ||
| arguments | No | ||
| input_data | No | ||
| timeout_seconds | No | ||
| include_executed_script_in_output | No | ||
| include_substitution_logs | No | ||
| report_execution_time | No | ||
| output_format_mode | No |
TDQS
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.
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.
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.
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.
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.
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_termor browsing a specificcategory(withoutlist_categories: true). Does not apply iflist_categoriesis true.
Browsing by Category (Use
category):Parameter:
category(string, optional).Functionality: Shows tips from a specific category. Combine with
limitto control result count.Example:
category: "01_intro"orcategory: "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:
Always start with search: Use natural language queries to find solutions (e.g., "send email from Mail app").
Browse categories when exploring: Use
list_categories: trueto see available automation areas.Use specific IDs for execution: Once you find a script, use its ID with
execute_scripttool for precise execution.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | ||
| search_term | No | ||
| list_categories | No | ||
| refresh_database | No | ||
| limit | No |
TDQS
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
MCP connector that lets ChatGPT list, search, and run your Apple Shortcuts via a local Mac agent
Related MCP Servers
- AlicenseAqualityFmaintenanceA Model Context Protocol server that enables running AppleScript code to interact with Mac applications and system features including Notes, Calendar, Contacts, Messages, file management, and more.1123463MIT
- AlicenseAqualityAmaintenanceProvides 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.21,294874MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables AI assistants to control Apple Keynote presentations through AppleScript automation, supporting comprehensive slide creation, management, and content operations.74MIT
- AlicenseBqualityDmaintenanceA Model Context Protocol server that enables direct integration with macOS Calendar application using AppleScript, allowing users to create, list, and search calendar events without requiring OAuth setup.86MIT
Appeared in Searches
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/SuperCrazyKaizen/macos-automator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server