You Do Not Need an MCP Server for Every Mac App - Accessibility APIs as a Universal Interface
You Do Not Need an MCP Server for Every Mac App
The Model Context Protocol is great for connecting AI agents to external services. But when it comes to controlling native Mac apps, there is a simpler approach that most people overlook.
Instead of building a separate MCP server for Mail, another for Calendar, another for Finder, and another for every other app you want your agent to use - just use the macOS accessibility API. One interface, every app.
The MCP Per-App Problem
The typical setup for an AI agent that controls Mac apps looks like this:
- MCP server for browser automation
- MCP server for file system operations
- MCP server for email
- MCP server for calendar
- Custom MCP server for each additional app
Each one needs to be built, configured, maintained, and kept in sync. Managing 10+ MCP servers is genuinely painful. Configuration files, version mismatches, servers that crash silently.
The Accessibility API Alternative
Every well-built Mac app exposes its UI through the accessibility framework. This is the same interface that screen readers like VoiceOver use. It gives you:
- Read any element on screen - buttons, text fields, menus, labels
- Perform actions - click, type, select, scroll
- Navigate the UI hierarchy - find elements by role, label, or position
- Works across all apps - one API, not one-per-app
An AI agent that speaks the accessibility API can control Mail, Calendar, Finder, Safari, Terminal, Xcode, Slack, and any other app without a single line of app-specific integration code.
How to Explore It
The Accessibility Inspector is built into Xcode and most people do not even know it exists. Open it from Xcode > Open Developer Tool > Accessibility Inspector. Point it at any app and you can see the entire UI tree - every element, every label, every available action.
This is the best free macOS automation tool nobody talks about. Before building an MCP server for a specific app, open the Accessibility Inspector and see if the app already exposes everything you need through the accessibility tree. It usually does.
When You Still Need MCP
Accessibility APIs are for UI-level interaction. If you need:
- API-level data access (reading a database, querying an API)
- Background processing (running without a visible window)
- Cross-machine operations (controlling a remote server)
Then MCP is the right tool. The sweet spot is using accessibility APIs for local app control and MCP for everything else.
Fazm uses accessibility APIs as its primary interface for controlling macOS apps. Open source on GitHub. Discussed in r/ClaudeAI.