- Claude Developer Platform’a 3 yeni özellik eklendi; böylece modelin binlerce harici aracı verimli biçimde keşfedip çağırabildiği ve öğrenebildiği gelişmiş bir araç kullanımı yapısı sunuluyor
- Tool Search Tool, araç tanımlarını yalnızca gerektiği anda yükleyerek token kullanımını %85’e kadar azaltıyor ve büyük ölçekli MCP ortamlarında doğruluğu %74–88 seviyesine çıkarıyor
- Programmatic Tool Calling, kod yürütme ortamında araçları paralel çağırarak token tasarrufu (%37), daha düşük gecikme ve daha yüksek doğruluk sağlıyor
- Tool Use Examples, gerçek çağrı örnekleri üzerinden JSON Schema ile ifade edilemeyen araç kullanım kalıplarını ve parametre ilişkilerini modele öğretiyor
- Bu üç özellik, büyük ölçekli yapay zeka ajanlarının verimli orkestrasyonu için temel sunuyor ve karmaşık iş akışı otomasyonunun çekirdek bileşenleri arasında yer alıyor
Yapay zeka ajanlarında araç kullanımını ölçeklendirmek
- Geleceğin yapay zeka ajanlarının yüzlerce, hatta binlerce aracı bütünleşik biçimde kullanması gerekecek
- Örnek olarak IDE yardımcı araçları, operasyon koordinatörleri ve Slack, GitHub, Jira, Google Drive gibi servislerle entegrasyon veriliyor
- Mevcut yaklaşımda tüm araç tanımlarının önceden yüklenmesi gerekiyor; bu da context window’u hızla tüketiyor
- Yeni yaklaşım ise araçları gerektiği anda keşfedip yüklemeye, ayrıca kod tabanlı çağrılar ve örneklerden öğrenme ile verimlilik sağlamaya odaklanıyor
Tool Search Tool
- Mevcut MCP ortamlarında çok sayıda sunucu bağlandığında araç tanımları 100 binden fazla token kaplayabiliyor
- Örnek: GitHub (26K), Slack (21K), Jira (17K) gibi kaynaklar biriktiğinde 134K token’ı aşan durumlar oluşabiliyor
- Tool Search Tool, araçları on-demand şekilde arayıp yüklüyor
- İlk yüklemede yalnızca yaklaşık 500 token kullanılıyor, ardından sadece gereken araçlar ek olarak yükleniyor
- Toplam token kullanımı yaklaşık 8.7K’ye düşüyor ve bağlamda %95 tasarruf sağlanıyor
- İç test sonuçlarına göre MCP değerlendirme doğruluğu Opus 4: %49→%74, Opus 4.5: %79.5→%88.1 seviyesine yükseldi
defer_loading: true ayarı ile araçlar gecikmeli yüklenebiliyor
- Sık kullanılan araçlar sürekli yüklü tutulup diğerleri arama anında getirilebiliyor
- Regex ve BM25 tabanlı arama araçları varsayılan olarak sunuluyor; embedding tabanlı özel arama da mümkün
- Önerilen kullanım koşulları: 10’dan fazla araç, 10K token’dan büyük tanımlar, sık araç seçme hatalarının görüldüğü ortamlar
Programmatic Tool Calling
- Mevcut doğal dil tabanlı çağrılar, ara sonuçların birikmesi ve çoklu akıl yürütme geçişleri nedeniyle verimsizlik yaratıyor
- Örnek: 10MB’lık log analizi sırasında tüm verinin bağlama dahil edilmesi token israfına yol açıyor
- Programmatic Tool Calling (PTC), araçları kod yürütme ortamında paralel olarak çağırıyor
- Claude, Python kodu ile döngüler, koşullar ve veri dönüşümleri gerçekleştiriyor
- Ara sonuçlar model bağlamına dahil edilmiyor, yalnızca nihai sonuç döndürülüyor
- Örnek: Çeyreklik bütçe aşımı yapanları bulma görevinde 2.000 öğe yerine yalnızca 1KB’lık sonuç bağlama ekleniyor
- Etkileri
- Token kullanımı 43,588→27,297 (%37 azalma)
- Daha düşük gecikme (20 çağrıda 19 akıl yürütme adımı ortadan kalkıyor)
- Daha yüksek doğruluk: iç aramada %25.6→%28.5, GIA benchmark’ında %46.5→%51.2
- Önerilen kullanım koşulları
- Büyük veri özetleme, 3 adımdan fazla bağımlı çağrı, paralel yürütme gerektiren işler
- Tek çağrı veya küçük yanıtlar için verimsiz olabilir
Tool Use Examples
- JSON Schema yalnızca yapıyı tanımlar; kullanım kalıplarını, biçim kurallarını ve parametre ilişkilerini ifade edemez
- Örnek: tarih biçimi, ID kuralları, iç içe nesnelerin hangi durumda kullanılacağı gibi noktalar belirsiz kalabilir
- Tool Use Examples, araç tanımına gerçek giriş örnekleri (
input_examples) ekliyor
- Bu örnekler sayesinde Claude; tarih biçimini (YYYY-MM-DD), ID kurallarını (USR-XXXXX) ve isteğe bağlı parametre kombinasyonlarını öğrenebiliyor
- İç testlerde karmaşık parametre işleme doğruluğu %72’den %90’a çıktı
- Önerilen kullanım koşulları
- İç içe yapılar ve çok sayıda isteğe bağlı parametre içeren araçlar
- Alan kuralları Schema ile ifade edilemeyen API’ler
- Benzer araçların birbirinden ayrılmasının gerektiği durumlar
Üç özelliğin birlikte kullanımı ve en iyi uygulamalar
- Bu üç özellik birbirini tamamlayacak şekilde çalışıyor
- Tool Search Tool → gerekli aracın keşfi
- Programmatic Tool Calling → verimli yürütme
- Tool Use Examples → doğru çağrı
- Uygulama önceliği
- Bağlam sınırının aşılması → Tool Search Tool
- Ara sonuçların aşırı büyümesi → Programmatic Tool Calling
- Parametre hataları → Tool Use Examples
- Yapılandırma ipuçları
- Arama doğruluğunu artırmak için araç adları ve açıklamaları net yazılmalı
- Sık kullanılan 3–5 araç sürekli yüklü tutulmalı, kalanlar gecikmeli yüklenmeli
- Kod yürütme için kullanılan araçlarda dönüş formatı açıkça belirtilmeli
- Örnek veri gerçekçi ve kısa tutulmalı (1–5 örnek)
Başlarken
- Üç özellik de beta sürümünde sunuluyor
betas=["advanced-tool-use-2025-11-20"] header’ı eklenerek kullanılabiliyor- Dahil araçlar:
tool_search_tool_regex_20251119, code_execution_20250825 vb.
- Resmî dokümantasyon ve GitHub cookbook içinde API örnekleri ve uygulama rehberleri yer alıyor
- Bu özellikler, basit fonksiyon çağrılarının ötesine geçerek akıllı orkestrasyona evrilen temel teknoloji olarak sunuluyor
- Özellikle karmaşık iş akışları ve büyük veri ortamlarında dinamik keşif, verimli yürütme ve doğru çağrı sağlayan çekirdek bileşenler olarak öne çıkarılıyor
5 yorum
Ama şimdilik bunun biraz model gücüyle ilgili olduğunu düşünüyorum. Claude'un sunduğu modeller olduğu için bu kadar iyi çalışıyor; diğer modellerde gerçekten nasıl olur... emin değilim.
Anthropic, Google, OpenAI gibi şirketler arasında Anthropic'in Agentic AI'a en yakın olanı olduğu hissine kapılıyorum.
Hacker News görüşleri
Birden fazla tool call stream edilirken context kullanımını azaltmanın bir yolunu arıyorlar
İşlemenin bir kısmını aracın kendisine offload ederek 200k tokenlık markdown’ı özet bir yapı olarak döndürmesini sağlıyorlar, ancak bu yaklaşım bile bazen ana modelin context’ini hızla doldurabiliyor
Programmatic Tool Calling’in doğal bir sonraki adım olduğunu düşünüyorum
LLM’ler kodu bir dil gibi ele alma yönünde ilerlediği için, o dilin tanımı önemli
Ancak tool search’ün gereksiz bir overhead olduğunu düşünüyorum. Gerekli araçları context’e önceden koymak daha verimli
Sonuçta, fonksiyon tanımı kadar kısa bir tool definition language gerekiyor; nesneleri context’e koyup tiplerini ve çağrılabilir metotlarını tanımasını istiyorum
.d.tsbenzeri bir declaration dosyası vermek yeterliBakımı ve testi de kolay olur; gerekirse
export * as Foo from '@foo/foo'gibi içe aktarılabilirLLM kod yazmakta da iyi olduğu için, yazma izni verilirse araçları kendi oluşturabilir ya da içe aktarabilir
İleride Jupyter/Pluto/Mathematica gibi interaktif AI↔insan iş birliği platformları daha uygun olabilir gibi görünüyor
Sesli giriş eklenir ve oturumlar arası iş birliği de mümkün olursa, neredeyse Skynet seviyesinde bir sistem ortaya çıkar gibi duruyor
Benim yaptığım ajan, Python SDK’nin bazı özellikleri ve birkaç özel fonksiyonla gayet yeterli çalışıyor
Bu tür pseudo-RPC yapıları gereksiz bir ritüel gibi geliyor
Smolagents bunu kullanarak araç çıktılarını nesne (dict) olarak ele alıyor
Bu yaklaşımın benim kastettiğim yöne benzer olup olmadığını merak ediyorum
Ayrıntılar Hugging Face blog yazısında var
MCP sunucusunun tool tanımına kullanım örnekleri ekleyip eklemeyeceğini merak ediyorum
Eğer ekleyecekse, kod örnekleri de konulabilir ve böylece kod üretim adımı atlanabilir, ancak muhtemelen güvenlik sorunları nedeniyle buna izin verilmemiş
Üçüncü tarafların sağladığı kodu çalıştırmak riskli olduğu için bu tasarım anlaşılabilir
Python’ın bir wrapper olarak kullanılmış olması biraz hayal kırıklığı yarattı
Bash kullanılsaydı diller arası uyumluluk daha yüksek olur ve Python kullanmayan iş akışlarına da uyardı
Harici araç çalıştırma kabiliyeti de Bash’ten aşağı kalmıyor
“Modelin yüzlerce, binlerce aracı sorunsuz yönettiği bir gelecek” fikri yanlış gibi görünüyor
Bana göre doğru yön, daha az araç + onları daha iyi kullanma becerisi
Uç noktada tek bir ShellTool bile yeterli olabilir
İdeal olan, modelin kendi araçlarını oluşturup test ederek onlara güvenmeyi öğrenmesi
Connector ekosistemi anlaşılması kolay ve pazarlaması rahat, ama temelde yanlış bir paradigma gibi duruyor
Küçük bir yerel orkestratör model olsa iyi olur diye düşünüyorum
Tüm iş akışını programatik olarak koordine etmek çoğu zaman verimsiz olabiliyor
Context kirlenmesini azaltmak ve hızı artırmak için ideal yapı programmatic > tiny local LLM > frontier LLM olur
Küçük model context’i sık sık sıfırlayıp yalnızca gerekli sonuçları büyük modele iletebilir
AI asistanları kullanırken tekrar eden bir örüntü var
Verimsiz bir yöntemi bizzat iyileştiriyorsun, sonra birkaç ay sonra yeni bir araç çıkıyor ve yaptığın iş anlamsızlaşıyor
Bunun, en güncel teknolojiyi kovalamanın bedeli olduğunu düşünüyorum
Bir gün tüm web’in milyarlarca araçtan oluşacağını düşünüyorum
Google bunları indeksleyecek, Gemini de dinamik biçimde seçip dünyada eylem gerçekleştirecek
Açıkçası bunu Gemini 3’te bekliyordum
Burada anlatılan özellik #2, son dönemde konuşulan “aracı doğrudan çağırmak yerine kod yazarak çağırma” fikrinin bir uygulaması
Python sandbox içinde çalışıyor, API üzerinden de erişilebiliyor ve araç çağrılarını sıradan API çağrıları gibi sunuyor
Batch tool calling zaten ürünümüzdeki AI asistanının hızını ciddi biçimde artırmıştı; bu yeni özellik de onun evrilmiş hali gibi görünüyor
Bizim agentic builder yalnızca tek bir araç kullanıyor — o da GraphQL
Ajan sorguyu yazıp çalıştırıyor, gerekli bilgileri de introspection ile alıyor
Yalnızca minimum veriyi aldığı için token tasarrufu sağlanıyor
50’den fazla aracı yüklemek gerekmiyor, ayrıca REST API’deki N+1 sorunu da çözülüyor
GraphQL typed schema sayesinde ajan daha iyi kod yazıyor
Eskiden GraphQL’i sevmezdim ama MCP’nin mevcut durumuna bakınca, AI ajanları için en uygun teknolojilerden biri olduğunu düşünüyorum
Ayrıntıları şu yazıda anlattım
Benim ajanım yalnızca bir SPARQL query çalıştırıyor ve durum sadece graph DB’de tutuluyor
Ontolojilerin çoğu açık olduğu için schema introspection’a neredeyse hiç ihtiyaç olmuyor
Structured output sayesinde yalnızca geçerli RDF üretmeye zorlanabiliyor
GraphQL’de de benzer bir yaklaşım mümkün olabilir
Ben web araması, yerel API çağrıları, Slack entegrasyonu gibi çeşitli işler yapmak zorundayım; bu yüzden tek başına GraphQL yetmiyor
Yetkilendirme, caching ve mutation sorunları var ama seçici context yükleme açısından büyük bir etkisi yok
LLM, schema’ya uyan GraphQL sorgularını oldukça iyi yazıyor
Hata yapsa bile iyi hata mesajları verilince hızlıca düzeltiyor
İlgili reasoning bu blog yazısında yer alıyor
Sonnet 4.5'in de oldukça iyi olduğunu düşünüyordum.
Ama Opus 4.5 daha da iyi gibi. Vay canına.
Öyle mi? Başlıca hangi yönleri böyle?