MCP is excellent at giving agents present-tense tool access. But many useful assistant requests are future-tense: "when this happens, tell me" or "if this changes, start the workflow." Those requests should leave behind durable conditions that can be matched later, even after the chat turn and MCP tool call are gone.

Short answer

Key takeaways

MCP connects agents to tools, but future monitoring needs state that outlives a single tool call.
A durable watch should record intent, sources, evidence rules, delivery target, and permission scope.
MCP servers can expose "create watch" style tools without becoming full event infrastructure.
Webhooks, queues, and local pull delivery still matter after the MCP call succeeds.
Future conditions make proactive agents debuggable because users can inspect what the system is waiting for.

Present-tense tools, future-tense requests

The Model Context Protocol made a useful idea concrete: agents need a standard way to discover and call tools. Anthropic's launch post framed MCP as a way to connect AI assistants to data sources and systems: https://www.anthropic.com/news/model-context-protocol. OpenAI's Agents SDK also supports MCP servers as tool providers: https://openai.github.io/openai-agents-js/guides/mcp/.

That solves a lot of present-tense work. Search this repo. Read this doc. Fetch this calendar. Create this issue. Send this message.

But proactive assistance often starts with a different grammar:

"When a customer replies to this thread, wake me."
"If this build fails again on main, ask the coding agent to investigate."
"Tell me when Rahul moves the planning meeting."
"Watch for a vendor invoice above this threshold."

Those are not just tool calls. They are future conditions.

What should persist

When an agent uses an MCP server to set up a future condition, the important artifact is not the transcript. It is the watch.

A good watch stores at least six things.

First, the user's natural-language intent. This is the human-readable contract.

Second, the source streams that can satisfy the condition: Gmail, Calendar, GitHub, Slack, Linear, Stripe, or a custom webhook.

Third, the matching evidence. Which fields matter? Which phrases are strong signals? Which changes count? Which identities are in scope?

Fourth, the delivery target. Should the match wake a local agent, a cloud agent, a Slack channel, an email draft, or a Codex task?

Fifth, the permission envelope. A watch that wakes from an external webhook should not automatically inherit the same authority as a direct user prompt.

Sixth, expiry and audit state. Future conditions should be reviewable, pausable, and deletable.

That object gives the agent system memory without pretending the model itself is memory.

MCP can create watches

An MCP server does not need to become a scheduler, webhook router, queue, and delivery service. It can expose tools that create, inspect, and revoke watches.

For example, a calendar MCP server could let an agent create a watch for "executive customer meetings that move within 24 hours." The server or surrounding platform can translate that into calendar push notifications, delta sync, and match rules. A GitHub MCP server could create a watch for "failed CI on branches owned by this project." An email MCP server could create a watch for "vendor security questionnaire threads with new external replies."

The MCP call is the setup moment. The event layer is the waiting room.

This matches the direction of the broader ecosystem. There are community MCP cron and webhook projects such as https://github.com/jolks/mcp-cron and https://github.com/kevinwatt/mcp-webhook, and official product APIs already expose their own event mechanisms, including OpenAI webhooks: https://developers.openai.com/api/docs/guides/webhooks.

The important design move is to avoid making the language model wake up just to ask every tool whether anything changed.

Future conditions need evidence, not magic

If a future condition fires, the downstream agent should receive evidence:

the watch that matched;
the raw event or source reference;
the fields that triggered the match;
the confidence or rule path;
the allowed actions;
the acknowledgement deadline.

That keeps the next model turn focused. It also lets a user say, "this should not have matched because I only meant direct messages, not newsletters." The correction can update the watch instead of becoming another forgotten chat preference.

Security gets clearer too

MCP security conversations often focus on tool access, prompt injection, and data boundaries. Future conditions add another layer: source-triggered authority.

An agent directly asked by the user to send a message is in one trust state. An agent woken by a webhook from a third-party system is in another. An agent woken by an expired local heartbeat may need to verify freshness before doing anything irreversible.

Persisted watches make that distinction explicit. They let the system attach narrower permissions to wakeups than to direct user sessions.

FAQ

Should every MCP server implement scheduling?

No. Scheduling and delivery can live in a separate event layer. MCP servers only need useful tools for creating, listing, updating, and deleting future conditions when that fits their domain.

Is a future condition the same as a prompt?

No. A prompt is language for the current turn. A future condition is an operational object that can evaluate later events, preserve evidence, and wake the right destination.

Does this replace webhooks?

No. Webhooks and push notifications are source-change mechanisms. Future conditions explain which changes are relevant to the user and what should happen after a match.

MCP servers should leave future conditions behind