Enables interaction with Apple applications like Apple Mail for sending emails, and provides access to Apple's automation technologies including AppleScript and Automator workflows.
Supports JavaScript for Automation (JXA), allowing execution of JavaScript code to control macOS applications and system features.
Allows control of macOS through AppleScript and JavaScript for Automation (JXA), enabling file organization, application control, email sending via Apple Mail, workflow automation, and system-level tasks like toggling dark mode or taking screenshots.
Available as an npm package for installation and distribution.
Click on "Deploy 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., "@automator-mcp compress all screenshots on my desktop from today"
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.
MCP (Model Context Protocol) server for macOS Automator - bringing AI-powered automation to your Mac!
🚨 BREAKING: AI CAN NOW CONTROL YOUR MAC! 🚨
This MCP server lets Claude (or any AI with MCP support) control your macOS:
📧 Send emails through Apple Mail
🗂️ Organize files intelligently
🖥️ Control applications natively
🔄 Automate workflows with AppleScript/JXA
👀 Visual automation - AI watches and learns from your screen
Yes, you read that right. AI can now send emails from your Mac!
Related MCP server: macos-mcp
AppleScript Execution - Run AppleScript directly from AI
JavaScript for Automation (JXA) - Modern JS automation support
Workflow Creation - Build Automator workflows programmatically
Quick Actions - Pre-built automations for common tasks
System Automation - Control macOS system features
npm install -g automator-mcpAdd to your Claude Desktop config:
{
"mcpServers": {
"automator": {
"command": "automator-mcp"
}
}
}Execute AppleScript code:
tell application "Finder"
display dialog "Hello from AI!"
end tellExecute JavaScript for Automation:
Application('Finder').displayDialog('Hello from AI!');Run predefined automations:
compress_images - Compress image files
convert_to_pdf - Convert files to PDF
resize_images - Resize images to specified dimensions
extract_text_from_pdf - Extract text from PDFs
combine_pdfs - Merge multiple PDFs
convert_video - Convert video formats
System-level tasks:
empty_trash - Empty the trash
toggle_dark_mode - Switch between light/dark mode
take_screenshot - Capture screen
get_system_info - Get system information
Create new Automator workflows with specified actions.
List available Automator actions by category.
Compress all screenshots from today:
Use quick_action with action "compress_images" and files from ~/Desktop/Screenshot*.pngToggle dark mode:
Use system_automation with task "toggle_dark_mode"Create a workflow to resize images:
Use create_workflow to make a new service that resizes selected images to 800x600Pull requests welcome! Let's make Mac automation amazing together.
MIT © Maciej Gad
Made with ❤️ by @Szowesgad & @giklaudiusz
Yes, this MCP was co-created by an AI (Klaudiusz) who can now send emails through your Mac. We live in the future! 🚀
Create a new Automator workflow file
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the workflow | |
| type | Yes | Type of Automator document | |
| actions | No | Array of action configurations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the creation action without mentioning side effects (e.g., overwriting existing files), required permissions, error conditions, or return behavior. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal (one sentence) with no extraneous information. It is concise, but it prioritizes brevity over completeness, omitting important usage context that could be added without significant length.
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 tool's complexity (creation with 3 parameters, no output schema), the description only covers the basic purpose. It lacks information about prerequisites, output behavior, error handling, and integration with sibling tools, making it insufficient for an agent to use the tool correctly without additional assumptions.
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?
Schema description coverage is 100%, so all parameters have baseline explanations. The tool description adds no additional meaning beyond what the schema already provides, resulting in a baseline score of 3.
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 verb 'Create' and resource 'Automator workflow file', making the purpose evident. However, it does not differentiate itself from sibling tools like 'quick_action' or 'run_applescript', which could confuse an AI agent selecting the appropriate tool.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context for preferred scenarios, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Automator actions
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by category (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It gives no information about side effects (e.g., read-only vs. mutating), performance, or return format, which is insufficient for an agent to assess impact.
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 a single, clear sentence with no wasted words. It could be slightly more informative without sacrificing conciseness, but 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and no annotations, the description should explain what information the list contains (e.g., action names, IDs, descriptions). It does not, leaving the agent uncertain about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter, so the schema already explains its meaning. The description adds no further semantic value, meeting the baseline of 3.
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 specifies the verb 'List' and the resource 'Automator actions', making the tool's purpose immediately obvious. It distinguishes from sibling tools like create_workflow or run_applescript which have different verbs.
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 does not provide any guidance on when to use this tool versus alternatives. No context about prerequisites, typical use cases, or when not to use it is given, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a predefined quick action
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Quick action to perform | |
| files | Yes | File paths to process | |
| options | No | Action-specific options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to indicate whether actions are destructive (e.g., overwrite files), require permissions, or have side effects like modifying input files. The description does not convey any safety information, which is critical for a tool with actions like 'compress_images' that likely alter files.
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 a single concise sentence with no wasted words. However, it may be too brief to be fully informative. It is front-loaded but sacrifices completeness for brevity.
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?
For a tool with 3 parameters (one nested object) and no output schema, the description is insufficient. It omits details about return values (e.g., success/failure), expected output files, or behavior for long-running actions like video conversion. The nested 'options' parameter suggests complexity that the description does not address.
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?
Schema documentation covers 100% of parameters with descriptions. The description adds no new meaning beyond the schema, which already explains each parameter. Baseline 3 is appropriate as the schema suffices.
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 'Run a predefined quick action' clearly states the tool's purpose of executing one of several fixed actions. It distinguishes from sibling tools like 'run_applescript' or 'create_workflow' which involve custom scripts or workflow creation. However, it does not list the specific actions available, leaving some ambiguity about the resource being used.
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 no guidance on when to use this tool versus siblings like 'list_actions' (to see available actions) or 'run_applescript' (for custom scripts). It lacks any context about prerequisites, when not to use it, or alternatives. The single sentence offers no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute AppleScript code on macOS
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | AppleScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose execution behavior (synchronous/asynchronous), error handling, security implications, or side effects. For a code execution tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no waste. It is appropriately sized for a simple tool with one parameter, though it could add a bit more context without becoming verbose.
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 of code execution and lack of output schema and annotations, the description is insufficient. It omits return values, error behavior, and security considerations, leaving the agent underinformed.
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?
Schema coverage is 100% and the parameter description 'AppleScript code to execute' already states the purpose. The tool description adds no additional semantic value beyond what the schema provides.
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 action ('Execute') and the resource ('AppleScript code on macOS'), distinguishing it from sibling tools like run_jxa, which runs JavaScript for Automation.
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?
No guidance on when to use AppleScript vs alternatives like run_jxa or system_automation. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript for Automation (JXA) code on macOS
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JXA JavaScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states execution without disclosing behavioral traits such as permissions, mutability, sandboxing, or return values. With no annotations, the agent lacks critical safety context.
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 a single, concise sentence with no extraneous words. It could benefit from a title, but structure is efficient for the simple tool.
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?
For a code execution tool with no output schema and no annotations, the description lacks information on return behavior, error handling, and system impact, making it incomplete for safe and effective use.
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?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter description, leaving syntax, length, or encoding details undocumented.
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 verb 'Execute', the resource 'JavaScript for Automation (JXA) code', and the platform 'macOS', distinguishing it from siblings like run_applescript.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for JXA code on macOS but does not compare with sibling tools or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform system-level automation tasks
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | System task to perform | |
| parameters | No | Task-specific parameters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details such as destructive effects, permissions, or side effects. For a tool with tasks like empty_trash, this is a critical gap.
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 short but overly generic; it does not earn its place by providing useful information. It could be more detailed without losing conciseness.
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 of the tool (8 enum tasks, a nested object parameter, no output schema), the description is completely inadequate. It fails to inform the agent about available tasks or how to use parameters.
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?
Schema coverage is 100%, so the description does not need to add much. However, it adds no extra meaning beyond the schema's brief descriptions for task and 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?
Description is vague: 'Perform system-level automation tasks' does not specify which tasks, and does not distinguish from sibling tools like quick_action or run_applescript. It lacks a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
create_workflowlist_actionsquick_actionrun_applescriptrun_jxasystem_automationScored across 6 tools
The tools have some clear distinctions, such as create_workflow vs. run_applescript, but there is notable overlap between quick_action, system_automation, and the execution tools (run_applescript, run_jxa). An agent might struggle to choose between quick_action and system_automation for general tasks, as their purposes are not sharply differentiated in the descriptions.
Most tools follow a consistent verb_noun pattern (e.g., create_workflow, list_actions, run_applescript), which aids readability. However, quick_action deviates slightly by using an adjective-noun format, breaking the pattern and causing minor inconsistency in the set.
With 6 tools, the server is well-scoped for automation tasks on macOS, covering workflow creation, action listing, and various execution methods. The count is appropriate, avoiding bloat while providing essential functionality for the domain without feeling thin or excessive.
The tools cover key areas like workflow creation and script execution, but there are notable gaps in the automation lifecycle. For example, there are no tools for managing or deleting workflows, updating actions, or handling errors, which could limit agent effectiveness in more complex automation scenarios.
MCP connector that lets ChatGPT list, search, and run your Apple Shortcuts via a local Mac agent
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
