How to add Screen Mirroring to Control Center, and the one function that lets an AI do it without scrolling by hand

On macOS Sonoma and Sequoia, the Screen Mirroring tile is already in Control Center by default. The thing people usually mean when they type 'how to add Screen Mirror to Control Center' is either (a) making the Screen Mirroring icon show up in the menu bar as its own icon (System Settings, Control Center, scroll to Screen Mirroring, set Show in Menu Bar to Always or When Active), or (b) adding a specific Control Center module they removed in the past. Both paths live in the same pane of System Settings. The interesting part of this page is that the Screen Mirroring row in that pane is below the fold on any 13-inch MacBook at the default System Settings window size, which means a naive accessibility-driven click at raw AX coordinates would post a click below the visible window and hit nothing.

The AX tree at Sources/MCPServer/main.swift traverses every descendant of the window via AXUIElementCopyAttributeValue, so it happily returns rows that are logically in the document but visually below the scroll viewport. The position is real; the pixel is just not painted. Posting a CGEvent mouseDown at that coordinate lands on the area below the window frame. The fix at main.swift:1151-1285 is to detect the off-viewport condition (windowBounds.contains(point) returns false at main.swift:1168) and scroll the containing window incrementally until the target element's text reappears inside the viewport. The function returns the element's actual painted center, which is then fed to the click post at main.swift:1588-1594.

On a default 13-inch MacBook (1440x900 logical points) with System Settings opened at its default size and Control Center selected in the sidebar, the Screen Mirroring row sits roughly 520 logical points below the viewport after the Wi-Fi, Bluetooth, AirDrop, Focus, Stage Manager, and Screen Mirroring labels are accounted for. scrollIntoViewIfNeeded classifies that as distance > 250 and picks linesPerStep = 3 at main.swift:1187, which at roughly 20-40 pixels per line (the doc comment at main.swift:1186) resolves in 5 to 9 scroll steps. The hard cap is 30 steps at main.swift:1189. If it takes more than that, the function gives up and returns the original point, which then fails at the click layer with a visible error instead of a silent miss.

That is the case-2 branch at main.swift:1220-1284. Instead of searching the tree for the target by string match, the function scrolls one step at a time and probes a point 60 logical points inside the viewport edge (probeY at main.swift:1231-1233). Each time an AX element with a non-empty text attribute appears at the probe position, the function logs 'edge element after N steps' and records its text. The step counter continues up to 30 steps. When the original target point finally comes back into range (main.swift:1254), the function switches to text-based tracking, scrolls up to 8 more nudge steps (main.swift:1264), and returns the element's painted center. This matters for Control Center-style panes because the 'Show in Menu Bar' popup buttons sometimes have no associated text until you hover.

Yes. Clone the repo, run xcrun --toolchain com.apple.dt.toolchain.XcodeDefault swift build -c release, grant Accessibility permission to .build/release/mcp-server-macos-use in System Settings, Privacy and Security, Accessibility, then add the binary to claude_desktop_config.json under mcpServers. Restart Claude Desktop. Type the prompt: 'Open System Settings, go to Control Center, and set Screen Mirroring to Always Show in Menu Bar.' Watch the MCP log viewer. You will see the click_and_traverse tool call, followed by the 'log: scrollIntoViewIfNeeded' stderr lines as the server scrolls the Control Center pane. The final click lands on the visible row. No manual scrolling from you.

AXUIElement frames are read-only for position and size through AXUIElementCopyAttributeValue. You can read AXPosition (getAXElementFrame at main.swift:1113-1122) but you cannot write it on an arbitrary window that you do not own. The only supported way to bring an off-viewport element into the visible rectangle is to scroll its parent scroll container. That is why the function uses CGEvent scrollWheelEvent2Source at main.swift:1196, which posts a real scroll event to cghidEventTap the same way a trackpad two-finger drag would. The AX tree is for reading; input is how you change the viewport.

The re-check after every step at main.swift:1208: findElementByText searches the AX tree for the original target text, and if the element's center lands inside windowBounds.insetBy(dx: 0, dy: 15) (main.swift:1128), the function returns that center immediately. The 15-point vertical inset guarantees the element is not clipped at the very top or bottom edge. The worst-case overshoot is one scroll line, roughly 20 to 40 pixels, and the next iteration's findElementByText would still match because the row remains in the tree.

Two other common approaches: (1) use the defaults write com.apple.controlcenter shell command to flip a preference key, or (2) AppleScript the menu bar extra item through System Events. The defaults approach only works for a small set of pre-defined keys, not every Control Center module, and requires a cfprefsd reload or a logout/login to take effect. AppleScript on macOS 15 Sequoia hits the TCC prompts every time and is brittle because Apple renames the menu extra item identifiers across minor versions. The accessibility-driven path in this MCP server works for every row in System Settings, Control Center because it just clicks the same UI a human would. scrollIntoViewIfNeeded is why that click lands on the right pixel.

scrollIntoViewIfNeeded reads the window bounds fresh at the start of the call (main.swift:1163) via getWindowContainingPoint. If the user resizes the window between the AX traversal and the click, the next call to click_and_traverse will pull a fresh traversal with the new bounds. The function does not cache the viewport between calls; every click revalidates. That is also why the server sets AXUIElementSetMessagingTimeout to 5.0 seconds at main.swift:1161, so a slow or unresponsive System Settings does not stall the scroll indefinitely.

The server logs to stderr in front of every scroll step. The key lines are 'log: scrollIntoViewIfNeeded: target text="..." distance=Npx, lines/step=N' at main.swift:1193 and 'log: scrollIntoViewIfNeeded: found "..." at (x,y) after N steps' at main.swift:1209. Pipe stderr somewhere visible (Claude Desktop's MCP log viewer, or an xterm if you run the server by hand) and you will see the exact step count, the element's text, and its final viewport-local coordinate. If the counter hits 30 and returns the original point, the click will log an error and the MCP response will tell the model the selector did not land.

Functionally identical. The function posts the same .line-unit scroll wheel events a trackpad would post. The difference is consistency: a human stops scrolling when their eye tracks the row into view, and may overshoot or undershoot. The auto-scroll stops exactly when findElementByText confirms the element's center is within the inset viewport, so the next click targets the actual painted center rather than somewhere nearby. This is how a Claude Desktop prompt can reliably land on a 28-point-tall System Settings row that sits 520 points below the initial viewport, every time.