SharePoint MCP Tools: Work IQ ile Agent’a Site Erişimi

Work IQ API’ye yeni SharePoint araçları geliyor. Bu araçlarla kendi uygulamalarınız ve agent’larınız, Microsoft Copilot’ı besleyen iş zekası katmanının aynısı üzerinden SharePoint içeriğine ve işlemlerine erişebiliyor. Agent dosya bulabiliyor, liste ve kitaplıkları yönetebiliyor, onay akışlarıyla çalışabiliyor; hepsi de oturum açmış kullanıcının mevcut izinleri çerçevesinde. Her işlem için ayrı entegrasyon yazma zorunluluğu da ortadan kalkıyor.

Work IQ ve SharePoint MCP bağlantısı

Work IQ, yapay zekayı kurumun bilgi birikimi, çalışanları ve iş akışlarıyla buluşturan katman olarak konumlanıyor. Bağlam, bellek ve beceri (skill) bileşenlerini bir araya getiriyor, böylece agent’ların işi anlamasını ve o iş üzerinde eylem almasını hedefliyor.

Daha önce duyurulan SharePoint MCP (önizleme aşamasında), SharePoint tarafında barındırılan kimlik doğrulamalı bir MCP uç noktası üzerinden SharePoint uzmanlığını Work IQ’ya açıyor. Kapsadığı alanlar şunlar:

• Listeler ve belge kitaplıkları
• Liste öğeleri
• Dosyalar ve klasörler
• Arama
• Onaylar (approvals)
• Kurallar (rules) ve Quick Steps
• Geri dönüşüm kutusu ve sürüm oluşturma

Katalogda 60’tan fazla SharePoint işlemi var. Agent’ın bunların her birini ayrı bir araç olarak kaydetmesi ya da dışarı açması gerekmiyor; tasarımın püf noktası da bu.

Sabit dilbilgisi, çalışma zamanında keşif

Work IQ agent’a sabit bir genel araç dilbilgisi sunuyor, ihtiyaç duyulan SharePoint yollarını ise çalışma zamanında keşfediyor. Temel sıra şöyle işliyor:

1. search_paths ile uygun işlemi keşfet.
2. get_schema ile o işlemin argümanlarını ve tiplerini incele.
3. do_action ile dönen yolu uygun bir istek gövdesiyle çağır.

Böylece agent’ın araç yüzeyi küçük kalırken arkadaki SharePoint yetenekleri büyümeye devam edebiliyor. Yeni bir işlem eklendiğinde agent tarafında araç listesini şişirmeniz gerekmiyor.

SharePoint sağlayıcısı, kayıtlı sharepoint/ ön eki altındaki yolları işliyor.

siteKey ve alan adları

Site bağlamına duyarlı işlemler, ham bir site URL’si yerine genellikle opak bir siteKey kullanıyor. Agent ilgili site için bir kez get_site_key çağrısı yapıyor, dönen anahtarı da sonraki işlemlere olduğu gibi aktarıyor. Anahtarlar üretildikleri sitenin kapsamında kalmalı.

Yazma işlemlerinde SharePoint’in dahili alan adları kullanılıyor. Kişi, lookup ve taksonomi değerlerini şemaya göre çözümlemek gerekiyor; görünen adların (display name) kabul edileceğini varsaymak hatalı sonuç doğurabilir.

Örnek bir etkileşim akışı

Pratikte agent önce site bağlamını kuruyor, sonra anlamlı bir belge veya içerik bulmak için bir arama ya da liste işlemi keşfediyor. Kullanılacak yol ve argümanlar gerçek akışa göre değişiyor, ama varsayımsal bir akış şöyle görünüyor:

1. get_site_key(siteUrl: "https://contoso.sharepoint.com/sites/project")
→ keep the returned siteKey for this site
2. search_paths(...)
→ discover the SharePoint path for the needed operation
3. get_schema(path: "<path returned by search_paths>")
→ inspect the required arguments and their types
4. do_action(
"<discoveredSharePointpath>",
body: {
siteKey: "<opaque key from get_site_key>",
...arguments shaped by get_schema...
}
)

Agent, do_action isteğinin gövdesini kurarken get_schema çıktısını temel alıyor. Opsiyonel alanları tahmin etmesine ya da görünen etiketleri dahili değerlere çevirmeye çalışmasına böylece gerek kalmıyor.

Bir ayrıntı daha var. Work IQ’nun genel araç sözleşmesinde items, folders veya viewIds gibi argümanlar iç içe geçmiş nesne yerine JSON olarak kodlanmış bir dize biçiminde temsil edilebiliyor. Dönen şemayı birebir takip etmek bu yüzden en güvenli yol.

Dönen verinin yapısı seçilen işleme bağlı. Bir arama işlemi örneğin eşleşen sayfaları, dosyaları, liste öğelerini veya diğer SharePoint kaynaklarını döndürebiliyor; yanında da agent’ın sonraki çağrılarda kullanabileceği tanımlayıcılar ve URL’ler geliyor.

Güvenlik modeli: WorkIQ.Read ve WorkIQ.Act

Work IQ, izinleri daha ayrıntılı ayarlayabilmek için iki yeni izin kapsamı getiriyor: WorkIQ.Read ve WorkIQ.Act. SharePoint araçlarının sağlayıcısı da bu kapsamlarla hizalanıyor. Yani agent’ınızın Work IQ içindeki SharePoint araçlarına erişebilmesi için bu iki kapsamdan en az birine sahip olması zorunlu.

• WorkIQ.Read: Agent, yalnızca durum değiştirmeyen işlemlerle hizalanan daraltılmış bir üst düzey Work IQ fiil aracı kümesine erişiyor: fetch, call_function, get_schema ve search_paths.
• WorkIQ.Act: Agent, araç kümesinin tamamına erişiyor.

Her iki kapsam da delege edilmiş (delegated) izin kapsamı. Work IQ güvenlik modelinde her işlem bir kullanıcı adına yürütülüyor, dolayısıyla o kullanıcının zaten yetkili olduğu eylemlerle sınırlı kalıyor. Çağrılar oturum açmış çağıranın SharePoint kimliği altında çalıştığı için agent, kullanıcının erişim hakkı olmayan bir içeriği ne okuyabiliyor ne değiştirebiliyor.

Nereden başlamalı

Agent’ınızın site içeriği veya site işlemleriyle çalışması gerekiyorsa SharePoint’in keşfet ve eylem al akışını denemek makul bir başlangıç. Dönen şemalara ve verilere bakarak hangi işlemlerin akışınıza uyduğunu hızla görebilirsiniz.

Work IQ tarafındaki gelişmeler ve yol haritası için Microsoft, 17-20 Kasım 2026 tarihlerinde San Francisco’da düzenlenecek Microsoft Ignite etkinliğine işaret ediyor. Etkinlik ayrıntıları ve güncellemeler Ignite sitesi üzerinden takip edilebiliyor.

Kaynaklar ve İleri Okuma

• Work IQ: SharePoint Tools — Microsoft 365 Developer Blog (Paolo Pialorsi, Patrick Rodgers)
• Microsoft 365 Developer Blog
• Microsoft Ignite resmî sitesi
• Work IQ Developer Tools önizlemesi
• Work IQ Developer Tools ile Copilot plugin paketleme