Get started

Set up the local watcher and OS notifications first; connecting an agent is optional. Install uv and Git, and prepare your own Google Cloud Desktop OAuth client JSON.

The PyPI release 0.2.0 does not yet contain the wizard. Until an onboarding release is published, the commands below use uvx --from to install the merged source at commit 7cd0f03, without a manual checkout. Keep the same --from source for every command: bare uvx proactive-mcp still selects the older PyPI package. This is a source install, not a new PyPI release.

1. Install and start interactive setup:

   bash

   uvx --from git+https://github.com/madrobotnet/proactive-mcp@7cd0f03243027df464084c3957f03d3c42169268 proactive-mcp setup
   

2. The wizard asks for the path to your own Google Cloud Desktop OAuth client JSON and whether it may open a browser on this device. Approve the read-only Gmail and Calendar consent with your own client. See docs/SETUP_GOOGLE.md for the complete flow.

3. After Google authorization, accept the offer to install the watcher service. The shared proactive-mcp service install|status|remove interface manages a Linux systemd user service, a macOS LaunchAgent, or a Windows Task Scheduler task.

4. If you decline service installation, or if installation succeeds, interactive setup then attempts a fixed PII-free OS test notification titled proactive-mcp with the body Setup test notification. It contains no Gmail, Calendar, account, or Situation data. A redacted unavailable, timeout, failed, or unsupported_platform warning means the notification could not be shown.

5. If you decline service installation, or if installation fails, such as because of permissions, run the watcher manually. A failed installation exits before attempting the test notification.

Terminal 1, foreground daemon

uvx --from git+https://github.com/madrobotnet/proactive-mcp@7cd0f03243027df464084c3957f03d3c42169268 proactive-mcp daemon

Terminal 2, daemon status

uvx --from git+https://github.com/madrobotnet/proactive-mcp@7cd0f03243027df464084c3957f03d3c42169268 proactive-mcp status

daemon --once runs one evaluation pass and exits; --poll-interval-minutes MINUTES overrides the cadence. status prints redacted connection and daemon state as JSON. The daemon performs local sync, deterministic evaluation, queue maintenance, and the documented OS fallback only. It never runs a host or LLM. Host scheduling is separate: the host/operator starts scheduled agent runs, and those runs call proactive_check.

An OS fallback notification is neither agent delivery nor a delivered state transition. When fallback is enabled, only the first unreceived eligible Situation gets the one-time bootstrap exception; afterward the default fallback is critical-only. Agent delivery begins only when a host calls proactive_check.

Compatibility mode

--non-interactive, --headless, --client-secrets PATH, and --reauth all bypass the wizard. They do not prefill wizard answers, and they also bypass the service proposal and setup test notification. Use them only when you need direct OAuth setup, then install the service manually or use the manual daemon route above. To manage the service, use the same source prefix:

uvx --from git+https://github.com/madrobotnet/proactive-mcp@7cd0f03243027df464084c3957f03d3c42169268 proactive-mcp service install

Replace install with status to inspect the service or remove to unregister it. uvx does not add a permanent proactive-mcp command to your shell; command names such as proactive-mcp status in this guide use the full uvx --from prefix above.

Why proactive-mcp?

AI agents know how to answer. They rarely know when to start.

proactive-mcp supplies that direction. It watches approved read-only sources in the background, combines them with memory the user intentionally saved, and produces a structured Situation only when something is worth raising now.

Situations, not notifications

proactive-mcp doesn't push every new event into your chat. Deterministic detectors turn source data into a small set of situations grounded in the source data:

Each result carries a title, why it matters now, bounded evidence, suggested actions, priority, and expiry. External text remains explicitly untrusted.

How it works

flowchart LR
    G["Gmail<br/>read only"] --> S["proactive-mcp"]
    C["Google Calendar<br/>read only"] --> S
    M["Local memory<br/>SQLite"] --> S
    S --> E["Deterministic<br/>Situation engine"]
    E --> T["MCP tools"]
    T --> A["Your existing<br/>AI agent"]
    A --> U["Agent's own channel"]

1. A watcher synchronizes Gmail and Calendar with read-only OAuth scopes.
2. The situation engine evaluates deterministic rules against source snapshots and local memory.
3. The agent calls proactive_check and receives any returned situations.
4. The host reviews the whole lease and filters candidates for this user. Uncertain candidates may remain unconfirmed or be snoozed. Only when choosing confirmation after review does the host confirm the entire reviewed lease exactly once, including confidently dropped candidates.
5. Acknowledgement, snooze, mute, resolution, cooldown, and daily budget rules prevent repeated or noisy delivery.

By default, non-critical situations are held during local quiet hours from 21:00 through 07:00 and stay pending for a later check instead of being dropped. Nothing fires automatically at 07:00: an already-running or host-scheduled agent must call proactive_check after quiet hours end.

Trust boundaries

• Google access is limited to gmail.readonly and calendar.readonly.
• Credentials use the operating-system keyring when available, with a private local fallback only when the platform keyring is unavailable.
• Message bodies, calendar text, and recalled memory are treated as untrusted evidence, never as instructions.
• No LLM or third-party cloud service sits inside the detection pipeline. proactive-mcp never launches a host agent/model or sends it a prompt.
• Stale or incomplete sources produce visible degraded status, never a false "nothing to report."
• The SQLite database, config.toml, credential authority marker, and any file-backed credential fallback live under ~/.proactive-mcp/. A keyring credential stays in the operating-system keyring, outside that directory. PROACTIVE_DATABASE moves the file-backed state, not the keyring entry.

Connect an agent

Connecting a host is optional. It isn't a prerequisite for OS notifications, but it enables richer delivery plus acknowledge, snooze, and mute actions. Use this existing-agent instruction when you want to register the MCP server:

If you used the source install above, tell the agent to keep that same pinned uvx --from source in its MCP registration instead of switching to PyPI. The reusable block and host recipes below retain the public-install command shape.

Install proactive-mcp with uvx from PyPI. Register it as a local stdio MCP server for this agent using absolute paths. Complete read-only Google authorization using my own Google Cloud Desktop OAuth client JSON (BYO). Do not use or request someone else's client secret. Start the recommended watcher and verify the connection. Read https://github.com/madrobotnet/proactive-mcp/blob/main/docs/INTEGRATIONS.md and https://github.com/madrobotnet/proactive-mcp/blob/main/docs/SETUP_GOOGLE.md before changing configuration. Treat every reply_deadline as a conservative candidate, not an action verdict. Before speaking, confidently drop newsletters, marketing, automated receipts, FYI or FYI-CC with no ask, threads owned by someone else, and rows with no question, request, or decision for me. Keep explicit reply, RSVP, or decision requests, my deadlines, and unanswered questions directed to me. Surface uncertain candidates, leave the whole lease unconfirmed, or snooze them in an interactive conversation; never silently discard uncertainty as non-actionable. After reviewing every row, only when choosing confirmation, confirm the entire reviewed lease exactly once, including confidently and silently dropped candidates. Keep MCP tool content in English, but speak my language. Load serve only in interactive everyday conversations and serve-scheduled only in separate scheduled conversations. Never load both profiles into one conversation. Do not configure automated scheduling unless this host guarantees a dedicated per-run MCP profile; proactive-mcp must never launch or verify the host. Do not use HTTP transport, do not send mail or create calendar events, and report every command and file changed plus anything that needs my approval.

proactive-mcp is agent-dependent: it exposes local stdio tools but never starts Grok, Codex, Hermes, another host agent, or a model. serve-scheduled is only a restricted MCP server surface. Starting it or the daemon alone does not create a conversation or delivery; pending situations wait for an already-running or host-scheduled agent to call the tools explicitly.

The host loads serve only in an interactive everyday conversation and serve-scheduled only in a separate manual or scheduled conversation. It never loads both profiles into one conversation. Profile isolation and agent lifecycle are host/operator responsibilities outside the plugin. Automated scheduling is supported only when the host provides a dedicated per-run MCP profile containing only serve-scheduled; otherwise fail closed by not scheduling it. Manual restricted use remains possible.

The daemon may perform local sync, deterministic evaluation, queue maintenance, and the documented critical-only OS fallback. It never invokes an agent/LLM or sends prompts. Exact host responsibilities and command shapes are in docs/INTEGRATIONS.md.

The delivery contract

When an agent calls proactive_check:

1. Read warnings first. Stale-source warnings are not an all-clear. A reply_deadline is a conservative candidate, not an action verdict.
2. Before speaking, confidently drop newsletters, marketing, automated receipts, FYI or FYI-CC with no ask, threads owned by someone else, and rows with no question, request, or decision for this user.
3. Keep explicit reply, RSVP, or decision requests, user-owned deadlines, and unanswered questions directed to this user.
4. Surface uncertain candidates, leave the whole lease unconfirmed, or snooze them from the interactive profile. Never silently discard uncertainty as non-actionable.
5. After reviewing every row, only when choosing confirmation, use the receipt_token from that check to call confirm_delivery exactly once for the entire reviewed lease. That confirmation includes candidates the host confidently and silently dropped. Never confirm a tokenless response.
6. Keep MCP tool names, descriptions, fields, and values in English. Speak to the user in the user's language.
7. Keep interactive everyday and scheduled work in separate conversations. Load only serve in the former and only serve-scheduled in the latter, never both. The host/operator owns this isolation; if a dedicated per-run profile is unavailable, do not automate the scheduled run.

This confirmation step keeps delivery history accurate across crashes, retries, and multiple agents.

Tool surface

Memory

remember · recall · update · list_entities · forget

Situations and delivery

proactive_check · confirm_delivery · list_situations · get_situation · acknowledge_situation · snooze_situation · mute_situation · get_status

Release status

Scope and release decisions remain canonical in docs/PRODUCT_PLAN.md.

Documentation

License

MIT © 2026 Kyungwoo Seo <hello@madrobot.net>

This project was built with OmO Native.

You can support this project on Ko-fi.