हर agent में अलग-अलग tool जोड़ने की बजाय toolbox
Toolbox Foundry में tools का एक चुना हुआ सेट है, जिसे एक Model Context Protocol (MCP) endpoint से दिखाया जाता है। Agents हर MCP server, OpenAPI API, या search tool को अलग से सेट करने की बजाय उसी endpoint से जुड़ते हैं। आप tools एक बार परिभाषित करते हैं, project connections पर credentials रखते हैं, और वही toolbox prompt agents, hosted agents, और दूसरे MCP-compatible runtimes में दोबारा इस्तेमाल कर सकते हैं।
अवधारणा 7 में आपने सीधे prompt agent पर अलग-अलग tools लगाए। छोटे tool set और एक agent के लिए यह ठीक है। जैसे-जैसे agents बढ़ते हैं, टीमें अक्सर वही integrations कॉपी करती हैं, secrets अलग-अलग जगह रखती हैं, और tool endpoint बदलते ही agent अपडेट भेजती हैं। Toolbox यह काम एक जगह लाता है: tools को केंद्र से जोड़ें या version करें, जाँचा हुआ version default बनाएँ, और consumer endpoint पर पहले से जुड़े agents को code redeploy किए बिना बदलाव मिल जाता है। Microsoft चेतावनी देता है कि non-Foundry tools से लागत बढ़ सकती है और डेटा Foundry की compliance boundary के बाहर जा सकता है, इसलिए जोड़ने से पहले हर tool की शर्तें पढ़ें।
Toolbox में क्या-क्या हो सकता है
आप एक toolbox version में एक या ज़्यादा tools (और preview में skills) बनाते हैं। हर tool के लिए साफ़ description ज़रूरी है ताकि model सही tool चुन सके। web search, Azure AI Search, code interpreter, और file search जैसे built-in types बिना अलग name के toolbox में ज़्यादा से ज़्यादा एक बार आ सकते हैं; दो index चाहिए तो हर Azure AI Search entry को अलग name दें। tool search सिर्फ़ toolbox के अंदर मिलता है: बड़े collection में agents को सही tools ढूँढने में मदद करता है, और Foundry की toolbox overview में इसे preview लिखा है।
- Custom APIs और partner services के लिए MCP servers और OpenAPI specs।
- Retrieval और grounding के लिए Azure AI Search, file search, और web search।
- Sandboxed Python के लिए code interpreter, और जहाँ region और model सपोर्ट करें वहाँ browser automation।
- खास data और Microsoft 365 context के लिए agent-to-agent (A2A) tools, Fabric IQ, और Work IQ।
- Preview skills, जो MCP resources के रूप में reusable multi-step workflows देते हैं।
| Tool type | Toolbox के अंदर | सीधे agent पर attach |
|---|---|---|
| MCP, OpenAPI, Azure AI Search, file search | हाँ | हाँ |
| Tool search | हाँ | नहीं |
| Skills | हाँ | नहीं |
| Function calling (आपके app में चलता है) | नहीं | हाँ |
Versions बनाना और agents को जोड़ना
Toolbox version अपने tool list और optional guardrail policy का बदला न जाने वाला snapshot है। पहला publish किया गया version अपने आप default बन जाता है। बाद के बदलाव नए versions बनाते हैं; version-specific MCP URL से परीक्षण करें, फिर जिस version पर भरोसा हो उसे default promote करें ताकि production agents को endpoint string बदले बिना switch मिल जाए।
- Microsoft Foundry Toolkit for Visual Studio Code में Activity Bar पर Foundry Toolkit खोलें, My Resources > Tools के तहत project expand करें, और Build a Custom Toolbox tab पर + Add Toolbox इस्तेमाल करें—या SDK / Azure Developer CLI से version बनाएँ।
- Credentials वाले tools के लिए पहले project connections register करें; toolbox connections को name से refer करता है और definition में secrets embed नहीं करता।
- Toolboxes tab की Endpoint URL column से toolbox consumer endpoint कॉपी करें; यह हमेशा मौजूदा default version serve करता है।
- URL में /versions/{version}/mcp वाला developer pattern तब इस्तेमाल करें जब promotion से पहले tools list करके एक tool call से version verify करना हो।
- Hosted agents Python में FoundryToolbox या .NET में AddFoundryToolboxes से जोड़ें; consumer endpoint दें (या runtime पर TOOLBOX_ENDPOINT inject होने दें)।
- Production से पहले MCP से tools list करें और हर entry में name, description, और input schema हो—खाली list अक्सर गलत connection credentials या अभी provision हो रहे toolbox की निशानी है।
Foundry project पर Foundry User role उस developer identity को दें जो toolbox versions manage करती है, और agent identity को जो runtime पर tools कॉल करती है। End users को यह role तभी चाहिए जब OAuth या user Entra token flows उनकी identity tool तक भेजें। Tool availability project region और model पर भी निर्भर करती है; deploy से पहले दोनों जाँच लें।
Authentication connections पर, agent code में नहीं
हर tool call में दो identities होती हैं। Agent identity Foundry से authenticate करके toolbox MCP endpoint खोलती है। Downstream data call के लिए Foundry project connection से credentials inject करता है—API keys, project managed identity, agent की अपनी identity, या signed-in user का token। Authentication type portal में या azd ai connection create से connection बनाते समय चुनते हैं, agent के business logic के अंदर नहीं।
| Auth type | Tool तक किसकी identity पहुँचती है | आम इस्तेमाल |
|---|---|---|
| none | Anonymous | Public MCP servers |
| custom-keys | Connection पर stored shared key या header | Key-based SaaS APIs |
| project-managed-identity | Project की managed identity | User context के बिना service-to-service calls |
| agentic-identity | Agent की identity | Per-agent least privilege और audit |
| oauth2 | OAuth पूरा करने वाला user | OAuth-compliant MCP और Work IQ |
| user-entra-token | Signed-in Entra user | Audience-specific Entra token चाहने वाली Microsoft services |
- Hosted agents पर OAuth identity passthrough के लिए FoundryToolbox या AddFoundryToolboxes इस्तेमाल करें ताकि platform मौजूदा call context आगे भेजे; users के बीच call ID hard-code या reuse न करें।
- OAuth passthrough वाले agents के consumers को कम से कम Foundry Agent Consumer role चाहिए; user का Entra tenant Foundry project tenant से मेल खाना चाहिए।
- MCP tools पर optional require_approval metadata agent runtime को देता है; always पर runtime को user से पूछना होगा—MCP endpoint खुद call block नहीं करता।
Governance, guardrails, और सुरक्षित tool use
Traffic toolbox से गुज़रता है, इसलिए आप toolbox version पर named guardrail policy लगा सकते हैं ताकि responsible AI filtering tool inputs और outputs पर model-level filters से अलग चले। Optional AI gateway (preview) भी है: Foundry portal में बने नए MCP tools—जो managed OAuth नहीं इस्तेमाल करते—Azure API Management से rate limits, IP restrictions, और centralized logging के लिए गुज़र सकते हैं। Gateway routing tool बनाते समय लगता है; पुराने tools तब तक सीधे MCP server को call कर सकते हैं जब तक आप उन्हें दोबारा न बनाएँ।
- हर tool response को untrusted input मानें; consequential action से पहले structured fields validate करें।
- Agent instructions में हर tool का नाम, कब इस्तेमाल करें, और fail होने पर क्या करें—tool best practices जैसा।
- Deterministic behavior के लिए tool_choice: none (turn पर tools बंद), auto (model decide), या required (tool call ज़रूरी)।
- Traces देखें (अवधारणा 13 विस्तार में) कि कौन से tools चले और खाली परिणाम description की वजह से हैं या data की।
Toolbox में बहुत समान tools हों तो instructions में decision rules जोड़ें (उदाहरण: web search से पहले internal indexes search करें)। ज़रूरी tools pin करें या tool search (preview) चालू करें ताकि हर request पर सैकड़ों पूरी tool definitions model को न भेजी जाएँ।
Toolbox के अंदर knowledge और retrieval
Retrieval tools model के जवाबों को आपके content पर आधारित करते हैं। अवधारणा 6 में file upload और Azure AI Search विस्तार से था; यहाँ फोकस shared toolbox में चुनाव और platform knowledge features के साथ मिलान पर है। file search model tokens से अलग bill होता है। Private virtual network वाले Azure AI Search connections project managed identity से authenticate करें—key-based auth वहाँ support नहीं। Foundry IQ managed knowledge base agentic retrieval देता है, capability reference में private networking support लिखा है। Memory (preview) sessions के बीच persistent memory देता है—preview मानें और enable करने से पहले retention और access तय करें।
| विकल्प | सबसे अच्छा कब | आप क्या manage करते हैं |
|---|---|---|
| File search | Project में upload किए गए मध्यम document set | Vector stores, uploads, ingestion status |
| Azure AI Search tool | पहले से scale पर indexed content, filters और hybrid queries | Indexes, connections, citations के लिए index fields |
| Foundry IQ | Agentic retrieval वाला managed knowledge base | Raw index wiring की बजाय Foundry IQ में knowledge base configuration |
| Memory (preview) | Context जो sessions के बीच रहना चाहिए | Preview policies: कौन stored memory पढ़ सकता है और कितनी देर |
- Uploaded FAQs और बड़े catalog index दोनों चाहिए तो file search और Azure AI Search एक toolbox में रखें; हर search tool को अलग name और description दें।
- Retrieval wire करने के बाद evaluation की योजना बनाएँ: अवधारणा 14 groundedness और retrieval evaluators cover करती है।
- Non-Microsoft MCP servers जोड़ते समय production से पहले toolbox documentation में data-handling notes पढ़ें।
उदाहरण, गलतियाँ, और अगले चरण
एक retail company का internal IT helper सोचें। आप toolbox version बनाते हैं: hardware catalog index पर Azure AI Search, OAuth connection से ticket API की ओर intranet नाम का MCP tool, public firmware advisories के लिए web search, और tool search (preview) क्योंकि बाद में और teams tools जोड़ेंगी। version-specific MCP URL से परीक्षण करते हैं, version 2 को default promote करते हैं, और hosted agent सिर्फ़ consumer endpoint पर point करता है। Instructions कहते हैं catalog search ticket खोलने से पहले करें, और account settings बदलने वाले MCP actions पर employee से approval लें। जवाब गलत लगें तो index content सुधारें और model alone tweak करने की बजाय अवधारणा 14 के retrieval evaluators चलाएँ।
- एक version में duplicate unnamed built-in tools invalid payload error देते हैं—दो indexes या दो web search configs चाहिए तो unique names दें।
- MCP initialize skip करके tools/list करने पर बाद की calls fail होती हैं; manual verify में हमेशा session initialize करें।
- User consent के बिना OAuth काम करेगा मानना consent-required errors छोड़ देता है जब तक user flow पूरा न करे।
- Model या region support न करे तो tool deploy करने पर tool-not-supported errors आते हैं, भले global feature table में tool listed हो।
- Retention plan के बिना Memory (preview) sensitive session context policy से ज़्यादा देर रख सकता है।
अवधारणा 13 production में हर tool call follow करने के लिए observability और tracing पर जाती है। तब तक MCP list और call checks से toolbox versions verify करें, connections और descriptions अपडेट रखें, और version-specific test pass होने के बाद ही default promote करें।
- Toolbox versions बनाने, MCP endpoints कॉपी करने, tools verify करने, और default promote करने के पूरे चरण। Create and manage a toolbox in Foundry
- Connections auth types कैसे ले जाते हैं और hosted agents के लिए OAuth passthrough कैसे काम करता है। How toolbox authentication works in Microsoft Foundry
- Instructions, tool_choice, security practices, और जब agents tools skip करें troubleshooting। Tool best practices for Microsoft Foundry Agent Service
- Eligible MCP tools को rate limits, IP filters, और audit logging के लिए AI gateway से route करें। Govern MCP tools by using an AI gateway (preview)