अपने एजेंट को डेटाबेस क्वेरी करने दें,
जब तक आप न कहें, रीड-ओनली
AgentsRoom आपके MySQL, PostgreSQL, SQL Server, MongoDB, SQLite और Google BigQuery कनेक्शन संभालता है और आपके AI कोडिंग एजेंट को उनके सामने क्वेरी चलाने का रास्ता देता है। डिफ़ॉल्ट रूप से रीड-ओनली, एक बार में एक स्टेटमेंट, और पासवर्ड पहुंच से बाहर।
जो एजेंट असली पंक्तियां पढ़ सकता है वह आपके डेटा के बारे में अंदाज़ा लगाना बंद कर देता है। जो एजेंट उनमें लिख नहीं सकता वह ऐसा जोखिम नहीं रह जाता जिसकी आपको लाइन-दर-लाइन निगरानी करनी पड़े।
AgentsRoom कैसे किसी प्राइवेट सबनेट के डेटाबेस तक पहुंचता है और किसी AI एजेंट की रीड-ओनली क्वेरी का जवाब देता है।
जो AI कोडिंग एजेंट आपका डेटा नहीं देख सकता वह उस स्कीमा के हिसाब से कोड लिखता है जिसकी उसने कल्पना की। वह एक कॉलम गढ़ लेता है, मान लेता है कि किसी enum के तीन मान हैं जबकि उसके सात हैं, और किसी बग की व्याख्या किसी पंक्ति के बजाय एक थ्योरी से करता है। उसे डेटाबेस कनेक्शन देना यह ठीक कर देता है, और यही किसी मददगार एजेंट को एक घटना में बदलने का सबसे तेज़ रास्ता भी है। AgentsRoom इसी तनाव के इर्द-गिर्द बना है।
आप अपने कनेक्शन ऐप में वैसे ही सहेजते हैं जैसे किसी भी डेटाबेस क्लाइंट में सहेजते : इंजन, होस्ट, पोर्ट, यूज़र, डेटाबेस, और TLS जब सर्वर उसकी अपेक्षा करता हो। अगर डेटाबेस खुले इंटरनेट से पहुंच में नहीं है, तो कनेक्शन किसी SSH सुरंग या किसी AWS SSM पोर्ट-फ़ॉरवर्डिंग सेशन से रूट होता है, उन्हीं SSH और SSM कनेक्शनों का इस्तेमाल करते हुए जो आपने पहले AgentsRoom में सहेजे हैं। इसी तरह प्राइवेट सबनेट में बैठा डेटाबेस ऐसी चीज़ बन जाता है जिसे आप उसे दुनिया के लिए खोले बिना क्वेरी कर सकते हैं।
हर कनेक्शन रीड-ओनली शुरू होता है। कोई SELECT चलता है। डेटा बदलने वाला स्टेटमेंट नहीं चलता, जब तक आप उस ख़ास कनेक्शन को राइटेबल न बना दें और कार्रवाई की पुष्टि न कर दें। प्रति कॉल केवल एक स्टेटमेंट स्वीकार होता है, इसलिए किसी सेमीकोलन के पीछे कुछ अतिरिक्त नहीं छिपता, और रिज़ल्ट सेट सीमित होते हैं ताकि कोई चौड़ी क्वेरी किसी एजेंट या किसी विंडो को भर न दे। किसी कनेक्शन को प्रोडक्शन के रूप में भी चिह्नित किया जा सकता है, जिससे पुष्टि गलती से देना और मुश्किल हो जाता है।
पढ़ना ही पूरा काम नहीं है। एक मशीन पर सहेजा गया कनेक्शन आपकी बाकी मशीनों पर भी दिखता है, इसलिए डेटाबेस एक बार सेट करना होता है, हर कंप्यूटर पर अलग-अलग नहीं। और किसी डेटाबेस को फ़ाइल में एक्सपोर्ट किया जा सकता है, फ़ाइल से वापस लाया जा सकता है, या उन्हीं सुरंगों से होकर सीधे दूसरे सर्वर पर कॉपी किया जा सकता है : वही काम जिनके लिए आपको पहले ऐप से बाहर जाना पड़ता था।
ऐसा डेटाबेस क्लाइंट जो मानकर चलता है कि एजेंट चला रहा है
MySQL, PostgreSQL, SQL Server, MongoDB, SQLite और Google BigQuery, सर्वर इंजन प्राइवेट नेटवर्क में भी पहुंच में, गार्डरेल डिफ़ॉल्ट रूप से चालू।
MySQL, PostgreSQL, SQL Server और MongoDB कनेक्शन
हर डेटाबेस के लिए एक कनेक्शन सहेजें : होस्ट, पोर्ट, यूज़र, खोलने वाला डेटाबेस और TLS जब सर्वर उसकी मांग करे। आपका लोकल डेटाबेस, स्टेजिंग वाला और प्रोडक्शन रेप्लिका सब एक ही सूची में रहते हैं, दोबारा टाइप करने के बजाय चुने जाने के लिए तैयार।
किसी प्राइवेट डेटाबेस तक पहुंचें
प्राइवेट सबनेट का डेटाबेस कोई ख़ास मामला नहीं है। कनेक्शन को किसी SSH सुरंग या किसी AWS SSM पोर्ट-फ़ॉरवर्डिंग सेशन से रूट करें और AgentsRoom उसे आपके लिए खोल देता है, उन्हीं SSH और SSM कनेक्शनों का दोबारा इस्तेमाल करते हुए जो आपने पहले ऐप में सहेजे हैं। Google Cloud SQL इंस्टेंस तक उसके कनेक्शन नाम से, Cloud SQL Auth Proxy के ज़रिए, आपके अपने gcloud लॉगिन से और कुछ भी सहेजे बिना पहुँचा जाता है।
डिफ़ॉल्ट रूप से रीड-ओनली
नया कनेक्शन पढ़ सकता है और कुछ नहीं। क्वेरी पंक्तियां लौटाती हैं, डेटा बदलने वाले स्टेटमेंट अस्वीकार होते हैं। सुरक्षित मोड चालू करना किसी को याद रखने की ज़रूरत नहीं, क्योंकि सुरक्षित मोड ही वह जगह है जहां हर कनेक्शन शुरू होता है।
किसी राइट से पहले दो ताले
लिखने में दो सोचे-समझे कदम लगते हैं, एक नहीं। कनेक्शन को राइटेबल बनाना पड़ता है, और कार्रवाई की खुद स्पष्ट पुष्टि करनी पड़ती है। एक लापरवाह क्लिक बिना WHERE क्लॉज़ वाले UPDATE तक नहीं पहुंच सकता।
प्रति कॉल एक स्टेटमेंट
हर कॉल में ठीक एक स्टेटमेंट होता है। किसी सेमीकोलन के पीछे लगाई गई कोई भी चीज़ चलाने के बजाय अस्वीकार कर दी जाती है, इसलिए जो रीड दिखती है वह अपने साथ चुपके से दूसरा स्टेटमेंट नहीं ला सकती। उसके ऊपर रिज़ल्ट सेट भी सीमित होते हैं।
प्रोडक्शन चिह्नित रहता है
किसी कनेक्शन को प्रोडक्शन के रूप में चिह्नित करें और पुष्टि कठिन हो जाती है। जो डेटाबेस मायने रखता है वह ठीक लोकल कॉपी जैसा दिखना बंद कर देता है, लंबे दिन के आख़िर में आपके लिए भी और किसी टास्क लिस्ट पर काम कर रहे एजेंट के लिए भी।
आपके कनेक्शन, हर मशीन पर
ऑफ़िस की मशीन पर सहेजा गया कनेक्शन लैपटॉप पर भी मौजूद रहता है : नाम, होस्ट, पोर्ट, यूज़र, डिफ़ॉल्ट डेटाबेस और वह सुरंग जिससे वह गुज़रता है। पीछे सिर्फ़ पासवर्ड रह जाता है, उसी मशीन पर एन्क्रिप्टेड जहां आपने उसे टाइप किया था, इसलिए हर मशीन आपसे उसे एक बार पूछती है।
एक्सपोर्ट, इम्पोर्ट, कॉपी
किसी डेटाबेस को .sql फ़ाइल में डंप करें, ऐसी फ़ाइल को किसी डेटाबेस में वापस चलाएं, या एक डेटाबेस को सीधे दूसरे के ऊपर कॉपी करें। ओवरराइट होने से पहले टारगेट का बैकअप ले लिया जाता है, और उसे पूरी तरह बदल देना अलग से पुष्टि किया जाने वाला अलग फ़ैसला है।
एजेंट डेटाबेस क्वेरी करते हैं, पासवर्ड उनके पास कभी नहीं होता
आपके डेटाबेस क्रेडेंशियल AgentsRoom के पास रहते हैं, बांटे नहीं जाते। कोई एजेंट किसी ऐसे कनेक्शन के सामने क्वेरी चलाने को कहता है जिसे वह नाम से जानता है, ऐप कनेक्शन खोलता है, स्टेटमेंट चलाता है और पंक्तियां लौटाता है। पासवर्ड न कभी उसका हिस्सा होता है जो एजेंट को मिलता है, न उस क्वेरी का जो वह लिखता है, और न उस बातचीत का जो वह रखता है।
रीड-ओनली नियम इसका दूसरा आधा हिस्सा है, और किसी एजेंट के लिए यह ऐसी चीज़ नहीं है जिससे वह बातों के सहारे निकल सके। एजेंट जिस टूल से क्वेरी करता है वह रीड के अलावा सब कुछ अस्वीकार करता है, जब तक दो बातें सच न हों: कनेक्शन राइटेबल हो, और आपने उस कनेक्शन के लिए "एजेंट को लिखने की अनुमति दें" चालू किया हो। यह विकल्प डिफ़ॉल्ट रूप से बंद रहता है, और जांच एजेंट के प्रोसेस में नहीं, डेस्कटॉप ऐप में होती है। कंसोल में आपके अपने राइट अब भी एक स्पष्ट पुष्टि मांगते हैं, जो कनेक्शन के प्रोडक्शन के रूप में चिह्नित होने पर जानबूझकर देना कठिन रखी जाती है। जब कोई कनेक्शन एजेंट के राइट के लिए खुल जाता है, तो वे राइट इस पुष्टि के बिना चलते हैं, इसलिए यह विकल्प उसी डेटाबेस के लिए रखें जिसके मामले में आप एजेंट पर भरोसा करते हों। बाक़ी हर जगह, किसी खराब क्वेरी का सबसे बुरा नतीजा एक गलत जवाब ही रहता है, न कि गायब हुई कोई टेबल।
एकल-स्टेटमेंट नियम वह पुरानी खिड़की बंद कर देता है। जिस कॉल में एक स्टेटमेंट है उसे किसी सेमीकोलन और दूसरे स्टेटमेंट से बढ़ाया नहीं जा सकता, इसलिए जो क्वेरी समीक्षा में निर्दोष पढ़ी जाती है वह चलते समय कुछ और नहीं कर सकती। SQL Server को उस सेमीकोलन की ज़रूरत नहीं होती, इसलिए वहां रीड का मतलब है एक SELECT या WITH, जिसमें कहीं भी कोई राइट या ट्रांज़ैक्शन कीवर्ड न हो, और वह एक ऐसे ट्रांज़ैक्शन के अंदर चलता है जिसे हमेशा रोलबैक कर दिया जाता है। सीमित रिज़ल्ट सेट के साथ मिलकर, गलती गलती ही रहती है, एक्सपोर्ट नहीं बन जाती।
छह इंजन, और जो नहीं हैं उनके नाम भी
MySQL और MariaDB, PostgreSQL, SQL Server (Azure SQL और Amazon RDS for SQL Server समेत), MongoDB, SQLite और Google BigQuery। हर एक का अपना अलग ड्राइवर है, कोई अनुवाद परत नहीं, क्योंकि इनमें फ़र्क़ सचमुच है : PostgreSQL या SQL Server का सेशन एक ही डेटाबेस से बंधा होता है, MongoDB SQL नहीं बल्कि एक क्वेरी लेता है, T-SQL में दो स्टेटमेंट के बीच सेमीकोलन ज़रूरी नहीं, हर एक्सपोर्ट उन्हीं टूल से चलता है जो उस इंजन के साथ आते हैं, SQLite बस आपके कंप्यूटर पर एक फ़ाइल है, बिना होस्ट, यूज़र या पासवर्ड के, और BigQuery कनेक्शन एक Google Cloud प्रोजेक्ट और एक डिफ़ॉल्ट डेटासेट होता है, जिसमें आप अपने खुद के Google लॉगिन (gcloud auth application-default login) से साइन इन करते हैं, और कोई कुंजी सहेजी नहीं जाती। चारों सर्वर इंजन तक सीधे पहुंचा जाता है, या किसी SSH सुरंग या किसी AWS SSM पोर्ट-फ़ॉरवर्डिंग सेशन के ज़रिए जब वे खुले इंटरनेट पर उपलब्ध न हों।
Oracle, Redis और बाकी समर्थित नहीं हैं। SQL Server पर आप SQL लॉगिन से साइन इन करते हैं (Windows, Active Directory और Entra ID प्रमाणीकरण उपलब्ध नहीं हैं), और कोई एक्सपोर्ट, इम्पोर्ट या कॉपी नहीं है। BigQuery पर Google हर क्वेरी का बिल उसके पढ़े गए बाइट्स के हिसाब से लेता है, इसलिए हर कनेक्शन पर प्रति क्वेरी बिलिंग की एक ऊपरी सीमा होती है (डिफ़ॉल्ट रूप से 1 GiB, बदली जा सकती है): इस सीमा से ऊपर जाने वाली क्वेरी पर शुल्क लगने के बजाय उसे अस्वीकार कर दिया जाता है। टेबल खोलना मुफ़्त और रीड-ओनली है, आपके एजेंट वही db_list, db_schema और db_query टूल उन्हीं गार्डरेल के साथ इस्तेमाल करते हैं और देखते हैं कि हर क्वेरी ने कितने बाइट्स पढ़े, और वहां भी कोई एक्सपोर्ट, इम्पोर्ट या कॉपी नहीं है। यह जानने का हक़ आपको डाउनलोड के बाद नहीं, उससे पहले है। अगला इंजन कौन सा आएगा यह इससे तय होता है कि लोग क्या मांगते हैं, इसलिए अगर आपका इंजन नहीं है, तो सार्वजनिक बैकलॉग पर बताएं कि कौन सा, और उसे गिना जाएगा।
अपना डेटाबेस इंजन मांगेंडेटाबेस को सिर्फ़ पढ़ें नहीं, कहीं और ले भी जाएं
किसी डेटाबेस को फ़ाइल में एक्सपोर्ट करें। किसी फ़ाइल को डेटाबेस में इम्पोर्ट करें। या एक डेटाबेस को सीधे दूसरे के ऊपर कॉपी करें, उस SSH सुरंग या AWS SSM सेशन से होकर भी जो आप पहले ही सहेज चुके हैं। हर इंजन अपने आधिकारिक टूल चलाता है और सब कुछ डिस्क पर स्ट्रीम में लिखा जाता है, इसलिए कई गीगाबाइट का डेटाबेस क्रैश नहीं, एक प्रोग्रेस बार बन जाता है।
ये टूल डेटाबेस के साथ आते हैं, AgentsRoom के साथ नहीं : mysqldump और mysql, pg_dump और psql, mongodump और mongorestore। SQL Server के पास ऐसा कोई समकक्ष नहीं है जो पूरे डेटाबेस को स्ट्रीम करे, इसलिए उसके कनेक्शनों में कोई एक्सपोर्ट, इम्पोर्ट या कॉपी नहीं है। जब ये टूल मशीन पर नहीं होते, ऐप ठीक-ठीक बताता है कि कौन से नहीं हैं और आपको उनका फ़ोल्डर दिखाने देता है, जैसा किसी डेटाबेस क्लाइंट को करना चाहिए : Dock या स्टार्ट मेन्यू से चलाए गए ऐप को बस एक न्यूनतम PATH दिखता है, और वरना वह उन्हीं मशीनों पर उन टूल के गायब होने का दावा करता रहता जिनमें वे मौजूद हैं।
एक गलत क्लिक जहां पूरा दिन ले डूबता है, वह जगह कॉपी है, इसलिए इसे उसी को ध्यान में रखकर बनाया गया है, न कि सब कुछ ठीक चलने वाली स्थिति को।
- रीड-ओनली कनेक्शन इम्पोर्ट को सीधे मना कर देता है, कुछ भी खुलने से पहले ही।
- पहला स्टेटमेंट लागू होने से पहले ही टारगेट डेटाबेस आपकी चुनी हुई फ़ाइल में डंप कर लिया जाता है।
- पुष्टि में कनेक्शन और डेटाबेस दोनों का नाम लिखा होता है, और कनेक्शन प्रोडक्शन के रूप में चिह्नित हो तो वह और ज़ोर से कहती है।
- टारगेट डेटाबेस को हटाकर दोबारा बनाना एक अलग विकल्प है, और प्रोडक्शन कनेक्शन पर आपको डेटाबेस का नाम खुद टाइप करना पड़ता है।
किसी प्राइवेट डेटाबेस से एक जवाब तक
कनेक्शन सहेजें, उसे रूट करें, फिर उसे क्वेरी करें या किसी एजेंट से करवाएं।
कनेक्शन सहेजें
डेटाबेस जोड़ें : होस्ट, पोर्ट, यूज़र, डेटाबेस का नाम, और TLS अगर सर्वर उसकी अपेक्षा करता हो। उसे ऐसा नाम दें जिसे आप बाद में पहचान लें, और अगर वह प्रोडक्शन है तो उसे वैसा चिह्नित करें।
अगर वह प्राइवेट है तो उसे रूट करें
अगर डेटाबेस सीधे पहुंच में नहीं है, तो कनेक्शन को किसी SSH सुरंग या किसी AWS SSM पोर्ट-फ़ॉरवर्डिंग सेशन की ओर इंगित करें, जो पहले से AgentsRoom में सहेजे कनेक्शनों से बना हो। प्राइवेट सबनेट का डेटाबेस उसे सार्वजनिक किए बिना पहुंच में आ जाता है। Google Cloud पर इसकी जगह Cloud SQL इंस्टेंस चुनें: AgentsRoom आपके लिए Cloud SQL Auth Proxy शुरू कर देता है।
उसे क्वेरी करें, या किसी एजेंट से क्वेरी करवाएं
अपना स्टेटमेंट ऐप से चलाएं, या किसी एजेंट को MCP पर चलाने दें। जब तक आप न बदलें तब तक रीड-ओनली, प्रति कॉल एक स्टेटमेंट, सीमित रिज़ल्ट सेट, और हर राइट तथा आपके डेटा के बीच खड़ी एक स्पष्ट पुष्टि।
जब किसी एजेंट को असली पंक्तियां चाहिए
वे पल जब प्रोडक्शन डेटा पढ़ना समाधान तक का सबसे छोटा रास्ता है।
असली डेटा के सामने डीबग करें
बग सिर्फ़ कुछ ही अकाउंट के लिए दिखता है। एजेंट को वे पंक्तियां पढ़ने दें और वह वह मान ढूंढ लेता है जो लॉजिक तोड़ता है, बजाय इसके कि डेटा कैसा हो सकता है इस पर तीन थ्योरी सुझाए।
ऐसा डेटाबेस जो सार्वजनिक नहीं है
डेटाबेस बिना किसी सार्वजनिक एंडपॉइंट के एक प्राइवेट सबनेट में रहता है। कनेक्शन को अपने सहेजे कनेक्शनों पर बनी किसी SSH सुरंग या किसी AWS SSM सेशन से रूट करें, और इंटरनेट के लिए कोई पोर्ट खोले बिना उसे क्वेरी करें।
एजेंट को जांचने दें, अंदाज़ा लगाने नहीं
कोई माइग्रेशन या कोई क्वेरी लिखने से पहले एजेंट देख सकता है कि सचमुच क्या संग्रहीत है। वह पढ़ता है, वह बताता है, और जब तक आपने उस कनेक्शन को एजेंट के राइट के लिए नहीं खोला है, ऐसा करते हुए उसके पास कुछ भी बदलने का कोई रास्ता नहीं होता।
प्रोडक्शन, बिना राइट के जोखिम के
प्रोडक्शन पढ़ना अक्सर ज़रूरी होता है, किसी काम के बीच उसमें लिखना लगभग कभी नहीं। कनेक्शन को प्रोडक्शन के रूप में चिह्नित करें, उसे रीड-ओनली रखें, और जांच करने तथा तोड़ देने के बीच का फ़र्क़ किसी के ध्यान देने पर निर्भर रहना बंद कर देता है।
स्टेजिंग को असली डेटा से ताज़ा करें
बग सिर्फ़ असली पंक्तियों पर ही दोहराता है। पहले से सहेजी सुरंग से होकर डेटाबेस को अपने स्टेजिंग सर्वर पर कॉपी करें, वहां जो पहले से था उसका डंप पहले ले लिया जाता है।
लैपटॉप खोलिए, सब कुछ वहीं है
आपके कनेक्शन आपके अकाउंट के साथ चलते हैं: वही होस्ट, वही सुरंगें, वही रीड-ओनली और प्रोडक्शन के निशान। सिंक किए गए पासवर्ड चालू हों तो पासवर्ड भी साथ चलते हैं, एंड-टू-एंड एन्क्रिप्टेड, इसलिए कुछ भी दोबारा टाइप नहीं करना पड़ता; इसके बिना हर मशीन पासवर्ड एक बार मांगती है।
मेरे एजेंट डेटाबेस कैसे क्वेरी करते हैं?
AgentsRoom MCP के ज़रिए, चार टूल के साथ। db_list आपके सहेजे गए कनेक्शन और उनका मेटाडेटा लौटाता है, db_schema एक लाइन SQL के बिना स्कीमा, टेबल और कॉलम में घूमता है, db_query एक स्टेटमेंट चलाता है और पंक्तियां लौटाता है, और db_connection_new ऐसा डेटाबेस सुझाता है जिसे आपने अभी तक सहेजा नहीं है। AgentsRoom कनेक्शन खोलता है, जिसमें उसके आगे की SSH सुरंग या AWS SSM सेशन भी शामिल है अगर कोई हो। एजेंट तक जो वापस जाता है वह एक रिज़ल्ट सेट है, कोई क्रेडेंशियल कभी नहीं।
एजेंट तभी लिख सकते हैं जब आप किसी ऐसे कनेक्शन पर "एजेंट को लिखने की अनुमति दें" चालू करें जो राइटेबल भी हो। यह ऑप्ट-इन विकल्प डिफ़ॉल्ट रूप से बंद रहता है और आपके खाते में कनेक्शन के साथ सिंक होता है। चालू होने के बाद राइट तुरंत चलते हैं, इसलिए इसे तभी इस्तेमाल करें जब आप उस डेटाबेस के मामले में एजेंट पर भरोसा करते हों। डेस्कटॉप यह अनुमति अपने मुख्य प्रोसेस में जांचता है, और db_query अब भी हर कॉल में सिर्फ़ एक स्टेटमेंट स्वीकार करता है।
किसी डेटाबेस को दर्ज करना पूरी तरह एजेंट का काम भी हो सकता है। db_connection_new समीक्षा वाले रास्ते को बनाए रखता है: वह बनाने का फ़ॉर्म उस होस्ट, यूज़र और उस SSH या AWS SSM कनेक्शन से पहले से भरा हुआ खोलता है जिसके ज़रिए उस तक पहुंचा जाना चाहिए, और उसकी समीक्षा आप करते हैं, पासवर्ड आप टाइप करते हैं और आप ही सहेजते हैं, जब तक आप ऐसा न करें तब तक कुछ भी संग्रहीत नहीं होता। जब तक आप "एजेंट कनेक्शन प्रबंधित कर सकते हैं" (सेटिंग्स, डिफ़ॉल्ट रूप से चालू) को बंद न कर दें, db_connection_save कनेक्शन सीधे लिख देता है, और पासवर्ड फिर भी कभी बातचीत से नहीं गुज़रता: वह आपके वॉल्ट के उस सीक्रेट से कॉपी होता है जिसका नाम एजेंट लेता है। एजेंट को वह मिलता है जो उसे आपके डेटा के बारे में सोचने के लिए चाहिए, और वे सारे रास्ते जिनसे यह एक्सेस आम तौर पर एक घटना बन जाता है, उसके लिए उपलब्ध ही नहीं हैं।
एजेंट की हर क्वेरी भी दिखती है। db_query और db_schema कॉल दाएं पैनल के "गतिविधि" टैब में आती हैं, SQL और लौटी पहली पंक्तियों के साथ, हर डेटाबेस के लिए अलग लॉग में; एजेंट का अवतार "डेटाबेस" बटन पर और, "एजेंट काम पर" बैज के साथ, आपकी डेटाबेस सूची में दिखता है। आप इसे अपने फ़ोन पर भी, मोबाइल ऐप में एजेंट के कार्ड में देख सकते हैं। यह लॉग सिर्फ़ आपके कंप्यूटर और आपके फ़ोन के बीच जाता है, एंड-टू-एंड एन्क्रिप्टेड और सीक्रेट छिपाकर: कोई भी रिज़ल्ट सेट किसी सर्वर पर सेव नहीं होता।
AgentsRoom MCP देखेंवही "गतिविधि" टैब जो आपकी db_query और db_schema कॉल सूचीबद्ध करता है, यहां एक सहेजे गए SSH सर्वर पर फ़िल्माया गया : एक एजेंट तीन कमांड चलाता है, हर एक अपने आउटपुट, अपने एग्ज़िट कोड और अपनी अवधि के साथ आती है, फिर उस कनेक्शन का लॉग पूरा खुलता है। यह लॉग आपके कंप्यूटर पर ही रहता है।
अक्सर पूछे जाने वाले सवाल
हमसे कुछ और पूछेंकौन से डेटाबेस समर्थित हैं?
क्या कोई AI एजेंट मेरे डेटाबेस में लिख सकता है?
मैं किसी प्राइवेट सबनेट के डेटाबेस तक कैसे पहुंचूं?
क्या मेरे एजेंट डेटाबेस पासवर्ड देखते हैं?
क्या कोई एजेंट एक साथ कई स्टेटमेंट चला सकता है?
किसी कनेक्शन को प्रोडक्शन के रूप में चिह्नित करने से क्या बदलता है?
अगर कोई क्वेरी बहुत सारी पंक्तियां लौटाए तो क्या होता है?
क्या कोई एजेंट डेटाबेस कनेक्शन जोड़ सकता है?
कोई एजेंट मेरा स्कीमा कैसे जानता है?
क्या मेरे डेटाबेस कनेक्शन मेरी मशीनों के बीच सिंक होते हैं?
क्या मैं किसी डेटाबेस को डंप करके कहीं और इम्पोर्ट कर सकता हूं?
मेरे कनेक्शन रखने वाला अकाउंट कैसे सुरक्षित है?
स्क्रीनशॉट
ऐप के असली स्क्रीनशॉट, जो इस फ़ीचर के विकास के साथ जोड़े जाते हैं।
अपने स्वयं के Google लॉगिन के साथ Google BigQuery कनेक्ट करें 
प्रति कनेक्शन एक BigQuery क्वेरी कितना बिल कर सकती है, इसकी सीमा निर्धारित करें 
डायरेक्ट TLS कनेक्शन सर्वर प्रमाणपत्र को सत्यापित करते हैं, स्व-हस्ताक्षरित सर्वरों के लिए ऑप्ट-इन के साथ
आपको यह भी पसंद आ सकता है
AWS SSM के ज़रिए RDS
ऐसे Amazon RDS इंस्टेंस तक अपनी ही मशीन से पहुंचें जिसका कोई पब्लिक एंडपॉइंट नहीं है, aws ssm start-session और AWS-StartPortForwardingSessionToRemoteHost डॉक्यूमेंट के ज़रिए। रखरखाव के लिए कोई bastion नहीं, कोई VPN नहीं, कोई इनबाउंड SSH नियम नहीं। AgentsRoom सेशन को एक loopback पोर्ट पर खोलता है और अपना डेटाबेस क्लाइंट उसी से जोड़ता है। MySQL, PostgreSQL, SQL Server और MongoDB, यानी RDS MySQL, RDS PostgreSQL, RDS for SQL Server, Aurora और DocumentDB।
Cloud SQL Auth Proxy
MySQL या PostgreSQL के Cloud SQL इंस्टेंस तक अपनी ही मशीन से पहुंचें, प्राइवेट IP समेत, बिना bastion VM के। AgentsRoom आपके gcloud Application Default Credentials के साथ Cloud SQL Auth Proxy को एक loopback पोर्ट पर चलाता है, IAM डेटाबेस ऑथेंटिकेशन को सपोर्ट करता है, और AI एजेंट को उसे रीड-ओनली क्वेरी करने देता है।
SSH कनेक्शन
अपने SSH कनेक्शन सहेजें, बिल्ट-इन SSH टर्मिनल खोलें, और Claude Code, Codex या Antigravity CLI को सीधे अपने रिमोट सर्वर या VPS पर चलाएं। SSH की या पासवर्ड से प्रमाणीकरण, प्रति-प्रोजेक्ट कनेक्शन प्रोफ़ाइल, बिना किसी अलग SSH क्लाइंट के।
सीक्रेट मैनेजर
API की, टोकन और पासवर्ड अपने OS कीचेन में रखें, उन्हें डेव कमांड और एजेंट परिवेश में {{secret:NAME}} के रूप में रेफ़र करें, और AgentsRoom को लॉन्च के समय उन्हें हल करने दें। एजेंट नाम देखते हैं, मान कभी नहीं, और कुछ भी किसी सर्वर पर सिंक नहीं होता।
डेव टर्मिनल
प्रति-प्रोजेक्ट टर्मिनल मैनेजर और प्रोसेस लॉन्चर। बैकएंड, फ्रंटएंड और वर्कर्स को एक क्लिक में शुरू करें, लोकल या किसी रिमोट सर्वर पर।
AgentsRoom MCP
वह MCP सर्वर जो आपके एजेंट को खुद AgentsRoom चलाने देता है : प्रोजेक्ट, टर्मिनल, बैकलॉग और कनेक्शन, साथ आने वाले गार्डरेल समेत।
अपने एजेंट को डेटा दें, की नहीं
AgentsRoom डाउनलोड करें, अपने MySQL, PostgreSQL, SQL Server, MongoDB, SQLite और Google BigQuery कनेक्शन सहेजें, सर्वर वाले कनेक्शनों तक किसी SSH सुरंग या किसी AWS SSM सेशन के ज़रिए पहुंचें, और अपने एजेंट को उन्हें क्वेरी करने दें, रीड-ओनली, जब तक आप किसी कनेक्शन को उनके राइट के लिए नहीं खोलते।
कंपेनियन ऐप: चलते-फिरते अपने एजेंट्स मॉनिटर करें
Claude, Codex, Antigravity CLI या किसी अन्य AI प्रदाता का उपयोग करें।
बग और अनुरोध सीधे अपने सार्वजनिक बैकलॉग में भेजें।
ऐसे एजेंट जिन्हें आप बातचीत की तरह पढ़ते हैं
हर एजेंट की एक भूमिका, एक चेहरा और एक थ्रेड है, जिसे आप मैसेजिंग ऐप की तरह पढ़ते हैं।
