MCP, A2A, and the Scheduling Layer
Two protocols are reshaping how AI agents interact with the world. MCP (Model Context Protocol) defines how an agent uses tools. A2A (Agent-to-Agent) defines how agents collaborate with each other. Both matter for scheduling. Neither is sufficient alone.
What each protocol does well
MCP is the tool layer. An agent connected to an MCP server can call find_free_slots, resolve_datetime, or book_slot the same way a program calls a function. The server exposes capabilities. The agent invokes them. This is the right model for operations where one agent controls the calendar: checking your own availability, booking a slot on your own calendar, expanding a recurring event rule.
MCP shines when the scheduling operation is unilateral — the agent has the credentials, has the context, and can act without negotiation. “Find me a free hour tomorrow” is pure MCP. The agent calls get_temporal_context, calls find_free_slots, and returns the result. No other agent involved.
A2A is the negotiation layer. When two agents need to coordinate — your scheduling agent and your counterpart’s scheduling agent — the interaction is a conversation, not a function call. Agent A proposes three times. Agent B checks its principal’s calendar and counter-proposes two alternatives. Agent A accepts one. Both agents book on their respective calendars.
A2A shines when the scheduling operation is bilateral. Neither agent has full information. Neither can unilaterally decide the outcome. The protocol provides the structure for this back-and-forth: task lifecycle, message passing, artifact exchange.
How scheduling operations map to protocols
Not every scheduling operation fits neatly into one protocol. Here’s how the five layers of scheduling tools distribute across MCP and A2A:
Layer 0 — Discovery (MCP-native): search_contacts and resolve_contact query your own contact database. Pure tool calls. No negotiation needed.
Layer 1 — Temporal Context (MCP-native): get_temporal_context, resolve_datetime, convert_timezone, compute_duration, adjust_timestamp. These are deterministic computations that run locally. They don’t touch a network.
Layer 2 — Calendar Operations (MCP-native): list_calendars, list_events, find_free_slots, expand_rrule, check_availability. These read from calendar providers using the agent’s own credentials. Unilateral operations.
Layer 3 — Availability (MCP + A2A boundary): get_availability can query your own calendars (MCP), but query_public_availability queries someone else’s published availability. This is where the protocols start to overlap — you’re accessing another party’s data, potentially through their agent.
Layer 4 — Booking (both protocols): book_slot writes to your own calendar (MCP). request_booking asks another party to hold a slot — this may go through A2A if they have an agent, or through a fallback channel if they don’t. compose_proposal generates the scheduling message itself.
The pattern: lower layers are pure MCP. Upper layers increasingly involve coordination with another party, where A2A becomes relevant.
Where gaps exist
Neither protocol fully addresses three scheduling-specific challenges.
The state problem
MCP is stateless by design. Each tool call is independent. But scheduling workflows are inherently stateful. Between “find free slots” and “book one of them,” the availability may have changed. Between “propose three times” and “receive a response,” hours may pass.
MCP handles this through the server maintaining state between calls — the shadow calendar, the lock manager, the credential store. The protocol is stateless; the server is not. This works for single-agent workflows but gets complicated when multiple agents interact with the same server.
A2A handles state through its task lifecycle (submitted, working, completed). But the mapping between A2A task states and calendar booking states (proposed, tentative, confirmed, cancelled) isn’t standardized. Each implementation defines its own.
The identity problem
When Agent A wants to schedule with Agent B, how does Agent A find Agent B? MCP doesn’t address agent discovery — it connects a known client to a known server. A2A’s Agent Card provides discovery metadata, but calendar-specific discovery (who controls this person’s schedule? what’s their availability endpoint?) isn’t part of the spec.
This is why contact resolution is a scheduling-layer concern, not a protocol concern. search_contacts and resolve_contact bridge the gap between “I want to schedule with [email protected]” and “here’s how to reach Alice’s scheduling agent — or, if she doesn’t have one, here’s what to do instead.”
The asymmetry problem
The biggest gap is what happens when one side has an agent and the other doesn’t. A2A assumes both parties are agents. MCP assumes the agent has direct access. But in practice, your AI scheduling agent often needs to coordinate with someone who uses a plain calendar app and checks email twice a day.
This asymmetry is the norm, not the exception. According to recent surveys, fewer than 15% of knowledge workers use any AI assistant for scheduling. That means 85% of scheduling counterparts are humans operating without agents.
The scheduling layer needs a fallback path. When A2A negotiation isn’t possible because the other party has no agent, the system needs to degrade gracefully — from real-time agent negotiation to asynchronous message-based coordination.
The bridge: compose_proposal
compose_proposal exists precisely for this asymmetry. It takes the output of the scheduling workflow — available times, participant context, meeting details — and produces a structured message that works regardless of the recipient’s setup:
{
"tool": "compose_proposal",
"input": {
"recipient": "[email protected]",
"slots": [
{ "start": "2026-03-17T14:00:00-04:00", "end": "2026-03-17T14:30:00-04:00" },
{ "start": "2026-03-18T10:00:00-04:00", "end": "2026-03-18T10:30:00-04:00" },
{ "start": "2026-03-19T15:00:00-04:00", "end": "2026-03-19T15:30:00-04:00" }
],
"subject": "Interview — Senior Engineer",
"message": "Here are three available times for your interview. Please let me know which works best."
}
}The proposal can be delivered through multiple channels:
- A2A: If Alice has a scheduling agent, the proposal becomes an A2A task. Her agent evaluates the slots against her calendar, responds with a selection, and both sides book atomically.
- Booking link: If Alice doesn’t have an agent but can click a link, the proposal includes a URL to a booking page showing the proposed slots with real-time availability.
- Email: If Alice is fully analog, the proposal renders as a formatted email with the times displayed in her timezone.
The scheduling infrastructure decides the delivery path based on what it knows about the recipient. The calling agent doesn’t need to care which path was taken — it gets back a confirmation or a counter-proposal either way.
Why scheduling infrastructure must be protocol-agnostic
Protocols evolve. Two years ago, MCP didn’t exist. A2A is months old. New protocols will emerge. Betting on one means rewriting when the landscape shifts.
Scheduling infrastructure sits below the protocol layer. The core operations — temporal computation, availability merging, conflict-free booking — don’t change when a new protocol arrives. What changes is the transport: how the tool call arrives, how the negotiation is structured, how the result is delivered.
Temporal Cortex supports MCP (stdio and HTTP transports) as the primary tool interface, REST for traditional integrations, a browser-accessible booking flow for human participants, and is designed to add A2A as the agent ecosystem matures. The scheduling logic is identical across all four. The protocol is just the envelope.
npx @temporal-cortex/cortex-mcpThe 18 tools work the same whether your agent reaches them via MCP, your API calls them via REST, or a future A2A peer invokes them through agent-to-agent negotiation. Protocols are how agents communicate. Scheduling is what they communicate about. Build on the scheduling layer, and the protocol can be whatever the ecosystem needs it to be.