The Protocol War for AI Scheduling

This is not an abstract standards debate. The protocol that wins becomes the foundation for every AI-driven calendar interaction. It determines whether your AI assistant can schedule across organizational boundaries, whether agents from different vendors can negotiate with each other, and whether the scheduling layer is open or locked into a single ecosystem.

The contenders

iCal and CalDAV: the incumbents

iCal (.ics) has been the standard for calendar data exchange since 1998. CalDAV, built on top of WebDAV, is the protocol for syncing calendars between servers and clients. Every calendar app in existence speaks iCal. It is the most widely deployed calendar standard by a massive margin.

But iCal is a data format, not an interaction protocol. It describes events: start time, end time, location, attendees. It does not describe capabilities, preferences, or negotiation flows. You can publish an iCal feed and let someone read your calendar. You cannot use iCal to say "find me a 30-minute slot next week that avoids my focus time and matches this other person's availability."

CalDAV adds synchronization but not intelligence. It solves "keep these two calendars in sync," not "negotiate the best meeting time between two parties." For AI scheduling, iCal/CalDAV provides the data layer but cannot serve as the interaction protocol.

REST APIs: the workhorse

Google Calendar API, Microsoft Graph API, and every scheduling platform's API use REST. The developer defines endpoints, the client sends requests, the server returns responses. It is well-understood, well-tooled, and reliable.

For application-to-application scheduling, REST works. A CRM checking a user's calendar availability through Google Calendar API is a solved problem. The developer knows the endpoint, the authentication flow, the request format, and the response schema. They write the integration once and it works.

The limitation is agent compatibility. REST APIs require the developer to hardcode the workflow: "Call this endpoint, parse this response, then call that endpoint." An AI agent using REST needs explicit instructions for every step. There is no capability discovery. There is no dynamic composition. The agent cannot figure out what the scheduling system can do. Someone has to tell it, in advance, for every system it might interact with.

This creates the N-times-M problem. If 10 AI assistants need to interact with 10 scheduling platforms, that is 100 custom integrations. Each with its own auth flow, its own endpoint schema, its own error handling. This does not scale.

Function calling: the LLM-native approach

Function calling, as implemented by OpenAI, Anthropic, Google, and others, lets an LLM invoke defined functions during a conversation. You provide a schema describing available functions (like "check_availability" or "create_booking"), and the model decides when and how to call them based on the conversation context.

For single-system scheduling, this is elegant. An AI assistant embedded in a scheduling platform can use function calling to check availability, propose times, and create bookings. The functions are defined by the platform, the model reasons about when to call them, and the user gets a natural conversational scheduling experience.

The limitation is scope. Function calling works within one system's boundary. Your AI assistant can call your scheduling platform's functions. But it cannot call someone else's scheduling platform's functions unless that platform has been explicitly integrated and its function schemas have been provided. Cross-boundary scheduling, where your agent talks to someone else's agent on a different platform, is not what function calling was designed for.

MCP: the agent-native protocol

The Model Context Protocol was designed specifically for AI agents interacting with external tools and services. It provides three things that the other approaches lack:

Capability discovery. An agent connecting to an MCP-compatible scheduling server can discover what the server offers: available tools (check availability, create booking, reschedule), available resources (calendar data, preference profiles), and available prompts (scheduling templates). The agent does not need pre-programmed knowledge of the API. It discovers capabilities at runtime.

Standardized interaction. Every MCP server exposes tools through the same protocol. An agent that knows how to interact with one MCP scheduling server can interact with any MCP scheduling server. This solves the N-times-M problem: agents implement MCP once, scheduling platforms implement MCP once, and every combination works.

Multi-step reasoning. MCP supports contextual, stateful interactions where the agent can chain multiple tool calls with reasoning in between. Check availability, evaluate the results against preferences, propose a subset of slots, handle a counter-proposal, and confirm the booking. This is a natural workflow for scheduling negotiation and maps poorly onto stateless REST calls.

Why MCP wins for AI scheduling

The decisive factor is the cross-boundary use case. Scheduling is inherently a multi-party, multi-system problem. Your calendar is on Google. Your colleague's calendar is on Outlook. Your client uses a scheduling platform you have never heard of. An effective AI scheduling protocol must work across all of these without requiring bilateral integration agreements.

MCP is the only contender designed for this. iCal provides the data format but not the interaction protocol. REST provides the interaction pattern but not the discovery or standardization. Function calling provides the AI-native interface but not the cross-boundary capability.

The technical argument breaks down like this:

• Agent-to-agent negotiation requires a protocol both agents understand without pre-arrangement. MCP provides this. REST does not.
• Dynamic capability discovery is essential when agents encounter unfamiliar scheduling systems. MCP provides this. Function calling schemas must be pre-defined.
• Stateful multi-step workflows map naturally to scheduling negotiation. MCP supports this natively. REST requires the application layer to manage state.
• Preference-aware slot evaluation requires the agent to reason about results between steps. MCP's design accommodates this. iCal has no concept of preferences.

The layered architecture

The answer is not "MCP replaces everything." It is a layered architecture where each protocol handles what it does best:

Data layer: iCal/CalDAV. Calendar events are stored and synced using iCal format over CalDAV. This is proven, universal, and does not need replacing.

Application layer: REST APIs. Scheduling platforms expose REST APIs for application integrations. CRMs, websites, and mobile apps use REST to interact with the scheduling backend. This is the integration backbone.

Intelligence layer: Function calling. Within a single scheduling platform, AI features use function calling to let the embedded LLM interact with scheduling tools. This powers the conversational interface.

Agent layer: MCP. For cross-boundary, agent-to-agent interactions, MCP provides the standardized protocol. This is the MCP server layer that lets any agent interact with any scheduling system.

Each layer serves a different consumer. iCal serves calendar apps. REST serves developers. Function calling serves embedded AI. MCP serves autonomous agents. The protocol war is not about one winner replacing all others. It is about which protocol claims the agent layer, because that is where the future of scheduling lives.

The stakes

Whoever controls the protocol for AI scheduling controls the interface between humans and their calendars. Today, that interface is a GUI: you open Google Calendar and click on a time slot. Tomorrow, it is a conversation: you tell your agent what you need and it handles the rest.

The protocol that powers that conversation will shape how billions of meetings get scheduled. MCP is the strongest candidate because it was built for exactly this moment: AI agents that need to interact with the real world across organizational boundaries, with discovery, standardization, and multi-step reasoning baked into the protocol itself.

The protocol war is still early. But the architecture is clear, the trade-offs are understood, and the direction is set. Scheduling platforms that implement MCP now will be the ones AI agents can talk to. The ones that wait will be invisible to the agent layer entirely.