Databases | The .NET Blog

SQL MCP Server — AI एजेंट्स को डेटाबेस एक्सेस देने का सही तरीका

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

सच बात करें तो: आज उपलब्ध अधिकांश database MCP servers डरावने हैं। वे एक natural language query लेते हैं, तुरंत SQL generate करते हैं, और उसे आपके production data पर चला देते हैं। क्या गलत हो सकता है? (सब कुछ। सब कुछ गलत हो सकता है।)

Azure SQL टीम ने अभी SQL MCP Server पेश किया, और यह एक मौलिक रूप से अलग दृष्टिकोण अपनाता है। Data API builder (DAB) 2.0 की एक feature के रूप में बना, यह AI एजेंट्स को database operations तक structured, निर्धारित access देता है — NL2SQL के बिना, आपका schema उजागर किए बिना, और हर कदम पर पूरे RBAC के साथ।

NL2SQL क्यों नहीं?

यह सबसे दिलचस्प design निर्णय है। Models निर्धारित नहीं होते, और complex queries में सूक्ष्म त्रुटियाँ पैदा होने की सबसे अधिक संभावना होती है। जो queries उपयोगकर्ता AI से generate करवाना चाहते हैं, वही non-deterministic तरीके से produce होने पर सबसे अधिक जाँच की माँग करती हैं।

इसके बजाय, SQL MCP Server एक NL2DAB दृष्टिकोण अपनाता है। एजेंट Data API builder की entity abstraction layer और built-in query builder के साथ काम करता है ताकि accurate, well-formed T-SQL निर्धारित रूप से produce की जा सके। उपयोगकर्ता के लिए परिणाम वही रहता है, लेकिन hallucinated JOINs या accidental data exposure का जोखिम नहीं रहता।

सात tools, सात सौ नहीं

SQL MCP Server database के आकार चाहे जो हो, ठीक सात DML tools expose करता है:

describe_entities — उपलब्ध entities और operations खोजें
create_record — rows insert करें
read_records — tables और views query करें
update_record — rows modify करें
delete_record — rows हटाएं
execute_entity — stored procedures चलाएं
aggregate_records — aggregation queries

यह समझदारी है क्योंकि context windows एजेंट की सोचने की जगह हैं। सैकड़ों tool definitions से भर देने पर reasoning के लिए कम जगह बचती है। सात fixed tools एजेंट को navigate करने की बजाय सोचने पर केंद्रित रखते हैं।

प्रत्येक tool को individually enable या disable किया जा सकता है:

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

तीन commands में शुरुआत

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

बस, आपका SQL MCP Server आपकी Customers table expose कर के चल पड़ा। Entity abstraction layer का मतलब है कि आप नाम और columns को alias कर सकते हैं, प्रत्येक role के लिए fields सीमित कर सकते हैं, और ठीक वही नियंत्रित कर सकते हैं जो एजेंट देखता है — बिना internal schema की जानकारी उजागर किए।

Security की कहानी पक्की है

यहीं Data API builder की परिपक्वता काम आती है:

हर layer पर RBAC — प्रत्येक entity परिभाषित करती है कि कौन से roles read, create, update, या delete कर सकते हैं, और कौन से fields दिखते हैं
Azure Key Vault integration — connection strings और secrets सुरक्षित रूप से manage होते हैं
Microsoft Entra + custom OAuth — production-grade authentication
Content Security Policy — एजेंट raw SQL के बजाय एक controlled contract के माध्यम से interact करते हैं

Schema abstraction विशेष रूप से महत्वपूर्ण है। आपके internal table और column names एजेंट को कभी नहीं दिखते। आप entities, aliases, और descriptions परिभाषित करते हैं जो AI interaction के लिए उचित हों — आपके database ERD के लिए नहीं।

Multi-database और multi-protocol

SQL MCP Server Microsoft SQL, PostgreSQL, Azure Cosmos DB, और MySQL को support करता है। और क्योंकि यह एक DAB feature है, आपको एक ही configuration से REST, GraphQL, और MCP endpoints एक साथ मिलते हैं। वही entity definitions, वही RBAC rules, वही security — तीनों protocols में।

DAB 2.0 में auto-configuration आपके database को inspect करके dynamically configuration बना सकती है, अगर आप rapid prototyping के लिए कम abstraction से comfortable हैं।

मेरा नजरिया

AI एजेंट्स के लिए enterprise database access इसी तरह काम करनी चाहिए। “अरे LLM, मेरे लिए कुछ SQL लिखो और production पर चला दो” वाला तरीका नहीं। बल्कि: एक well-defined entity layer, deterministic query generation, हर कदम पर RBAC, caching, monitoring, और telemetry। यह सबसे अच्छे अर्थ में उबाऊ है।

.NET डेवलपर्स के लिए, integration की कहानी साफ है — DAB एक .NET tool है, MCP Server एक container के रूप में चलता है, और यह Azure SQL के साथ काम करता है, जिसे हम में से अधिकांश पहले से उपयोग कर रहे हैं। अगर आप ऐसे AI एजेंट्स बना रहे हैं जिन्हें data access चाहिए, तो यहाँ से शुरू करें।

अंतिम बात

SQL MCP Server मुफ्त, open-source है, और कहीं भी चलता है। यह Microsoft की तरफ से AI एजेंट्स को सुरक्षित database access देने का prescriptive तरीका है। शुरुआत करने के लिए पूरी पोस्ट और documentation देखें।

SQL MCP Server, SSMS में Copilot, और AI Agents के साथ Database Hub: SQLCon 2026 की असली ज़रूरी बातें

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

यह पोस्ट स्वचालित रूप से अनुवादित है। मूल के लिए, यहाँ क्लिक करें.

Microsoft ने अभी SQLCon 2026 को FabCon के साथ Atlanta में शुरू किया, और इसमें काफी कुछ है जिसे समझना ज़रूरी है। मूल घोषणा में savings plans से लेकर enterprise compliance features तक सब कुछ शामिल है। मैं enterprise pricing की slides को छोड़ रहा हूँ और उन बातों पर ध्यान केंद्रित कर रहा हूँ जो एक developer के लिए Azure SQL और AI के साथ कुछ बनाते समय वास्तव में मायने रखती हैं।

SQL MCP Server public preview में है

यह मेरे लिए सबसे बड़ी खबर है। Azure SQL Database Hyperscale में अब SQL MCP Server public preview में उपलब्ध है, जो आपको Model Context Protocol का उपयोग करके अपने SQL डेटा को AI agents और Copilots से सुरक्षित रूप से जोड़ने की सुविधा देता है।

अगर आप MCP की लहर को फॉलो कर रहे हैं — और सच कहूँ तो, इसे नज़रअंदाज़ करना अभी मुश्किल है — तो यह एक बड़ी बात है। अपने AI agents को database का context देने के लिए custom data pipelines बनाने की बजाय, आपको SQL डेटा को सीधे expose करने के लिए एक standardized protocol मिलता है। आपके agents live database की जानकारी को query कर सकते हैं, उस पर reasoning कर सकते हैं और action ले सकते हैं।

जो लोग Semantic Kernel या Microsoft Agent Framework के साथ AI agents बना रहे हैं, उनके लिए यह एक clean integration path खोलता है। आपके agent को inventory चेक करनी है? कोई customer record देखना है? किसी order को validate करना है? MCP इसके लिए एक structured तरीका देता है, बिना हर scenario के लिए bespoke data-fetching code लिखे।

SSMS 22 में GitHub Copilot अब GA है

अगर आप SQL Server Management Studio में समय बिताते हैं — और सच कहूँ तो, हम में से अधिकतर अभी भी करते हैं — तो GitHub Copilot अब SSMS 22 में generally available है। वही Copilot experience जो आप VS Code और Visual Studio में पहले से उपयोग करते हैं, लेकिन T-SQL के लिए।

यहाँ व्यावहारिक मूल्य सीधा है: queries लिखने, stored procedures को refactor करने, performance issues को troubleshoot करने और admin tasks संभालने के लिए chat-based assistance। अवधारणा में कुछ क्रांतिकारी नहीं है, लेकिन इसका SSMS में सीधे होना मतलब है कि database काम के लिए AI सहायता पाने के लिए आपको किसी दूसरे editor पर switch नहीं करना पड़ेगा।

Vector indexes को गंभीर upgrade मिला

Azure SQL Database में अब full insert, update, और delete support के साथ तेज़, अधिक capable vector indexes उपलब्ध हैं। इसका मतलब है कि आपका vector डेटा real time में current रहता है — batch reindexing की कोई ज़रूरत नहीं।

नया क्या है:

Quantization — accuracy बहुत कम खोए बिना छोटे index sizes के लिए
Iterative filtering — अधिक precise results के लिए
Query optimizer के साथ गहरा integration — predictable performance के लिए

अगर आप Azure SQL को vector store के रूप में उपयोग करके retrieval-augmented generation (RAG) कर रहे हैं, तो ये improvements सीधे काम आती हैं। आप अपने vectors को उसी database में अपने relational data के साथ रख सकते हैं, जो एक अलग vector database चलाने की तुलना में आपकी architecture को काफी सरल बनाता है।

यही vector enhancements Fabric में SQL database में भी उपलब्ध हैं, क्योंकि दोनों के नीचे एक ही SQL engine चलता है।

Fabric में Database Hub: agentic management

यह थोड़ा भविष्योन्मुखी है, लेकिन दिलचस्प है। Microsoft ने Database Hub in Microsoft Fabric (early access) की घोषणा की, जो Azure SQL, Cosmos DB, PostgreSQL, MySQL और Arc के ज़रिए SQL Server पर एक single pane of glass देता है।

दिलचस्प पहलू सिर्फ unified view नहीं है — यह management का agentic approach है। AI agents लगातार आपके database estate को monitor करते हैं, बताते हैं क्या बदला, समझाते हैं क्यों यह मायने रखता है, और सुझाव देते हैं कि आगे क्या करना है। यह एक human-in-the-loop model है जहाँ agent सारी मेहनत करता है और आप निर्णय लेते हैं।

कई databases manage करने वाली teams के लिए, यह operational noise को वास्तव में कम कर सकता है। Portals के बीच jump करने और manually metrics चेक करने की बजाय, agent signal को आपके पास लाता है।

.NET developers के लिए इसका क्या मतलब है

इन सभी घोषणाओं को जोड़ने वाला धागा स्पष्ट है: Microsoft database stack की हर layer में AI agents को embed कर रहा है। एक gimmick के रूप में नहीं, बल्कि एक practical tooling layer के रूप में।

अगर आप Azure SQL से backed .NET apps बना रहे हैं, तो मैं वास्तव में यही करूँगा:

SQL MCP Server आज़माएं अगर आप AI agents बना रहे हैं। यह आपके agents को database access देने का सबसे clean तरीका है बिना custom plumbing के।
SSMS में Copilot enable करें अगर आपने अभी तक नहीं किया — daily SQL काम के लिए free productivity win।
Vector indexes में देखें अगर आप RAG कर रहे हैं और वर्तमान में एक अलग vector store चला रहे हैं। Azure SQL पर consolidate करने का मतलब है एक कम service manage करना।

अंत में

पूरी announcement में और भी है — savings plans, migration assistants, compliance features — लेकिन developer की कहानी MCP Server, vector improvements और agentic management layer में है। ये वो pieces हैं जो आपके बनाने के तरीके को बदलते हैं, न कि सिर्फ आपके budget को।

पूरी तस्वीर के लिए Shireesh Thota की पूरी announcement देखें, और नया management experience आज़माने के लिए Database Hub early access के लिए sign up करें।