एक tool क्या है

आपके मौजूदा workflows कई अलग-अलग technologies पर निर्भर करते हैं — project management software, databases, files। Claude ये चीजें खुद से check नहीं कर सकता। इसके बजाय, यह tools पर निर्भर करता है, जो Claude को external data और actions तक पहुंच देते हैं।

एक tool क्या है

सीधे शब्दों में कहें तो, एक tool एक function है जिसे आप define करते हैं और Claude को expose करते हैं। आप describe करते हैं कि यह क्या करता है और किन inputs को लेता है, और Claude decide करता है कि इसे कब call करना है।

यहाँ मुख्य बात है: Claude tool को execute नहीं करता — आपका code करता है। flow इस तरह दिखता है:

• Claude एक tool call request करता है।
• आपका code function को execute करता है।
• परिणाम Claude को वापस जाता है, और यह आगे बढ़ता है।

Tools कैसे define किए जाते हैं

Tools JSON schemas हैं जिनके तीन parts हैं: एक name, एक description, और एक input schema। आप उन्हें Claude को request body में एक tools array के रूप में pass करते हैं।

Description वह है जो Claude पढ़ता है यह decide करने के लिए कि tool को call करना है या नहीं। अगर आप एक vague description लिखते हैं, तो आपको bad tool use मिलता है। यह agents के misfire होने या available tools को grab न करने का number one कारण है। Specific रहें।

यहाँ एक tool definition कैसा दिखता है:

{ "name": "lookup_building_code", "description": "Look up a specific building code section by its identifier. Returns the full text of that code section. ", "input_schema": { "type": "object", "properties": { "section": { "type": "string", "description": "The building code section to look up" } }, "required": ["section"] } }

तो जब हम इसका use करते हैं तो क्या होता है? मान लीजिए हम एक agent को एक compliance report भेजते हैं। पहले turn पर, Claude stop_reason: "tool_use" के साथ वापस आता है — यह हमारा signal है। यहाँ वह response कैसा दिखता है:

एक API response जिसमें stop_reason को tool_use पर set किया गया है, जिसमें एक tool_use content block है जो tool का नाम और input देता है जिसके साथ Claude इसे call करना चाहता है

हमारा loop lookup_building_code को Claude द्वारा request किए गए parameter के साथ call करता है, फिर परिणाम को एक tool result के रूप में वापस feed करता है — एक user message जिसमें tool call के id से tied एक tool_result block है:

एक user message जिसमें एक tool_result block है जिसमें tool_use_id और looked-up building code text है

और Claude आगे बढ़ता है। उस बिंदु पर, हम Claude को tools call करते रह सकते हैं और results return कर सकते हैं जब तक कि उसके पास जो चाहिए वह न हो।

Multiple tools: Claude को pick करने दें

एक tool उपयोगी है, लेकिन interesting part Claude को multiple tools देना और देखना है कि यह कौन सा use करता है, किस order में।

इस scenario को imagine करें: आप Denver के लिए एक three-day trip के लिए pack कर रहे हैं, और आप आज का weather और अगले कुछ दिनों का forecast दोनों चाहते हैं। तो हम एक की जगह दो tools declare करते हैं:

const tools = [ { name: "get_weather", description: "Get today's current weather for a city. ", input_schema: { type: "object", properties: { city: { type: "string", description: "The city to check" } }, required: ["city"] } }, { name: "get_forecast", description: "Get the weather forecast for the next few days for a city. ", input_schema: { type: "object", properties: { city: { type: "string", description: "The city to check" } }, required: ["city"] } } ];

Loop उसी तरह है जैसे agent loops जो हमने पहले देखे हैं। एकमात्र नया piece एक runTool function है जो tool name पर dispatch करता है एक switch statement के साथ — यह code का block वह जगह है जहाँ आपका code actually run होता है:

function runTool(name, input) { switch (name) { case "get_weather": return getWeather(input. city); case "get_forecast": return getForecast(input. city); } }

while (true) { const response = await client. messages. create({ model: "claude-sonnet-4-6", max_tokens: 1024, messages, tools, });

if (response. stop_reason ! == "tool_use") { // Claude done है — यह final answer है break; }

messages. push({ role: "assistant", content: response. content });

const toolResults = response. content filter((block) => block. type === "tool_use") .map((block) => ({ type: "tool_result", tool_use_id: block. id, content: runTool(block. name, block. input), }));

messages. push({ role: "user", content: toolResults }); }

और यह पूरा pattern है। एक तीसरा tool चाहिए? इसे array में add करें, switch में एक case add करें, और आप done हैं।

इसे run करें, और आप देखेंगे Claude get_weather को call करता है और फिर get_forecast को — कभी-कभी same turn में, कभी-कभी एक के बाद एक। फिर यह answer देता है: layers pack करें, आज snow flurries की उम्मीद करें, पूरे हफ्ते warming हो रही है।

अब notice करें कैसे Claude ने choose किया। इसने descriptions को पढ़ा, आपके prompt को "today's weather" और "the next few days" से map किया, और प्रत्येक के लिए सही tool pick किया। यही कारण है कि आपके tool descriptions really matter करते हैं।

The tool runner: boilerplate को skip करें

आपने शायद पहले से ही दो red flags spot कर लिए हैं जो हमने अभी लिखे हैं:

• यह दो simple lookups के लिए बहुत सारा code है।
• एक real codebase में, आप हर function के लिए handwrite JSON schemas नहीं करना चाहते। यह अपने code को दो बार लिखने जैसा है।

यहाँ tool runner आता है। यह Claude SDK में TypeScript, Python, और Ruby के लिए ship होता है। Runner आपके actual functions को लेता है, schemas build करने के लिए types और docs को read करता है, और पूरे tool use / tool result loop को internally handle करता है।

आपका code shrink हो जाता है: tool को describe करें, prompt भेजें, result के लिए wait करें। यहाँ same two-tool weather demo है जो tool runner के through wired है:

// Same two lookups जो हमने manually run किए — बस plain TypeScript functions function getWeather(city: string) { // ... existing lookup }

function getForecast(city: string) { // ... existing lookup }

const runner = client. beta. messages. toolRunner({ model: "claude-sonnet-4-6", max_tokens: 1024, messages: [ { role: "user", content: "I'm packing for a three-day trip to Denver. What's the weather today and over the next few days? ", }, ], tools: [getWeather, getForecast], });

// सभी tool ping-pong settle हो जाने के बाद final assistant message return करता है const finalMessage = await runner. untilDone();

Same scenario, code का एक fraction:

• कोई while loop नहीं, कोई stop reason switch नहीं, कोई manually tool results को messages में push नहीं — runner यह सब handle करता है।
• कोई JSON schemas नहीं, तो आप चीजें दो बार नहीं लिखते।
• दोनों functions same lookups हैं जो हमने एक मिनट पहले manually run किए, बस plain TypeScript।
• runner. untilDone() final assistant message return करता है एक बार सब कुछ settle हो जाता है।

इसे run करें, और आपको same answer मिलता है।

Real tools आपके existing code को wrap करते हैं

Real life में, आपके tools hardcoded weather data नहीं होंगे। वे actual functions को wrap करेंगे जो आपके application में पहले से exist करते हैं।

एक compliance review agent लें: इसके tools lookup_building_code और search_building_code functions के around thin wrappers हैं जो पहले से codebase में exist करते हैं। Tool runner के साथ, आप उन functions को directly pass करते हैं, और agent हर finding में specific code sections cite करता है — कोई schema writing required नहीं:

एक compliance review app जो एक structural report को agent findings के साथ दिखाता है, प्रत्येक flagged item specific building code section को cite करता है जिसे यह check करता है

Recap

• Tools Claude को आपके systems तक पहुंच देते हैं। एक tool एक function है जिसे आप define करते हैं और expose करते हैं; Claude decide करता है कि इसे कब call करना है, और आपका code इसे execute करता है।
• Tools JSON schemas हैं जिनमें एक name, एक description, और एक input schema है, request में एक tools array के रूप में pass किया जाता है।
• Specific descriptions लिखें। Vague descriptions agents के misfire होने का number one कारण हैं।
• stop_reason: "tool_use" आपका signal है tool को run करने और result को एक tool result के रूप में वापस feed करने का।
• Multiple tools के लिए, tool name पर dispatch करें। एक tool add करने का मतलब array में add करना और एक case add करना है।
• SDK का tool runner (TypeScript, Python, Ruby) आपके actual functions से schemas build करता है और पूरे loop को handle करता है — या आप loop को खुद run कर सकते हैं।
• आप execute करते हैं, या आप loop को delegate करते हैं। उस spectrum के far end पर, managed agents पूरे agent को Anthropic को delegate करते हैं।