The Screen Time Parental Control App Already On Your Mac. Plus The Tamper Audit Apple Left Out.

Because the SERP for 'screen time parental control app' treats the phrase as a shopping query: every top 10 result is a listicle selling Qustodio, Bark, Net Nanny, Mobicip, Norton Family, FamilyTime, or Canopy subscriptions. None of them tell you macOS already ships Screen Time under System Settings, and that pane already does the core work: app limits, downtime schedules, content and privacy restrictions, communication limits, and a four-digit passcode the child cannot remove. What Apple actually leaves out is auditability. Screen Time itself does not log when a toggle moves. A kid in the right Apple ID can reach into the pane, flip a toggle, and no notification goes out. This page is about closing that specific gap with the macos-use MCP server, which reads the same AX tree System Settings renders and prints a diff every time any AXCheckBox changes AXValue.

Sources/MCPServer/main.swift:843 reads `if change.attributeName == "text" || change.attributeName == "AXValue" {`. That one conditional is the whole audit primitive. Every modified element in the diff between two traversals is checked; any AXValue attribute transition gets formatted at main.swift:847 as `'<oldVal>' -> '<newVal>'` with each side truncated to 60 characters by the truncate helper at main.swift:898. Up to three such lines are appended under a `text_changes:` header at main.swift:855. A Screen Time AXCheckBox carries AXValue '1' when on and '0' when off. So when a child toggles 'Block at Downtime' off, the next refresh_traversal returns a text_changes line reading `'1' -> '0'`. Grep that across a day's worth of hourly snapshots and every tamper event has a timestamp.

Two tools, two cron lines. First, once, run macos-use_open_application_and_traverse with identifier='com.apple.systempreferences' and navigate to Screen Time. That captures a baseline traversal at /tmp/macos-use/<ts>_open.txt. Second, a cron job every N minutes runs macos-use_refresh_traversal with the System Settings PID. Each run writes a new <ts>_refresh.txt file into /tmp/macos-use/ and the server diffs it against the prior traversal internally. The diff summary is what produces the `text_changes:` lines. A simple shell cron: `* * * * * /path/to/mcp-client refresh-traversal --pid $(pgrep -f 'System Settings') >> ~/screen-time-audit.log`. Your audit log is now append-only. macOS' own Launch Agent plist works too if you want per-user scope.

Those apps run their own enforcement layer on top of the OS: a launchd helper that kills apps, a network filter that drops connections, a browser extension that blocks URLs. They duplicate what Screen Time already enforces through FamilyControls and nesessionmanager, then add their own reporting dashboard which ships your child's browsing history to a vendor cloud. macos-use does the opposite. It enforces nothing; Screen Time enforces. macos-use only reads the AX tree of the existing Screen Time pane and emits a local diff line when any AXCheckBox changes AXValue. No cloud, no second enforcement engine, no second subscription. The audit file lives in /tmp/macos-use/ on your machine. You can tail it, grep it, pipe it to a local Slack webhook, or just leave it.

Yes, because turning Screen Time off is itself an AXCheckBox transition inside the Screen Time pane. The top-of-pane 'Screen Time' toggle is [AXCheckBox (checkBox)] 'Screen Time' with AXValue '1' when on. If the child knows the passcode and turns it off, the next refresh_traversal produces `text_changes: 'Screen Time' '1' -> '0'` in the diff summary. If they turn it off without the passcode, macOS raises the AXSheet passcode modal instead, which findSheetBounds at main.swift:241-278 detects and appends `dialog: AXSheet detected (viewport scoped to sheet bounds)` to the summary. Either way there is a log line with a timestamp. You do not need to trust the child's report; you have the AX tree's report.

Accessibility only. Grant it once under System Settings > Privacy and Security > Accessibility pointing at the mcp-server-macos-use binary you built with `xcrun --toolchain com.apple.dt.toolchain.XcodeDefault swift build`. Accessibility is what lets AXUIElementCopyAttributeValue read the tree of another process. Screen Recording is optional and only needed for the PNG screenshot alongside each traversal; the audit itself is purely textual so you can deny it without breaking anything. Notably, you do not need Full Disk Access, you do not need MDM enrollment, and you do not need to sign the child into a separate managed Apple ID. The audit runs in the current user's session.

Given a baseline where Downtime > Scheduled is on, Content & Privacy Restrictions is on, and Communication Limits is on, here is one real refresh after a kid flips 'Scheduled' off: `summary: Refreshed PID 812 (System Settings). 541 elements, 128 visible.` then `text_changes:` then ` 'Scheduled' AXValue '1' -> '0'`. The 60-character truncation at main.swift:898 is why you get exactly that shape. If more than three attributes change in one refresh, you still get only three entries, so for high-change windows either shorten the cron interval or call refresh_traversal twice in a row to split the transitions across two summaries.

That is itself a catchable event. If System Settings is not running when refresh_traversal fires, the call returns an error pointing at the PID that no longer exists. Your cron can watch for that and restart the flow with open_application_and_traverse to re-activate System Settings. More importantly, Screen Time's enforcement does not depend on the pane being open; the pane is the settings UI, not the enforcement engine. So closing System Settings does nothing to the actual restrictions. What it does is pause the audit stream. If you care, run open_application_and_traverse on a schedule instead of refresh_traversal so the pane is force-activated every interval. Screen Time restrictions stay live while you are auditing.

Yes, the MCP server runs over stdio. You can SSH in, run the built binary locally on their machine, and have a scheduled Launch Agent write the audit file. The audit file is plain text, so `tail -f ~/screen-time-audit.log` over SSH shows you the live diff stream. You can also pipe the log into any notifier: a shell wrapper that greps for `text_changes:` and curls a Slack webhook on match gives you a push notification on your phone within seconds of a child flipping a toggle. Everything stays on the two machines you own. The third-party alternatives require the child's device to upload its browsing data to a vendor cloud, which is a much larger privacy trade than running a local stdio process.

Because 'screen time parental control app' is a keyword the content industry has owned since 2017. Every top result is a listicle that ranks by affiliate link inventory. MCP was published by Anthropic in late 2024; the whole idea of an AI agent driving a macOS System Settings pane through the accessibility tree to produce a tamper log is two years newer than the listicles that rank. The specific detail that macOS exposes every Screen Time toggle as an AXCheckBox with a public AXValue that a local process can read, and that one conditional at main.swift:843 turns that into a diff stream, is not on any SERP page because it is not what the content mills were optimizing for. This page targets that gap exactly.

That is a natural extension and the server supports it in the same process. Pipe the text_changes line into your script; if the line reads `'Scheduled' '1' -> '0'`, issue a click_and_traverse with element='Scheduled' role='AXCheckBox'. The toggle flips back to 1. The server re-traverses after the click, the new diff shows `'0' -> '1'`, and your audit log records both events. You now have an auto-heal loop where any kid-initiated disable is reverted within one cron interval. The enforcement is still Screen Time's; macos-use is still only reading and clicking. The scheduling layer outside the MCP is what makes the loop a loop.