Install
$ agentstack add mcp-prithviseran-hunch-mcp ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ● Network access Used
- ● Filesystem access Used
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Hunch
Drive your Mac with any LLM: focus-free, in the background, over MCP.
Hunch is an MCP server that gives an LLM agent hands on your Mac: your installed apps, your logged-in sessions, your files, without taking over your screen. While you keep working in the foreground, an agent can read a background app's UI, click its buttons, drive Mail or Music by AppleScript, fill a web form, or move files. It works on real native apps, not just a browser.
> Works best with modern LLMs. Hunch ships a detailed playbook as MCP server instructions; > capable tool-using models (Claude Sonnet/Opus-class and up) follow it well. Smaller models may > pick clumsier paths (screenshots and keystrokes instead of tree reads and clicks).
The four layers
Hunch always prefers the most direct layer. It's faster, more reliable, and (except the last) never touches your screen:
| Layer | Tools | What it's for | |---|---|---| | OS-API | trash file_op open_file clipboard_* launch_app … | files, clipboard, app lifecycle, via direct API calls | | AppleScript | applescript | scriptable apps: Mail, Messages, Notes, Calendar, Music, Finder, Safari … | | Web / CDP | web_open web_snapshot web_act web_login … | any browser page or Electron app, driven in the background | | Accessibility | snapshot act | any native app's UI: read the tree, click/select/type by reference |
A gated last resort (screenshot + coordinate clicks/keystrokes) exists for apps whose accessibility tree is truly empty. It steals focus, so it asks you first.
How it works (no server, no cloud)
"MCP server" undersells how local this is. hunch serve is a plain Python process that your MCP host (Claude Desktop, Cursor, …) spawns as a child process and talks to over JSON-RPC on stdin/stdout (MCP's stdio transport). There is no HTTP endpoint, no port Hunch listens on, no daemon, and no telemetry. When your host quits, Hunch is gone.
The tools are direct macOS API calls in-process: the Accessibility framework via pyobjc, osascript for AppleScript, OS APIs for files/clipboard, and, for the web layer, a local WebSocket to Chrome's DevTools port on 127.0.0.1. The only thing that ever touches the network is Chrome itself, doing ordinary browsing. What the model sees is whatever the tools return through your host; nothing else leaves the machine.
Benchmarks
Hunch is measured against other macOS computer-use agents on a real, logged-in Mac in mac-agent-bench — same brain, different hands: identical claude -p per task, only the MCP adapter differs. It scores task success with programmatic checkers and disturbance: how much the agent hijacks your cursor and foreground while it works.
Across 5 complex multi-step tasks (n=3):
| Tool | Success | Cost | Disturbance (focus·cursor) | Timeouts | |---|---|---|---|---| | Hunch | 15/15 | $1.52 | 1·0 | 0 | | Peekaboo | 13/15 | $14.60 | 22·16 | 2 | | cua-driver | 15/15 | $17.70 | 22·0 | 0 |
Perfect reliability, ~10x cheaper, ~5–10x faster, and it essentially never touches your screen (0 cursor moves, 1 focus switch across 15 trials). Full methodology and per-task tables are in the benchmark repo.
Install
macOS 13+. From PyPI (the distribution is hunch-sdk; the import and CLI are hunch):
pipx install hunch-sdk # or: pip install hunch-sdk
pip install 'hunch-sdk[agent]' # + the optional LLM agent loop (both backends;
# [api] or [subscription] picks just one)
Or via Homebrew — best if you don't manage Python environments; it bundles an isolated Python at a stable path, which makes the macOS permission grants the most predictable:
brew install prithviseran/hunch/hunch
Then, one time:
hunch setup # walk the macOS permission grants
hunch doctor # verify every layer; fix anything it flags
hunch connect claude-desktop # or: claude-code, cursor
Restart your MCP host and ask it to "use hunch to …".
The permissions, honestly
macOS trust attaches to the app that runs the server, meaning your MCP host (Claude Desktop, Cursor, your terminal), not "hunch" itself. hunch setup walks you through it:
- Accessibility (required): lets Hunch read app UIs and click focus-free. Grant it to your MCP
host app in System Settings → Privacy & Security → Accessibility.
- Automation (per-app, automatic): the first time Hunch scripts an app, macOS shows a one-time
"allow control" prompt.
- Screen Recording (optional): only for the screenshot/vision fallback.
hunch doctor reports what's granted. Note: its Accessibility line reflects the terminal you ran it from; the server inherits the host's grant.
Python SDK (library use)
Hunch is also an importable library — the same focus-free primitives as the MCP tools, driven deterministically from your own Python (a cron job, a test harness, your own agent loop), no LLM required. The distribution is hunch-sdk; the import is hunch:
from hunch import Hunch
mac = Hunch() # your machine, your logged-in apps
print(mac.snapshot("Mail")) # accessibility tree, focus-free
mac.act([{"action": "click", "ref": "e12"}])
mac.web.open(url="https://github.com") # real persistent Chrome profile over CDP
print(mac.web.snapshot())
mac.files.trash(["~/Downloads/old.zip"]) # reversible delete, no Finder
mac.applescript('tell application "Music" to play')
Constructor knobs: app (initial snapshot target), confirm="dialog"|"off" (see below), check_permissions (Accessibility check up front), simultaneous (never touch the foreground/cursor/keyboard), cdp_port.
- Permissions: for library use it's whatever runs your script — your terminal or IDE — that
needs Accessibility (the MCP server instead uses the host app's grant). The constructor checks and raises AccessibilityNotGranted with instructions. screenshot() additionally needs Screen Recording.
- Safety gates default ON: the same one-click "Go ahead" dialogs and
~/.hunch/config.json
gates as the MCP server. Hunch(confirm="off") auto-approves for that instance only — for unattended scripts, with the same caveats as auto_approve_all.
- Errors: methods return status strings (check for
REFUSED); the SDK raises only
ApprovalDenied (user declined a dialog), AccessibilityNotGranted, WebNotOpen (.web before .web.open()), StaleRef (re-snapshot), and HunchError when a CDP browser can't be opened (web.restart() recovers a stale instance).
- Credentials:
mac.web.fill_login(service)/fill_secret(service, ref)type Keychain
values straight into the page and never return them; domain binding is enforced.
- Coexistence: the SDK and the MCP server share the CDP port (9337) and the persistent Hunch
browser profile — whichever opened it first is reused, but web.restart()/web.login() kill whatever holds the port.
Runnable scripts live in [examples/](examples/).
Agent loop (mac.agent)
The instance SDK gives you deterministic primitives. The agent loop puts an LLM in the driver's seat: you hand it a task in plain English and Claude drives the Mac through those same primitives — Scrapybara's act(), but on your machine with your logged-in apps. It's an optional extra (keeps the base install free of the model SDKs):
pip install 'hunch-sdk[agent]'
python -c 'import hunch; hunch.login()' # Claude subscription sign-in (browser OAuth) — no
# API key. Already signed into Claude Code? Skip it.
from hunch import Hunch
mac = Hunch()
result = mac.agent.run("reply to Sarah's latest email, but don't send it")
print(result.text) # Claude's final summary
print(result.turns, result.usage)
Signing in
Auth is an explicit, visible surface — nothing is scavenged silently. Two ways to run the loop:
| Backend | Sign in with | Cost | |---|---|---| | subscription | hunch.login() — the same browser OAuth Claude Code uses. Already signed into Claude Code on this Mac? You're done; Hunch reuses that. | your Claude plan (no per-token cost) | | api | export ANTHROPIC_API_KEY=sk-ant-... | metered API tokens |
You choose the backend where it suits your code — at construction, or per call:
mac = Hunch(agent_backend="subscription") # this instance's agent = subscription
mac.agent.run(task) # ...no per-call ceremony
mac.agent.run(other_task, backend="api") # per-call override still wins
The default backend="auto" picks by credentials, in a fixed documented order (API key → CLAUDE_CODE_OAUTH_TOKEN env → Claude Code sign-in → hunch.login(token=...) token) — inspect it any time with hunch.auth.status() or hunch doctor. With no credentials at all, run() raises a HunchError naming both fixes — it never guesses.
Auth is public Python API (there is no login CLI — the MCP server never needs one, and your app owns its own onboarding):
import hunch
st = hunch.auth.status() # AuthStatus: .source / .email / .plan / .subscription_ready
if not st.subscription_ready:
hunch.login() # browser OAuth; or hunch.login(token="sk-ant-oat-...") headless
hunch.logout() # removes what login() stored, and only that
- Watch it work with an
on_event(kind, data)callback —kindis one oftext(Claude's
reasoning), tool ({name, input}), tool_result (preview), done (final text), error.
- Continuation: follow-up
run()calls keep the conversation (Claude still knows which email
is Sarah's); mac.agent.reset() starts a fresh task.
- Mix layers freely: call
mac.snapshot(...)/mac.clipboard.get()deterministically around
mac.agent.run(...) — the thing a cloud sandbox can't do on your real machine.
- Knobs: `run(task, model=None, maxturns=40, effort=None, onevent=None,
systemsuffix="", backend=None) — model=None means claude-opus-4-8 on the api backend and your subscription's default model otherwise. AgentResult has text, turns, stopreason, usage, aborted`.
- Safety: the instance's gate config governs the loop. The default
confirm="dialog"pops a
real "Go ahead?" dialog before any focus-stealing or risky step — good when you're at the machine, but a gated action can stall an unattended run for the dialog's timeout. For cron jobs use Hunch(confirm="off") and accept the risk; Claude still asks you (via notify_user) before irreversible or outward actions like sending a message. A declined gate comes back to the model as a REFUSED result, so the loop adapts instead of crashing.
- Cost: on the subscription backend, runs draw on your Claude plan's usage limits — no
per-token bill. On the api backend each turn resends the tree-heavy history; prompt caching is on by default, so cached input is ~10× cheaper — but long autonomous runs still add up. max_turns caps it either way.
Other models: the agent loop is Claude-only, but the instance-SDK primitives are provider-agnostic — wire mac.snapshot() / mac.act() into your own OpenAI/Gemini/etc. agent loop as tools.
Building an app on Hunch
The SDK is developer-first: one uniform semantics, everything instance-owned, nothing ambient unless you opt in. The MCP server above is itself just the first app built on it — its "personal" behavior (the ~/.hunch/config.json policy, "Hunch"-branded dialogs, shared browser profile) is nothing but constructor arguments.
from hunch import Hunch, ConsentRequest, OAuthToken
mac = Hunch(
app_id="com.acme.mailbot", # pure namespacing — own Keychain slots, browser
# profile, and CDP port; never a behavior switch
app_name="Acme Mailbot", # what consent dialogs + notifications say
confirm=my_consent_callback, # ConsentRequest -> bool, rendered in YOUR UI
notify=my_toast_handler, # (message, title) -> your surface, not macOS banners
policy={"gates": {"shell": True}}, # instance-owned safety; the user's personal
# config can never disarm your app
auth=OAuthToken(token), # exactly the credential YOUR app manages —
# or "none" to forbid ambient pickup entirely
)
What this buys you:
- Coexistence — two apps with different
app_ids get disjoint Keychain services, credential
stores, browser profiles, and CDP ports. They can't read each other's logins, log each other out, or kill each other's browser sessions. Structurally, not by convention.
- Your brand, your UX — every dialog, refusal, and notification says your
app_name;
confirm= and notify= route consent and alerts through your app instead of osascript dialogs and macOS banners. A broken consent callback fails closed.
- Isolated safety posture — the machine's
hunch config(andHUNCH_NO_INTERNAL_GATE)
govern only the personal MCP server, never your instance.
- Explicit auth —
hunch.ApiKey(...)/hunch.OAuthToken(...)use exactly that credential
(reprs are redacted); auth="none" guarantees your app never silently rides on the end user's own Claude sign-in.
Programmatic credential management uses the same namespacing: hunch.creds.set_credential(name, user, pw, namespace=your_app_id) etc. A runnable walkthrough lives in [examples/embedded_app.py](examples/embedded_app.py).
Credentials: agents use them, never see them
hunch creds add github --domain github.com
hunch creds list
Values go straight into the macOS Keychain. An agent signs in by calling web_fill_login("github") with only the service name; Hunch reads the secret from the Keychain and types it into the page over CDP. The value never enters the model's context, its logs, or its provider's servers.
Domain binding: a credential added with --domain github.com will only ever be typed into github.com (and its subdomains). If a confused or prompt-injected agent lands on a look-alike page, the fill is refused. Bind every credential; blank (any-site) exists only for compatibility.
No stored credential? Agents fall back to web_login, which opens a tagged browser window where you sign in yourself; the session then persists in Hunch's dedicated browser profile.
Confirmation gates
Your MCP host's tool approvals are the primary permission layer. Hunch adds a content-aware second gate, a one-click macOS dialog, for the catastrophic cases:
| Gate | Fires on | |---|---| | gates.focus_steal | actions that take over your keyboard/cursor (key, click_xy, ref-less typing) | | gates.app_to_front | an app being brought to the front (a focus switch, even mid-fullscreen) | | gates.shell | AppleScript containing do shell script | | gates.destructive_applescript | delete / send / empty trash / shut down / … |
One approval covers its follow-through: clicking "Go ahead" (on request_focus, a gated act, or the app-to-front dialog) authorizes the switch it announced for ~15 s: no second dialog, and the focus-switch notification is suppressed. A switch is either asked about or announced, never both, and never silent (turn gates.app_to_front off and switches fall back to the notification).
All on by default. For the MCP server, hunch config show / hunch config set gates.shell off adjusts them; changes apply immediately, even to a running server. auto_approve_all disables everything and makes you confir
…
Source & license
This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: PrithviSeran
- Source: PrithviSeran/hunch-mcp
- License: Apache-2.0
- Homepage: https://www.tryhunch.ca
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.