Claude की उन्नत tool use क्षमताएँ पेश

• Claude Developer Platform में 3 नए फीचर जोड़े गए हैं, जो मॉडल को हज़ारों external tools को कुशलतापूर्वक खोजने, कॉल करने और सीखने में सक्षम बनाने वाली advanced tool use architecture प्रदान करते हैं
• Tool Search Tool ज़रूरत पड़ने पर ही tool definitions लाता है, जिससे token usage में अधिकतम 85% कमी आती है, और बड़े MCP environment में accuracy 74~88% तक बेहतर होती है
• Programmatic Tool Calling code execution environment में tools को parallel call करके token बचत (37%), latency में कमी, और accuracy में सुधार हासिल करता है
• Tool Use Examples वास्तविक call examples के ज़रिए JSON Schema से व्यक्त न हो पाने वाले tool use patterns और parameter relationships को सीखने में मदद करता है
• ये तीनों फीचर बड़े AI agents के efficient orchestration की बुनियाद देते हैं और complex workflow automation के मुख्य घटक हैं

---

AI agents में tool use का विस्तार

• भविष्य के AI agents को सैकड़ों से हज़ारों tools का एकीकृत रूप से उपयोग करना होगा
  • उदाहरण के तौर पर IDE assistant tools, operations coordinators, और Slack·GitHub·Jira·Google Drive जैसी integrations का उल्लेख किया गया है
• मौजूदा तरीका सभी tool definitions को पहले से load करने की माँग करता है, जिससे context window तेज़ी से भर जाता है
• नया approach ज़रूरत के समय tools को खोजने और load करने के साथ code-based calling और example-based learning के ज़रिए efficiency हासिल करता है

Tool Search Tool

• मौजूदा MCP environment में कई servers जुड़े होने पर tool definitions 100K से अधिक tokens घेर लेते हैं
  • उदाहरण: GitHub(26K), Slack(21K), Jira(17K) आदि मिलाकर 134K tokens से ज़्यादा के मामले
• Tool Search Tool tools को on-demand तरीके से search और load करता है
  • शुरुआती load पर लगभग 500 tokens ही लगते हैं, और ज़रूरी tools ही बाद में load होते हैं
  • कुल token usage लगभग 8.7K तक घट जाता है, यानी 95% context बचत
• internal tests के अनुसार MCP evaluation accuracy में सुधार: Opus 4: 49%→74%, Opus 4.5: 79.5%→88.1%
• defer_loading: true setting के ज़रिए tools को delayed load किया जा सकता है
  • अक्सर इस्तेमाल होने वाले tools हमेशा load रखें, बाकी को search के समय लाएँ
• regex·BM25 आधारित search tools default रूप से उपलब्ध हैं, और embedding-based custom search भी संभव है
• अपनाने की अनुशंसित स्थितियाँ: 10 से अधिक tools, 10K tokens से अधिक definitions, और बार-बार होने वाली selection errors वाले environment

Programmatic Tool Calling

• मौजूदा natural language आधारित calling में intermediate results के जमा होने और multiple reasoning passes के कारण inefficiency पैदा होती है
  • उदाहरण: 10MB log analysis में पूरा data context में शामिल हो जाता है, जिससे tokens बेकार खर्च होते हैं
• Programmatic Tool Calling(PTC) code execution environment में tools को parallel call करता है
  • Claude Python code के ज़रिए loops, conditionals, और data transformation संभालता है
  • intermediate results model context में शामिल नहीं होते, और केवल final result लौटाया जाता है
• उदाहरण: quarterly budget overrun ढूँढने वाले task में 2,000 items की जगह सिर्फ 1KB result ही context में शामिल होता है
• प्रभाव
  • token usage 43,588→27,297 (37% कमी)
  • latency में कमी (20 calls में 19 reasoning steps हटते हैं)
  • accuracy में सुधार: internal search 25.6→28.5%, GIA benchmark 46.5→51.2%
• अपनाने की अनुशंसित स्थितियाँ
  • बड़े data summaries, 3 से अधिक चरणों वाले dependent calls, और parallel execution की ज़रूरत वाले tasks
  • single call या छोटे response के लिए यह inefficiency पैदा कर सकता है

Tool Use Examples

• JSON Schema केवल structure define करता है, लेकिन usage patterns, format rules, और parameter relationships व्यक्त नहीं कर पाता
  • उदाहरण: date format, ID rules, nested object कब इस्तेमाल करना है, जैसी बातें स्पष्ट नहीं होतीं
• Tool Use Examples tool definitions में वास्तविक input examples (input_examples) जोड़ता है
  • उदाहरणों के माध्यम से Claude date format (YYYY-MM-DD), ID rule (USR-XXXXX), और optional parameter combinations सीखता है
• internal tests में complex parameter handling accuracy 72%→90% तक बढ़ी
• अपनाने की अनुशंसित स्थितियाँ
  • nested structures और optional parameters वाले tools
  • ऐसे domain-specific rules वाले API जिन्हें Schema में व्यक्त नहीं किया जा सकता
  • जब मिलते-जुलते tools के बीच अंतर करना ज़रूरी हो

तीनों फीचर्स का संयुक्त उपयोग और best practices

• ये तीनों फीचर एक-दूसरे के पूरक हैं
  • Tool Search Tool → ज़रूरी tools की खोज
  • Programmatic Tool Calling → efficient execution
  • Tool Use Examples → accurate calling
• अपनाने की प्राथमिकता
  • context overflow → Tool Search Tool
  • बहुत अधिक intermediate results → Programmatic Tool Calling
  • parameter errors → Tool Use Examples
• सेटअप टिप्स
  • tool names और descriptions को स्पष्ट लिखें ताकि search accuracy बेहतर हो
  • अक्सर इस्तेमाल होने वाले 3~5 tools हमेशा load रखें, बाकी delayed load करें
  • code execution के लिए tool के return format को स्पष्ट करें
  • example data को वास्तविक और संक्षिप्त रखें (1~5 examples)

शुरू करना

• ये तीनों फीचर beta version में उपलब्ध हैं
  • betas=["advanced-tool-use-2025-11-20"] header जोड़कर इस्तेमाल किया जा सकता है
  • शामिल tools: tool_search_tool_regex_20251119, code_execution_20250825 आदि
• official docs और GitHub cookbook में API examples और implementation guide उपलब्ध हैं
• इन फीचर्स को सिर्फ function calling से आगे बढ़कर intelligent orchestration की दिशा में जाने वाली foundational technology के रूप में पेश किया गया है
• complex workflows और large-scale data environments में dynamic discovery, efficient execution, और accurate calling को संभव बनाने वाले प्रमुख घटकों के रूप में इन पर ज़ोर दिया गया है

[kaydash]

लेकिन अभी तक तो यह मॉडल-ड्रिवन ही लगता है। Claude जिन models को service कर रहा है, इसलिए यह इतना अच्छा working कर रहा है; बाकी models के साथ वाकई ऐसा होगा या नहीं... यही सोचता हूँ।

[beoks]

Anthropic, Google, OpenAI जैसी कंपनियों में मुझे लगता है कि Anthropic सबसे ज़्यादा Agentic AI के क़रीब है।

[GN⁺]

Hacker News राय

• कई tool call को स्ट्रीम करते समय context उपयोग कम करने का तरीका खोज रहे हैं
  कुछ प्रोसेसिंग को tool पर ही offload करके 200k token वाले markdown को summary structure के रूप में लौटाया जाता है, लेकिन इस तरीके में भी कभी-कभी main model का context जल्दी भर जाता है

• मुझे लगता है Programmatic Tool Calling अगला स्वाभाविक कदम है
  LLM जिस दिशा में code को language की तरह हैंडल कर रहे हैं, उसमें उस language की definition महत्वपूर्ण है
  लेकिन tool search अनावश्यक overhead लगता है। ज़रूरी tools को पहले से context में डालना ज़्यादा efficient है
  आख़िरकार function definition जैसी संक्षिप्त tool definition language की ज़रूरत है, और मैं चाहता हूँ कि object को context में रखा जाए ताकि model type और callable methods को पहचान सके

  • इस तरह की जटिल संरचना के बजाय .d.ts जैसी declaration file दे दें तो काफ़ी है
    maintenance और testing भी आसान है, और ज़रूरत हो तो export * as Foo from '@foo/foo' जैसे तरीके से import किया जा सकता है
    LLM code लिखने में भी अच्छे हैं, इसलिए write permission मिले तो वे ख़ुद tools बना सकते हैं या import कर सकते हैं
    आगे चलकर Jupyter/Pluto/Mathematica जैसे interactive AI↔human collaboration platform ज़्यादा उपयुक्त लगते हैं
    अगर इसमें voice input जोड़ दिया जाए और sessions के बीच collaboration भी संभव हो जाए, तो यह लगभग Skynet स्तर का system बन जाएगा
  • समझ नहीं आता कि नई language की ज़रूरत ही क्यों है
    मैंने जो agent बनाया है, वह Python SDK की कुछ सुविधाओं और custom functions से ही अच्छी तरह चल जाता है
    इस तरह की pseudo-RPC संरचना एक अनावश्यक रस्म जैसी लगती है
  • नवीनतम MCP spec (2025-06-18+) Structured Content और Output Schema को support करती है
    Smolagents इसका उपयोग करके tool output को object (dict) की तरह हैंडल करता है
    जानना चाहता हूँ कि क्या यह approach उस दिशा से मिलती-जुलती है जिसकी मैं बात कर रहा हूँ
    विस्तार से Hugging Face ब्लॉग पोस्ट में है

• उत्सुकता है कि क्या MCP server tool definitions में usage examples शामिल करेगा
  अगर हाँ, तो code examples भी जोड़े जा सकते हैं और code generation step को छोड़ा जा सकता है, लेकिन शायद security concerns की वजह से इसे रोका गया है
  third-party द्वारा दिया गया code चलाना ख़तरनाक है, इसलिए यह design समझ में आता है

• Python को wrapper के रूप में इस्तेमाल किया गया, यह थोड़ा अफ़सोसजनक है
  अगर Bash इस्तेमाल होता, तो भाषाओं के बीच compatibility ज़्यादा होती और यह Python का उपयोग न करने वाले workflows में भी फिट बैठता

  • मुझे तो उल्टा Python बेहतर लगता है
    external tools चलाने की इसकी क्षमता भी Bash जितनी ही है
  • लगता है उन्होंने यह देखकर वही दिशा चुनी कि लोग वास्तव में Python का ही उपयोग करते हैं

• “ऐसा भविष्य जहाँ model सैकड़ों से हज़ारों tools को सहजता से संभाले” — यह दिशा ग़लत लगती है
  इसके बजाय कम tools + उन्हें बेहतर उपयोग करने की क्षमता सही दिशा है
  चरम स्थिति में सिर्फ़ एक ShellTool भी काफ़ी हो सकता है

  • बेशक model सब कुछ शुरू से ख़ुद भी कर सकता है, लेकिन अगर पहले से verified tools मौजूद हों, तो उनका उपयोग बेहतर है
    आदर्श तरीका यह होगा कि model ख़ुद tools बनाए, उन्हें test करे और भरोसेमंद बनाना सीखे
  • मैं भी काफ़ी हद तक ऐसा ही सोचता हूँ
    connector ecosystem समझने में आसान है और marketing के लिए अच्छा है, लेकिन मूल रूप से यह एक ग़लत paradigm लगता है

• मुझे लगता है एक छोटा local orchestrator model होना अच्छा रहेगा
  पूरे workflow को programmatically orchestrate करना कई बार inefficient होता है
  context pollution कम करने और speed बढ़ाने के लिए programmatic > tiny local LLM > frontier LLM संरचना आदर्श है
  छोटा model context को बार-बार reset कर सकता है और सिर्फ़ ज़रूरी results बड़े model को भेज सकता है

• AI assistant का उपयोग करते समय बार-बार दोहराए जाने वाले patterns दिखते हैं
  जब आप किसी inefficient तरीके को ख़ुद सुधारते हैं, तो कुछ महीनों बाद कोई नया tool आ जाता है और आपका काम अर्थहीन हो जाता है
  इसे मैं latest tech का पीछा करने की क़ीमत मानता हूँ

• लगता है कि किसी दिन पूरा web अरबों tools से बना होगा
  Google उन्हें index करेगा, और Gemini उन्हें dynamic तरीके से चुनकर दुनिया में actions करेगा
  सच कहूँ तो मैं ऐसी चीज़ Gemini 3 से उम्मीद कर रहा था

• यहाँ बताई गई feature #2 हाल में चर्चा में रहे उस concept का implementation है जिसमें “tool को सीधे call नहीं किया जाता, बल्कि code लिखकर call किया जाता है”
  यह Python sandbox में चलता है, API से भी accessible है, और tool calls को सामान्य API calls की तरह expose करता है
  Batch tool calling ने पहले ही हमारे product में AI assistant की speed काफ़ी बढ़ा दी है, और यह feature उसका evolved version लगता है

• हमारा agentic builder सिर्फ़ एक tool इस्तेमाल करता है — GraphQL
  agent query लिखकर उसे execute करता है और introspection से ज़रूरी जानकारी लेता है
  सिर्फ़ न्यूनतम data मिलने से token बचत होती है
  50 से ज़्यादा tools load करने की ज़रूरत नहीं पड़ती, और REST API की N+1 समस्या भी हल हो जाती है
  GraphQL typed schema की वजह से agent बेहतर code लिखता है
  पहले मुझे GraphQL पसंद नहीं था, लेकिन MCP की मौजूदा स्थिति को देखकर अब लगता है कि यह AI agents के लिए सबसे उपयुक्त technologies में से एक है
  विस्तार से इस लेख में लिखा है

  • मैं भी इसी तरह का approach इस्तेमाल करता हूँ
    मेरा agent सिर्फ़ एक SPARQL query चलाता है, और state सिर्फ़ graph DB में रहती है
    ज़्यादातर ontologies public हैं, इसलिए schema introspection की लगभग ज़रूरत नहीं पड़ती
    structured output की वजह से इसे सिर्फ़ valid RDF generate करने तक सीमित किया जा सकता है
    GraphQL में भी शायद ऐसा ही approach संभव होगा
  • लेकिन यह हर use case पर फिट नहीं बैठता
    मुझे web search, local API calls, Slack integration जैसे अलग-अलग काम करने होते हैं, इसलिए सिर्फ़ GraphQL काफ़ी नहीं है
  • GraphQL introspection में definition बहुत लंबी हो सकती है, जिससे token की बर्बादी होती है, या फिर उसे कई बार call करना पड़ सकता है
  • फिर भी यह GraphQL के उपयोग का वास्तव में बहुत अच्छा उदाहरण है
    permissions, caching और mutation जैसी समस्याएँ हैं, लेकिन selective context loading पर इनका बड़ा असर नहीं पड़ता
  • हम भी Exograph में यही approach अपनाते हैं (exograph.dev)
    LLM schema के अनुसार GraphQL queries काफ़ी अच्छी तरह लिख लेता है
    गलती होने पर भी अगर अच्छे error messages दिए जाएँ, तो वह जल्दी सुधार कर लेता है
    संबंधित reasoning इस ब्लॉग पोस्ट में है

[kimjoin2]

मुझे भी लगा कि sonnet 4.5 काफ़ी अच्छा है
लेकिन opus 4.5 उससे भी बेहतर लगता है। वाह।

[shakespeares]

अच्छा? मुख्य रूप से किस मामले में ऐसा है?