تسهیل اتصال مدل‌های زبانی به هسته .NET 9 از طریق پروتکل MCP

اگر امروز یک سیستم بک‌اِند با .NET دارید، دیگر نیازی نیست برای اتصال آن به هوش مصنوعی، منطق تجاری خود را دوباره در پایتون یا تایپ‌اسکریپت بنویسید. «چرا باید منطق دامنه (Domain Logic) را در پایتون یا تایپ‌اسکریپت بازنویسی کنیم وقتی بک‌اِند فعلی ما دقیقاً همان‌جاست؟» این پرسش هسته‌ی اصلی تغییرات اخیر است. حالا با استفاده از SDK جدید مدل کانتکست پروتکل (MCP) برای C#، توسعه‌دهندگان .NET می‌توانند خدمات فعلی خود را به ابزارهایی تبدیل کنند که مدل‌های زبانی بزرگ (LLM) قادر به درک و اجرای مستقیم آن‌ها باشند. با بهره‌گیری از قابلیت‌های .NET 9، توسعه‌دهندگان اکنون می‌توانند یک سطح نازک و مبتنی بر اتریبیوت (Attributed Surface) ایجاد کنند که به LLMها اجازه می‌دهد مستقیماً با سرویس‌های دامنه C# تعامل داشته باشند.

این تحول در حالی رخ می‌دهد که عامل‌های هوش مصنوعی (AI Agents) از چرخه‌های ساده‌ی پرسش-پاسخ به سمت الگوهای پیچیده استفاده از ابزار (Tool Use) حرکت می‌کنند. برای سازمان‌ها و شرکت‌هایی که منطق تجاری‌شان پیش از این در اکوسیستم .NET مستقر شده است، تکثیر و بازنویسی این منطق در زبانی دیگر تنها برای ارضا کردن یک پروتکل AI، اتلاف شدید منابع و زمان است. طبق گزارشی فنی که در ۲۶ جولای ۲۰۲۶ در وب‌سایت dev.to منتشر شد، ارزش اصلی این SDK در این است که امضای تایپ‌شده‌ی (Typed Signature) متدهای .NET را به عنوان «منبع حقیقت» (Source of Truth) برای ساختار ابزار AI در نظر می‌گیرد. این رویکرد، نیاز به نوشتن دستی JSON Schemaها را که مستعد خطا هستند و معمولاً در گردش‌کارهای عامل‌محور باعث بروز ناهماهنگی (Drift) می‌شوند، به‌طور کامل از بین می‌برد. این رویکردی است که شرکت‌های بزرگی نظیر اپل نیز در پیش گرفته‌اند تا فرآیندهای توصیف دستی را در ابزارهای برنامه‌نویسی خود حذف کنند.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی استانداردسازی پروتکل‌های ارتباطی AI اشاره کردیم، هدف نهایی حذف لایه‌های واسطه‌ی متناقض است.

گذار از پیاده‌سازی دستی به SDK

پیش از ظهور SDK سی‌شارپ، توسعه‌دهندگان با حجم زیادی از کارهای دستی و سربارهای عملیاتی روبرو بودند. انتقال به این SDK چرخه حیات توسعه را به‌طور بنیادی تغییر می‌دهد:

• تجزیه پروتکل (Protocol Parse): از کدنویسی دستی JSON-RPC به سمت استفاده از AddMcpServer() برای مدیریت خودکار تغییر یافت.
• ساختار ابزار (Tool Schema): از نوشتن دستی JSON Schema به تولید خودکار از طریق اتریبیوت [McpServerTool] تغییر کرد.
• وابستگی‌ها (Dependencies): سازنده‌های استاتیک یا نمونه‌سازی‌های دستی جای خود را به تزریق وابستگی (Dependency Injection) با دامنه Scoped برای هر فراخوانی دادند.
• لایه انتقال (Transport): از پیاده‌سازی‌های بسته و محدود به stdio به انتخاب‌های منعطف بین stdio و ASP.NET Core تغییر یافت.
• تست: از اجرای کامل عامل‌های AI به سمت تست واحد (Unit Testing) متدها و استفاده از انتقال‌دهنده‌های درون-حافظه‌ای (In-memory transport) حرکت کرد.
• شروع سرد (Cold Start): از باینری‌های حجیم JIT به سمت Trim کردن و AOT بومی (Native AOT) گذار کرد.

خودکارسازی پروتکل

پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) — که شبیه به یک مترجم استاندارد است تا مدل زبانی بتواند با دیتابیس‌ها و ابزارهای مختلف بدون زبان‌های واسطه صحبت کند — در این SDK به شدت ساده شده است. این SDK کارهای دشوار مربوط به قاب‌بندی JSON-RPC، مقداردهی اولیه (Initialization) و مذاکره درباره قابلیت‌ها (Capability Negotiation) را بر عهده می‌گیرد.

توسعه‌دهندگان تنها کافی است بسته‌های NuGet مربوط به ModelContextProtocol و نسخه ModelContextProtocol.AspNetCore را به پروژه خود اضافه کنند. با استفاده از متد WithToolsFromAssembly()، سرور به‌طور خودکار کلاس‌هایی را که با اتریبیوت [McpServerToolType] علامت‌گذاری شده‌اند، شناسایی می‌کند. این شناسایی مبتنی بر Reflection، مکانیسم توزیع درخواست‌ها را سیم‌کشی می‌کند؛ به این معنا که توسعه‌دهنده به جای درگیر شدن با لوله‌کشی کد (Plumbing)، فقط قابلیت‌ها را ثبت می‌کند. در کد، این فرآیند به شکل یک الگوی ساده‌ی Builder ظاهر می‌شود:

builder.Services
    .AddMcpServer(o => o.ServerInfo = new() { Name = "mattrx-analytics", Version = "2.4.0" })
    .WithHttpTransport()
    .WithToolsFromAssembly();

ساختارهای مبتنی بر اتریبیوت

بر اساس مستندات این SDK، ویژگی کلیدی یا «Killer Feature» آن، تبدیل متدهای C# به ابزارهایی است که برای مدل قابل خواندن باشد. با افزودن اتریبیوت [McpServerTool] و ارائه یک توصیف ([Description])، SDK به طور خودکار JSON Schema لازم را از روی امضای متد تولید می‌کند.

برای مثال، متدی مانند GetCampaignKpis پارامترهای خود — نظیر یک GUID برای شناسه‌ی کمپین‌ها و رشته‌های ISO-8601 برای بازه‌های زمانی (مانند "2026-06-01/2026-06-30") — را مستقیماً به ویژگی‌هایی تبدیل می‌کند که مدل زبانی قادر به درک آن‌هاست. پارامترهایی که Non-nullable هستند، به‌طور خودکار به عنوان فیلدهای اجباری (Required) در Schema در نظر گرفته می‌شوند. در این میان، اتریبیوت [Description] تبدیل به دستورالعمل صریح و لفظی می‌شود که مدل برای تصمیم‌گیری در مورد زمان فراخوانی ابزار، آن را می‌خواند.

ابزارسازی بومی با تزریق وابستگی (DI)

ابزارها در این معماری به عنوان کلاس‌هایی با تزریق وابستگی در سازنده (Constructor Injection) پیاده‌سازی می‌شوند، که باعث می‌شود رفتاری کاملاً مشابه با کنترلرهای MVC داشته باشند. SDK یک نمونه Scoped از ابزار را برای هر فراخوانی از کانتینر تزریق وابستگی برنامه استخراج می‌کند.

این معماری اجازه می‌دهد یک سرور MCP از سرویس‌های دامنه موجود، مانند ICampaignQueries یا یک DbContext با دامنه Scoped و همچنین هویت امنیتی درخواست (AiPrincipal) مجدداً استفاده کند. در این حالت، سرور تبدیل به یک رابط مدیریت‌شده (Governed Interface) می‌شود، نه یک بازپیاده‌سازی از بک‌اِند. برای مثال، با تزریق ICampaignQueries، اکسپوز کردن یک دامنه کامل تحلیلی روی MCP تقریباً به هیچ کد کوئری جدیدی نیاز ندارد. توسعه‌دهندگان همچنین می‌توانند CancellationToken را در امضای متد بگذرانند تا اطمینان حاصل کنند که SDK می‌تواند زمان‌های انتظار (Timeout) یا لغو درخواست‌ها را به‌طور بهینه مدیریت کند.

مدل‌های میزبان منعطف

یک کدبیس واحد می‌تواند بسته به هدف استقرار، از دو محیط میزبانی متمایز پشتیبانی کند:

• میزبان Stdio: یک اپلیکیشن کنسول که برای توسعه محلی یا ابزارهای AI مبتنی بر دسک‌تاپ طراحی شده است. این مدل از WithStdioServerTransport() برای ارتباط از طریق ورودی/خروجی استاندارد استفاده می‌کند.
• میزبان HTTP: یک اپلیکیشن ASP.NET Core که از MapMcp("/mcp") برای محیط‌های تولیدی و چندمستاجری (Multi-tenant) استفاده می‌کند. این رویکرد اجازه می‌دهد نقطه انتهایی (Endpoint) مدل کانتکست پروتکل با احراز هویت‌های موجود، OpenTelemetry (OTel) و میدل‌ویرهای بررسی سلامت (Health-check) ترکیب شود.

این انعطاف باعث می‌شود توسعه‌دهندگان قابلیت ابزار را تنها یک بار بنویسند و سپس لایه‌ی انتقال (Transport Layer) را بر اساس اینکه سرور به صورت محلی اجرا می‌شود یا به عنوان یک سرویس ابری، انتخاب کنند. این انتقال به سمت معماری‌های منعطف‌تر، با تغییرات معماری MCP v2 برای سازگاری با زیرساخت‌های بدون سرور همسو است تا مقیاس‌پذیری در محیط‌های ابری بهینه شود.

تست و عملکرد

به دلیل اینکه ابزارها در واقع متدهای ساده هستند، می‌توان آن‌ها را با استفاده از Fakeها بدون هیچ‌گونه سربار پروتکلی، مورد تست واحد قرار داد. توسعه‌دهنده می‌تواند به سادگی AnalyticsTools را با یک FakeCampaignQueries نمونه‌سازی کرده و تأیید کند که نتایج به‌درستی بر اساس مستاجر (Tenant-scoped) هستند.

برای اعتبارسنجی سرتاسری (End-to-End)، SDK یک انتقال‌دهنده درون-حافظه‌ای از طریق McpTestHost.ConnectInMemoryAsync<T>() فراهم کرده است. این امکان به کلاینت‌ها اجازه می‌دهد تا بدون نیاز به شبکه زنده یا حضور LLM در چرخه، لیست ابزارها را دریافت کرده و آن‌ها را به‌صورت قطعی فراخوانی کنند تا از صحت عملکردهای tools/list و tools/call اطمینان حاصل شود.

برای رفع مشکل راه‌اندازی سرد (Cold Start) در محیط‌های ابری مانند Azure Container Apps، این SDK از Native AOT (Ahead-of-Time) پشتیبانی می‌کند. با تنظیم ویژگی‌های زیر در فایل پروژه، توسعه‌دهندگان می‌توانند زمان استارت-آپ را به شدت کاهش داده و حجم ایمیج‌ها را کوچک کنند:

• <PublishTrimmed>true</PublishTrimmed>
• <InvariantGlobalization>true</InvariantGlobalization>
• <PublishAot>true</PublishAot>

با این حال، نویسنده هشدار می‌دهد که چون تولید Schema بر پایه Reflection است، توسعه‌دهندگان باید پیش از استقرار Native AOT، ایمنی Trim (Trim-safety) را اعتبارسنجی کنند یا از Source Generatorها استفاده نمایند تا از خطاهای زمان اجرا جلوگیری شود. نباید این تنظیمات را بدون بررسی (Cargo-culting) کپی کرد، بلکه ابتدا باید اعتبارسنجی صورت گیرد.

این تغییر، شیوه ادغام AI را برای شرکت‌های .NET تغییر می‌دهد؛ زیرا پیچیدگی را از «کدهای چسب» (Glue Code) به «منطق دامنه» منتقل می‌کند. در واقع، به جای ساخت یک میدل‌ویر AI مجزا، هوش مصنوعی به‌طور مؤثر به یکی دیگر از کلاینت‌های لایه سرویس موجود تبدیل می‌شود.

ادغام MCP در استک .NET 9 اصطکاک معماری‌های چند-زبانه را از بین می‌برد و تضمین می‌کند که قابلیت‌های AI هم‌زمان با تغییر کد بک‌اِند، به‌روز شوند؛ زیرا هرگونه تغییر در امضای یک متد، به‌طور خودکار Schema ابزار ارائه شده به مدل را به‌روزرسانی می‌کند. در نهایت، این ابزارها می‌توانند در رابط‌های کاربر پیشرفته‌تر نمایش داده شوند، مشابه آنچه در چارچوب‌های رابط کاربر پشتیبان از mcp-elements مشاهده می‌کنیم.

توسعه‌دهندگان اکنون باید سرویس‌های دامنه فعلی خود را برای یافتن فرصت‌های با اهرم بالا (High-leverage) جهت استفاده از AI ارزیابی کنند. گام منطقی بعدی برای این معماری، انتقال این سرورها به زیرساخت‌های مقیاس تولید در Azure است.

گام بعدی شما

• شناسایی متدهای پرکاربرد در لایه‌ی سرویس فعلی خود که پتانسیل تبدیل شدن به ابزار AI دارند.
• تست پیاده‌سازی Native AOT روی یک پروژه کوچک برای بررسی سازگاری Reflection با کاربرد Trim.
• بررسی جایگزینی APIهای واسط با یک سرور MCP متمرکز برای کاهش تأخیر در پاسخ‌دهی عامل‌ها.