Google Calendar MCP Randevu Asistanı OAuth Geçişi Nasıl Planlanır?

Calendar MCP kullanan randevu asistanı neyi değiştirmeli?

Google Calendar MCP sunucusunu çağıran bir yapay zekâ randevu asistanı, OAuth istemcisinin AI destekli ajan olarak işaretlenmesini kontrol etmelidir. Google’ın 12 Ekim 2026 sürüm notu, 11 Kasım 2026’dan başlayarak uygun işaret taşımayan istemcilerin Workspace MCP sunucularına yaptığı isteklerin reddedileceğini bildirir. Yalnızca klasik Calendar REST API çağıran randevu entegrasyonları bu değişiklikten etkilenmez. Önce sistemin hangi arayüzü kullandığını belirlemek, gereksiz istemci değişikliklerini önler.

Bu yazı, bir restorana, kliniğe veya hizmet ekibine randevu alan MCP tabanlı pilot asistanın erişim planını anlatır. Calendar MCP hâlen Google Workspace Developer Preview kapsamındadır; tüm işletmelerde hazır ve genel kullanıma açık bir özellik gibi sunulmamalıdır. İşletme önce gerçek ihtiyacını tanımlar: asistan takvimi yalnızca okuyacak mı, uygun zaman önerecek mi, kullanıcı onayıyla etkinlik oluşturacak mı? Erişim izni ve hata akışı bu yanıtlarla şekillenir.

Önce kullanılan entegrasyonu sınıflandırın

Bir randevu sisteminin Google Calendar ile konuşması, onun MCP kullandığı anlamına gelmez. Kod doğrudan Calendar REST uç noktalarına gidiyorsa bu 2026 OAuth işaretleme duyurusu o çağrılar için uygulanmaz. Uygulama Google’ın uzaktaki Calendar MCP sunucusuna bağlanan bir yapay zekâ istemcisi kullanıyorsa işaretleme önemlidir. Aynı OAuth istemcisi hem REST hem MCP işlevleri için kullanılıyorsa Google, ajan için ayrı istemci oluşturup REST tarafındaki mevcut istemciyi ayırmayı önerir.

Teknik envantere OAuth istemci kimliğinin kendisini rapora dökmek gerekmez. Hangi Google Cloud projesinde tutulduğu, hangi ortamda kullanıldığı, hangi uygulama bileşeninin onu çağırdığı ve hangi kapsamlarla yetkilendirildiği yeterli başlangıçtır. Gizli anahtarları, yenileme belirteçlerini veya müşteri takvim ayrıntılarını dokümana koymayın. Üretim ve test ortamı farklı istemciler kullanıyorsa her birini ayrı satırda değerlendirin.

11 Kasım geçişinde hangi kararlar var?

Google sürüm notunda, işaretlenmemiş mevcut istemcilerin belirlenen tarihten sonra MCP isteği yapamayacağı ve gerektiğinde yeni, ajan olarak işaretlenmiş istemciyle uygulamanın güncellenmesi gerektiği anlatılır. Ayarın mevcut istemci üzerinde değiştirilemediği durumda eski kimliği zorla yeniden kullanmaya çalışmak yerine yeni istemci için geçiş planı yapın. Eski istemcinin hangi randevu akışlarını taşıdığını, yeniden yetkilendirme gerekip gerekmediğini ve geri dönüş seçeneğini önceden belirleyin.

Google Workspace MCP kurulum belgesi, yeni OAuth istemcisi oluşturulurken “Use this client for an AI-powered agent” seçeneğini ve Calendar için ayrı MCP sunucu adresini gösterir. Aynı belgede geliştirici ön izleme programı üyeliği ve Google Cloud projesi ön koşul olarak yer alır. Kurulum ekranının varlığı tek başına erişim hakkı sağladığı anlamına gelmez; kendi kuruluşunuzun ön izleme durumunu ve yetkisini kontrol edin.

İstemci değişikliğinden önce ilgili kullanıcıların onay akışını düşünün. Çalışanın veya müşterinin takvimine erişim gerekiyorsa OAuth kapsamı yalnızca gereken işlemleri kapsamalı. Randevu oluşturma yetkisi ile takvimi okuma yetkisi aynı ihtiyaç değildir. Asistanın önerdiği zamanı doğrudan kaydetmek yerine kullanıcıya ve görevli ekibe net onay adımı göstermek, çift randevu ve yanlış takvim riskini azaltabilir.

İzin sınırı ve denetim nasıl kurulur?

Google Workspace MCP belgeleri ajanların Workspace verisine kullanıcının izinleri kapsamında eriştiğini söyler. Bu yüzden “MCP bağladık, bütün ekip takvimini görebilir” varsayımı yanlıştır. Randevu asistanının hangi takvimi okuyacağı, hangi takvime yazacağı ve özel etkinlik ayrıntılarını görüp görmeyeceği proje kabul belgesinde ayrı satırlar olmalıdır. Kurum yöneticisinin verdiği uygulama izni ile tek kullanıcının takvim yetkisi de karıştırılmamalıdır.

Test için gerçek hasta veya müşteri bilgisi yerine örnek etkinlikler kullanın. İki çalışanın takviminde aynı saati, iptal edilmiş bir etkinliği, saat dilimi değişikliğini ve erişim verilmemiş takvimi deneyin. Asistan bir eylem önerdiğinde hangi veriye dayanarak önerdiği anlaşılır olmalı. Takvim verisi güncel değilse “müsait” iddiasını kesin sonuç gibi göstermeyin; randevu kaydı öncesi yeniden uygunluk kontrolü yapın.

İşlem günlüklerinde soru metninin tamamını tutmak yerine istek türü, izin verilen takvim, sonuç sınıfı ve hata kodu gibi sınırlı bilgiler kullanın. Bir erişim hatası, takvimde boş yer kalmaması ve ağ kesintisi kullanıcıya farklı mesajlar olarak yansıtılmalı. Yetki yokken asistanın yeni izin isteme yolunu göstermesi; takvim doluyken alternatif zaman önermesi; ağ hatasında ise işlemin kaydedilip kaydedilmediğini kontrol ettirmesi gerekir.

Geçişi nasıl test edersiniz?

Önce test ortamında eski istemciyle mevcut davranışı kaydedin. Sonra ajan olarak işaretlenmiş yeni OAuth istemcisini yapılandırın, yetkilendirme akışını tamamlayın ve MCP sunucusuna güvenli bir okuma isteği gönderin. Ardından izinli bir test takvimine etkinlik ekleyip güncelleme ve iptal akışını deneyin. Her adımda uygulamanın kullandığı istemciyi, istek sonucunu ve ekranda görülen randevu durumunu eşleştirin. API’nin başarılı yanıtı ile müşteriye doğru bildirim gitmesi ayrı kabul ölçütleridir.

Geçişten sonra yalnızca “bağlandı” işaretine bakmayın. İki kez gönderilen istek aynı etkinliği iki kez oluşturuyor mu? Bağlantı kesildiğinde tekrar deneme kuralı ne yapıyor? Eski OAuth istemcisinin erişimini ne zaman kapatacağınız ve sorun çıkarsa nasıl geri döneceğiniz belli olsun. Pilot tamamlanmadan tüm randevu trafiğini asistana taşımayın; önce sınırlı ekip ve örnek görevlerle çalışın.

Calendar API’de randevu türlerini başka bir açıdan düzenlemek isteyenler Google Calendar etiketleriyle randevu türleri rehberine bakabilir. O içerik takvim verisinin sınıflandırılmasını ele alır; bu yazı MCP kullanan ajan istemcisinin yetkilendirme geçişine odaklanır. Bir sistem iki özelliği kullanıyorsa veri modelini ve erişim modelini ayrı test etmek gerekir.

Webinle’nin otomasyon yazılımları hizmeti için randevu sürecindeki insan onayını, kullanılan Calendar bağlantı türünü ve iptal akışını paylaşın. Böylece mevcut REST entegrasyonunu korumak mı, MCP pilotunu yetki ve hata kontrolleriyle sürdürmek mi gerektiği gerçek iş akışına göre belirlenir.