MCP Scheduling Server Tutorial: Design Tools That Finish Group Meetings

Build the MCP scheduling server in eight boundaries

Expose a small command surface around one durable meeting request. Do not make the model chain provider CRUD tools while carrying the meeting state in chat. Every tool call should validate policy, persist its result, and return structured state that another worker can resume.

1. 1

   Define the meeting-intent schema before the tools

   Create a typed record with meeting_request_id, organizer, purpose, duration, date window, booking deadline, meeting time zone, working-hour rules, preferences, exclusions, location, approval mode, and revision. Put people into separate required_participants and optional_participants arrays. Add approved outreach channels and consent references before the server contacts anyone.
   • Reject a request with no organizer, duration, date window, or required participant.
   • Store IANA time-zone names; do not treat a fixed UTC offset as a permanent zone.
   • Keep the original instruction for audit while running the workflow from typed fields.
2. 2

   Expose commands, reads, and side effects as different tools

   Start with a narrow surface such as create_meeting_request, get_meeting_request, revise_meeting_request, approve_participant_outreach, approve_slot, and cancel_meeting_request. Reading state is not the same risk as emailing a participant or writing a calendar event. MCP lets servers publish JSON Schema inputs and optional output schemas; use both so clients can validate the contract.
   • Give every side-effect tool an explicit authorization or policy field.
   • Return structured content with state, revision, blocking reasons, and next actions.
   • Keep provider-specific calendar operations behind the server rather than exposing them as the meeting model.
3. 3

   Resolve consent and connected free/busy per person

   For each participant, record whether the server may read connected Google or Microsoft free/busy, request availability conversationally, or must stop for human approval. Google exposes a free/busy query; Microsoft Graph exposes getSchedule. Normalize both into busy intervals with participant ID, provider, source account, retrieval time, and error state. A partial response is missing evidence, not an open calendar.
   • Ask for the smallest calendar permission that supports the action.
   • Keep event titles, descriptions, locations, and attendee lists out of model context.
   • Separate permission denial, expired access, throttling, and provider failure.
4. 4

   Make participant outreach and no-sync fallback resumable

   Calendar connection is optional. When a required person is not connected, the server should create an outreach task that names the organizer, meeting purpose, duration, date window, response deadline, and time zone. Parse the reply into the same availability shape as provider free/busy. If the response says ‘Tuesday afternoon’ without a zone, return needs_participant_clarification and ask one narrow follow-up.
   • Require an approved channel and an organizer-authority record before outreach.
   • Cap reminders and preserve opt-out or decline state.
   • Do not silently demote a required person because they did not connect or reply.
5. 5

   Generate slots with deterministic quorum and time-zone rules

   Intersect every required participant first. Score surviving slots for optional attendance, organizer preferences, working hours, buffers, fairness across time zones, and deadline. Let the model explain a result, but do not let it override hard attendance or consent policy. Persist the availability snapshot and rejection reason behind every proposal.
   • A required participant remains a hard constraint until an authorized revision changes the brief.
   • A changed time zone invalidates affected proposals.
   • A no-overlap result names the smallest constraints an operator could change.
6. 6

   Put human control at the side-effect boundary

   The MCP specification says applications should make exposed tools clear and provide human control for tool invocations. For scheduling, approval policy can differ by action. Reads and slot generation may run automatically; external outreach, sensitive relationships, booking, rescheduling, and cancellation may require confirmation. The server must enforce that policy even if a client calls the tool directly.
   • Return <code>approval_required</code> as normal domain state, not a vague error.
   • Bind approvals to a meeting revision and an exact proposed action.
   • Expire approval when a required calendar or participant constraint changes.
7. 7

   Commit one event with idempotency and reconciliation

   Derive a booking key from meeting request, revision, and approved proposal. Re-check fresh free/busy, then write the organizer event once and persist provider identifiers before reporting success. A client retry, worker restart, or duplicate MCP call must return the prior result. If the provider times out after an uncertain write, query or reconcile before trying another insert.
   • One approved revision creates at most one canonical event.
   • Retries do not resend participant outreach or duplicate invitations.
   • A partial calendar write moves to a visible recovery state with a safe next action.
8. 8

   Return verified completion and meeting-level observability

   A successful tools/call response is not proof that the meeting is booked. Verify event ID, organizer calendar, start, end, time zone, required attendees, invitation dispatch, and current revision. Emit states such as collecting_availability, waiting_on_required_participant, candidate_ready, awaiting_approval, committing, confirmed, and needs_review.
   • Trace provider calls, participant messages, approvals, and commits by meeting request ID.
   • Return stable domain reason codes separately from JSON-RPC or transport errors.
   • Alert on stuck states, exhausted retries, and duplicate-commit attempts.

Choose the MCP boundary by the job it finishes

Tool count is a weak proxy. Compare the meeting state, cross-company reach, fallback, control, recovery, and completion contract behind the tools.