MCP چیست و چه کاری برای ما انجام می‌دهد؟
اگر مدتی است با LLMها، AI Agentها و ابزارهای هوش مصنوعی کار می‌کنید، احتمالاً با یک سؤال مهم مواجه شده‌اید:
چطور می‌توانیم یک مدل هوش مصنوعی را به سیستم‌های واقعی خودمان متصل کنیم؟
مثلاً فرض کنید یک مدل زبانی داریم و می‌خواهیم بتواند:
- اطلاعات را از Database بخواند
- وضعیت یک سفارش را بررسی کند
- به API داخلی شرکت دسترسی داشته باشد
- فایل‌های پروژه را جست‌وجو کند
- اطلاعات GitHub را دریافت کند
- Documentation پروژه را بخواند
- یا یک عملیات مشخص در Backend انجام دهد
مدل زبانی به‌صورت پیش‌فرض چنین دسترسی‌هایی ندارد.
اینجاست که MCP یا Model Context Protocol اهمیت پیدا می‌کند.
MCP چیست؟
MCP (Model Context Protocol) یک پروتکل استاندارد برای متصل کردن مدل‌های هوش مصنوعی به داده‌ها، منابع و ابزارهای خارجی است.
اگر بخواهیم خیلی ساده تصور کنیم، MCP یک لایه ارتباطی بین AI و سیستم‌های خارجی ایجاد می‌کند.
مثلاً:
AI Model / AI Agent
│
▼
MCP
│
┌────┼─────┬────────┐
▼ ▼ ▼ ▼
Database API Files GitHub
مدل به جای اینکه برای هر سیستم یک Integration کاملاً اختصاصی داشته باشد، می‌تواند از ابزارهایی استفاده کند که از طریق MCP در اختیارش قرار گرفته‌اند.
مشکل قبل از MCP چه بود؟
فرض کنید یک AI Agent داریم که باید بتواند با چند سیستم مختلف کار کند.
مثلاً:
LLM
│
├── Database Integration
├── GitHub Integration
├── Internal API Integration
├── File System Integration
└── Documentation Integration
هر Integration ممکن است API، ساختار و روش پیاده‌سازی خودش را داشته باشد.
اگر بعداً مدل یا AI Client دیگری اضافه کنیم، ممکن است مجبور شویم بخش زیادی از این Integrationها را دوباره پیاده‌سازی کنیم.
در پروژه‌های کوچک شاید مشکل بزرگی نباشد.
اما وقتی تعداد ابزارها زیاد شود، معماری خیلی سریع پیچیده می‌شود.
MCP تلاش می‌کند یک استاندارد مشترک برای این ارتباط ایجاد کند.
MCP Server و MCP Client چه هستند؟
برای درک MCP بهتر است حداقل سه مفهوم را بشناسیم:
MCP Host
برنامه‌ای که AI در آن اجرا می‌شود.
MCP Client
بخشی که ارتباط با MCP Server را برقرار می‌کند.
MCP Server
سرویسی که ابزارها و منابع موردنیاز AI را در اختیار آن قرار می‌دهد.
به‌صورت ساده:
┌──────────────────────┐
│ AI Host │
│ │
│ ┌────────────────┐ │
│ │ MCP Client │ │
│ └───────┬────────┘ │
└──────────┼───────────┘
│
▼
┌───────────────┐
│ MCP Server │
└───────┬───────┘
│
┌─────┼─────┬────────┐
▼ ▼ ▼ ▼
DB API Files GitHub
البته این دیاگرام یک مدل ذهنی ساده‌شده است؛ در معماری واقعی، جزئیات Transport، Session و قابلیت‌های MCP هم مطرح می‌شوند.
MCP چه چیزهایی را در اختیار AI قرار می‌دهد؟
یکی از نکات مهم MCP این است که فقط بحث «فرستادن اطلاعات به LLM» نیست.
MCP می‌تواند چند نوع قابلیت اصلی را در اختیار Client قرار دهد.
1. Tools
Toolها عملیاتی هستند که مدل می‌تواند درخواست اجرای آن‌ها را بدهد.
مثلاً:
GetCustomer
GetOrder
SearchProducts
CreateTicket
GetWeather
SearchDocumentation
فرض کنید MCP Server ما یک Tool به نام:
GetCustomerOrders
دارد.
مدل می‌تواند تشخیص دهد که برای پاسخ دادن به سؤال کاربر باید از این Tool استفاده کند.
مثلاً:
سفارش‌های مشتری شماره 125 چه وضعیتی دارند؟
مدل می‌تواند به جای حدس زدن، Tool مربوطه را صدا بزند و اطلاعات واقعی را دریافت کند.
2. Resources
Resources بیشتر برای ارائه اطلاعات و context به Client استفاده می‌شوند.
مثلاً:
project://documentation
project://configuration
project://schema
یا منابعی که از سیستم‌های مختلف خوانده می‌شوند.
این قابلیت برای سناریوهایی مثل Documentation، اطلاعات پروژه و داده‌های قابل‌خواندن بسیار کاربردی است.
3. Prompts
MCP می‌تواند Promptهای قابل استفاده مجدد را نیز در اختیار Client قرار دهد.
مثلاً یک سیستم می‌تواند Promptهای استانداردی برای:
Code Review
Database Analysis
Bug Investigation
Documentation Generation
داشته باشد.
در نتیجه بخشی از منطق مربوط به نحوه استفاده از AI می‌تواند ساختارمندتر شود.
یک مثال واقعی برای Backend Developer
فرض کنید یک سیستم فروشگاهی با ASP.NET Core داریم.
معماری ما چیزی شبیه این است:
ASP.NET Core
│
├── SQL Server
├── Redis
├── Payment API
└── Order Service
حالا می‌خواهیم یک AI Agent بسازیم که کارش پشتیبانی مشتری باشد.
کاربر می‌پرسد:
سفارش من الان کجاست؟
Agent باید بتواند:
- Customer را پیدا کند
- Order را پیدا کند
- وضعیت سفارش را بررسی کند
- پاسخ مناسب تولید کند
به جای اینکه مدل مستقیماً به SQL Server دسترسی داشته باشد، می‌توانیم Toolهایی تعریف کنیم:
GetCustomer
GetCustomerOrders
GetOrderStatus
و این Toolها از طریق MCP در اختیار Agent قرار بگیرند.
مثلاً:
User
│
▼
AI Agent
│
▼
MCP Client
│
▼
MCP Server
│
├── GetCustomer()
├── GetCustomerOrders()
└── GetOrderStatus()
│
▼
ASP.NET Core
│
▼
SQL Server
این معماری یک نکته بسیار مهم دارد:
AI لازم نیست بداند SQL Server شما چگونه کار می‌کند.
AI فقط می‌داند:
ابزاری به نام
GetOrderStatusوجود دارد که می‌تواند وضعیت سفارش را برگرداند.
جزئیات implementation پشت Tool باقی می‌ماند.
یکی از مهم‌ترین مزایای MCP: جداسازی مسئولیت‌ها
فرض کنید Tool زیر را داریم:
GetOrderStatus(orderId)
ممکن است پشت این Tool در حال حاضر SQL Server باشد.
اما شش ماه بعد معماری تغییر کند و اطلاعات سفارش از یک Microservice دریافت شود.
AI نباید مجبور شود تغییر کند.
ما فقط implementation پشت Tool را تغییر می‌دهیم:
Before:
MCP Tool
↓
SQL Server
After:
MCP Tool
↓
Order Microservice
↓
SQL Server
Interface مورد استفاده AI همچنان می‌تواند همان باشد.
این دقیقاً همان نوع جداسازی‌ای است که در معماری نرم‌افزار هم ارزش زیادی دارد.
MCP چه مزایایی دارد؟
1. استانداردسازی
یکی از مهم‌ترین اهداف MCP ایجاد یک روش استاندارد برای ارتباط AI با ابزارها و منابع خارجی است.
به جای اینکه برای هر مدل و هر سیستم یک Integration متفاوت طراحی کنیم، می‌توانیم از یک پروتکل مشخص استفاده کنیم.
2. Reusability
فرض کنید یک MCP Server برای سیستم داخلی شرکت ساخته‌اید.
این Server می‌تواند ابزارهایی مثل:
SearchCustomers
GetOrders
SearchTickets
GetProduct
را ارائه کند.
در صورت پشتیبانی Client موردنظر، همان MCP Server می‌تواند توسط Clientهای مختلف مورد استفاده قرار بگیرد.
این یعنی لازم نیست منطق Backend را برای هر AI Client دوباره بنویسیم.
3. کنترل دسترسی AI به سیستم‌ها
این مورد برای Backend Developerها بسیار مهم است.
یک اشتباه خطرناک این است که بگوییم:
AI مستقیماً به Database دسترسی داشته باشد.
در عوض می‌توانیم قابلیت‌های مشخصی را به شکل Tool در اختیار آن قرار دهیم.
مثلاً:
GetCustomer
GetOrder
SearchProducts
و اصلاً Toolای برای:
DROP TABLE
DELETE *
در اختیار Agent قرار ندهیم!
حتی برای عملیات حساس‌تر می‌توانیم Permission، Validation، Logging و محدودیت‌های بیشتری در لایه Backend اعمال کنیم.
پس MCP به ما کمک می‌کند سطح دسترسی AI را به قابلیت‌های مشخص محدود کنیم.
4. کاهش وابستگی AI به Implementation
مدل نباید مجبور باشد بداند:
- Database چیست
- API چگونه پیاده‌سازی شده
- Backend با .NET نوشته شده یا Java
- اطلاعات در SQL Server است یا PostgreSQL
- سرویس داخلی چگونه deploy شده
مدل فقط با Interface مربوط به Tool کار می‌کند.
مثلاً:
SearchCustomer
و implementation می‌تواند هر چیزی باشد.
این موضوع برای معماری‌های بزرگ اهمیت زیادی پیدا می‌کند.
5. ساخت Agentهای کاربردی‌تر
یک LLM معمولی عمدتاً متن تولید می‌کند.
اما وقتی Tool در اختیارش قرار می‌دهیم، می‌تواند در یک Workflow واقعی نقش فعال‌تری داشته باشد.
مثلاً:
User
↓
AI Agent
↓
Analyze Request
↓
Select Tool
↓
Call Tool
↓
Receive Result
↓
Reason
↓
Call Another Tool
↓
Generate Final Response
برای مثال:
«بررسی کن چرا سفارش مشتری 125 هنوز ارسال نشده.»
Agent ممکن است:
GetOrder(125)
↓
CheckPaymentStatus()
↓
CheckInventory()
↓
CheckShippingStatus()
↓
Analyze Results
↓
Generate Response
اینجاست که مفهوم AI Agent واقعاً جالب می‌شود.
آیا MCP جای REST API را می‌گیرد؟
خیر.
این یکی از سوءتفاهم‌های رایج درباره MCP است.
MCP رقیب REST API نیست.
REST API معمولاً برای ارتباط بین Applicationها و Serviceها استفاده می‌شود.
MCP بیشتر یک استاندارد برای ارتباط AI Client با Tools و Resources است.
در واقع یک MCP Tool می‌تواند در پشت خودش یک REST API را صدا بزند.
مثلاً:
AI Agent
↓
MCP
↓
Tool: GetOrderStatus
↓
REST API
↓
Order Service
↓
Database
بنابراین MCP می‌تواند روی سیستم‌های موجود شما قرار بگیرد و الزاماً نیاز نیست Backend فعلی را از نو طراحی کنید.
آیا MCP فقط برای برنامه‌نویسی است؟
خیر.
سناریوهای MCP بسیار گسترده‌تر هستند.
مثلاً:
Software Development
GitHub
Repository
Documentation
Issue Tracker
CI/CD
Database
Business Applications
CRM
ERP
Orders
Customers
Tickets
Reports
DevOps
Logs
Monitoring
Deployment
Infrastructure
Containers
Internal Enterprise Systems
Internal APIs
Databases
Documents
Knowledge Bases
Business Services
بنابراین MCP بیشتر از اینکه یک ابزار مخصوص Coding باشد، یک روش استاندارد برای اتصال AI به محیط واقعی نرم‌افزار است.
MCP در معماری AI کجا قرار می‌گیرد؟
اگر بخواهیم یک تصویر ذهنی ساده داشته باشیم:
┌──────────────┐
│ User │
└──────┬───────┘
│
▼
┌──────────────┐
│ AI Agent │
└──────┬───────┘
│
▼
┌──────────────┐
│ MCP Client │
└──────┬───────┘
│
▼
┌──────────────┐
│ MCP Server │
└──────┬───────┘
│
┌────────────┼─────────────┐
▼ ▼ ▼
Database APIs File System
در یک معماری واقعی ممکن است اجزای بیشتری وجود داشته باشند، اما این دیاگرام برای درک نقش MCP بسیار مناسب است.
برای یک .NET Developer، MCP چه اهمیتی دارد؟
اگر Backend Developer هستید، MCP یک موضوع جالب است چون بسیاری از مفاهیمی که قبلاً با آن‌ها کار کرده‌اید همچنان وجود دارند:
API
Authentication
Authorization
Validation
Logging
Database
Caching
Dependency Injection
Architecture
Security
اما حالا یک مصرف‌کننده جدید برای قابلیت‌های Backend داریم:
AI Agent
مثلاً شما قبلاً یک سرویس ساخته‌اید:
IOrderService
که اطلاعات سفارش را برمی‌گرداند.
حالا می‌توانید یک لایه AI-facing روی قابلیت‌های سیستم ایجاد کنید و بعضی از این عملیات را به عنوان Tool در اختیار Agent قرار دهید.
در نتیجه مسیر جالبی شکل می‌گیرد:
.NET Backend
+
LLM
+
MCP
+
AI Agent
و این دقیقاً یکی از بخش‌هایی است که برای AI Engineering با .NET ارزش یادگیری دارد.
اما یک نکته مهم: MCP به معنی دسترسی نامحدود AI نیست
MCP خودش به این معنی نیست که:
«حالا AI می‌تواند هر کاری در سیستم من انجام دهد.»
برعکس، طراحی Toolها اهمیت بسیار زیادی دارد.
مثلاً به جای:
ExecuteAnySql(query)
ممکن است Toolهای مشخصی طراحی کنیم:
GetCustomerById(id)
GetOrdersByCustomer(id)
GetProductById(id)
SearchProducts(keyword)
این طراحی باعث می‌شود:
- سطح دسترسی محدودتر شود
- رفتار قابل پیش‌بینی‌تر باشد
- Validation راحت‌تر شود
- Logging بهتر انجام شود
- Audit ساده‌تر شود
- ریسک عملیات ناخواسته کاهش پیدا کند
بنابراین MCP فقط یک مسئله AI نیست؛ یک مسئله معماری و Security هم هست.
MCP را چه زمانی باید یاد بگیریم؟
اگر مسیر یادگیری شما به سمت AI Agent و AI Engineering می‌رود، MCP یکی از مفاهیمی است که ارزش یادگیری دارد.
به‌خصوص اگر Backend Developer هستید و می‌خواهید AI را وارد سیستم‌های واقعی کنید.
به نظرم ترتیب ذهنی خوبی می‌تواند این باشد:
LLM Fundamentals
↓
Prompting
↓
LLM API
↓
Structured Output
↓
Tool Calling
↓
RAG
↓
AI Agents
↓
MCP
↓
Production AI Systems
البته این مسیر کاملاً خطی نیست و بعضی از این مفاهیم هم‌پوشانی دارند.
جمع‌بندی
MCP را می‌توان به زبان ساده یک استاندارد برای متصل کردن AI به دنیای بیرون از مدل دانست.
LLM به تنهایی فقط بخشی از یک سیستم AI است.
وقتی آن را به:
- Database
- API
- Files
- GitHub
- Documentation
- Business Services
- DevOps Tools
متصل می‌کنیم، می‌توانیم سیستم‌هایی بسازیم که فقط جواب تولید نمی‌کنند، بلکه می‌توانند بر اساس درخواست کاربر از ابزارهای واقعی استفاده کنند.
و برای یک Backend Developer، این یعنی یک فرصت جالب:
Backendهایی که قبلاً فقط توسط Applicationهای معمولی مصرف می‌شدند، می‌توانند به قابلیت‌هایی تبدیل شوند که AI Agentها هم از آن‌ها استفاده می‌کنند.
اگر با ASP.NET Core و C# کار می‌کنید، یادگیری MCP در کنار Tool Calling، RAG و AI Agentها می‌تواند بخش مهمی از مسیر ورود شما به AI Engineering باشد.
