MCP Server چیست؟ راهنمای اتصال امن ابزارهای هوش مصنوعی به داده و سرویس‌ها
راهنمای کاربردی Model Context Protocol و MCP Server؛ از معماری Client و Server و انتخاب Transport تا ارزیابی ابزارها، حداقل دسترسی، OAuth، جلوگیری از Prompt Injection و چک‌لیست اتصال امن.
یک مدل هوش مصنوعی به‌تنهایی به Repository، فایل‌های محلی، پایگاه داده یا ابزار مدیریت پروژه شما دسترسی ندارد. برای انجام کار واقعی باید راهی استاندارد وجود داشته باشد تا Client قابلیت‌ها را کشف کند، ورودی معتبر بفرستد و نتیجه را با مرز دسترسی روشن دریافت کند. Model Context Protocol یا MCP برای همین مسئله طراحی شده است.
MCP اتصال را ساده می‌کند، اما هر اتصال یک مرز اعتماد تازه می‌سازد. Server می‌تواند فقط مستندات را بخواند یا توانایی اجرای فرمان و تغییر داده داشته باشد. بنابراین سؤال درست فقط «چطور MCP را وصل کنیم؟» نیست؛ باید بدانیم این Server چه می‌بیند، چه کاری انجام می‌دهد و چگونه می‌توان اثر هر Tool call را کنترل کرد.
MCP Server چیست؟
MCP Server برنامه یا سرویسی است که مجموعه‌ای از قابلیت‌های ساختاریافته را از طریق پروتکل MCP در اختیار Client قرار می‌دهد. Client می‌تواند یک IDE، Agent کدنویسی یا برنامه هوش مصنوعی باشد. Server به‌جای آنکه مدل مستقیماً با هر API اختصاصی حرف بزند، قرارداد مشخصی برای کشف و فراخوانی قابلیت‌ها ارائه می‌کند.
برای نمونه، یک MCP Server مربوط به Git می‌تواند وضعیت Repository را بخواند؛ Server پایگاه داده می‌تواند Schema یا Queryهای مجاز را ارائه دهد؛ و Server مستندات می‌تواند محتوای نسخه فعلی یک کتابخانه را بازیابی کند. سطح خطر این سه یکسان نیست و Permission باید متناسب با عمل واقعی تنظیم شود.
| جزء | نقش | نمونه | مرز امنیتی |
|---|---|---|---|
| Host | برنامه میزبان تجربه AI | IDE یا Agent Manager | سیاست کلی و رضایت کاربر |
| Client | مدیریت ارتباط MCP | اتصال هر Server | Session و Capability |
| Server | ارائه قابلیت ساختاریافته | GitHub، Database، Files | مجوز و Validation |
| Transport | انتقال پیام | STDIO یا HTTP | فرایند محلی یا شبکه |
| Model | انتخاب و ترکیب Toolها | Agent کدنویسی | نباید مرجع Authorization باشد |
تفاوت Tools، Resources و Prompts
قابلیت‌های MCP فقط «ابزار اجرا» نیستند. Tools معمولاً عملی را انجام می‌دهند و ممکن است اثر جانبی داشته باشند. Resources اطلاعات قابل‌خواندن را در قالبی ساختاریافته ارائه می‌کنند. Prompts نیز الگوهای قابل‌استفاده برای تعامل را در اختیار Client می‌گذارند.
| نوع | کاربرد | نمونه | ریسک اصلی |
|---|---|---|---|
| Tool | انجام عمل | ساخت Issue یا اجرای Query | تغییر ناخواسته |
| Resource | خواندن Context | فایل راهنما یا Schema | افشای داده |
| Prompt | قالب تعامل | الگوی Review | اعتماد نادرست به متن |
نام Tool به‌تنهایی درباره ایمنی آن چیزی ثابت نمی‌کند. عملی با نام «sync» ممکن است فقط بخواند یا داده را بازنویسی کند. Description، Schema ورودی، Permission و پیاده‌سازی Server را بررسی کنید.
STDIO یا Remote HTTP؟
Server محلی معمولاً به‌صورت یک Process فرزند اجرا می‌شود و با STDIO پیام ردوبدل می‌کند. این روش برای ابزار توسعه محلی ساده است، اما فرمان راه‌اندازی همان کدی است که روی سیستم شما اجرا می‌شود. Server راه‌دور از HTTP استفاده می‌کند و نیازمند TLS، Authorization، محدودیت شبکه و مدیریت Session است.
| ویژگی | STDIO محلی | Remote HTTP |
|---|---|---|
| محل اجرا | دستگاه کاربر | Server شبکه |
| Credential | Environment محلی | OAuth یا Token محدود |
| ریسک برجسته | اجرای Package یا فرمان مخرب | سرقت Token و دسترسی شبکه |
| کنترل کلیدی | بررسی Command و Pin نسخه | HTTPS، Audience و Scope |
| بهترین کاربرد | فایل و ابزار توسعه | سرویس مشترک تیمی |
سناریوی عملی: اتصال Agent به Repository و مستندات
فرض کنید Agent باید یک خطای API را در پروژه پیدا کند. برای انجام این کار به خواندن Source، مشاهده مستندات رسمی و اجرای Test محدود نیاز دارد. دسترسی نوشتن به Branch اصلی، Secretهای Deployment و Database Production برای این Task ضروری نیست.
قرارداد دسترسی پیشنهادی
- خواندن فقط از Repository مشخص
- نوشتن فقط در Worktree یا Branch آزمایشی
- دسترسی وب فقط به Domain مستندات رسمی
- اجرای Testهای از پیش مشخص با تأیید کاربر
- ممنوعیت دسترسی به فایل‌های Environment واقعی
- ممنوعیت Push، Merge و Deploy خودکار
این قرارداد باید در Client و Server اجرا شود؛ نوشتن آن در Prompt کافی نیست. مدل ممکن است متن را اشتباه تفسیر کند، اما Permission فنی باید عملیات خارج از Scope را متوقف کند.
مرحله اول: Server را قبل از نصب ارزیابی کنید
One-click installation می‌تواند راحت باشد، اما Specification برای نصب Server محلی بر نمایش کامل فرمان و رضایت صریح کاربر تأکید می‌کند. پیش از اجرا، Publisher، Repository، Package، نسخه، Dependencyها و فرمان نهایی را ببینید.
- آیا Server در Registry رسمی یا منبع معتبر معرفی شده است؟
- Repository عمومی، License و سابقه Release دارد؟
- فرمان نصب دقیقاً چه Package و چه نسخه‌ای را اجرا می‌کند؟
- آیا Script پس از نصب از شبکه فایل دیگری می‌گیرد؟
- چه پوشه، Variable و Credentialی در اختیار Process قرار می‌گیرد؟
- آیا راه حذف و Rotation Credential مستند شده است؟
تعداد ستاره یا محبوبیت شبکه اجتماعی جای Code review و محدودیت دسترسی را نمی‌گیرد. اگر Server برای کار ساده، دسترسی گسترده می‌خواهد، گزینه دیگری انتخاب کنید.
مرحله دوم: Scope و حساب جدا تعریف کنید
برای MCP Server یک حساب فنی با حداقل Scope بسازید. اگر فقط باید Issueها را بخواند، Token با مجوز نوشتن Repository ندهید. برای Database از User فقط‌خواندنی، View محدود و محیط Staging استفاده کنید.
| منبع | دسترسی لازم | دسترسی اضافه و خطرناک |
|---|---|---|
| GitHub | خواندن یک Repository | Admin سازمان یا Merge |
| Database | View یا Query محدود | DDL، Delete و Production write |
| Files | یک Workspace | Home یا کل Drive |
| Docs | Domainهای رسمی | Web آزاد بدون Approval |
| Ticketing | خواندن Project | ویرایش و حذف همه Ticketها |
مرحله سوم: Credential را امن نگه دارید
Token را داخل Prompt، فایل تنظیمات Commitشده یا آرگومان قابل‌مشاهده قرار ندهید. برای STDIO، Specification توصیه می‌کند Credential از Environment امن دریافت شود. برای Server راه‌دور از Authorization استاندارد، Token کوتاه‌عمر و Storage امن Client استفاده کنید.
Token passthrough خطرناک است: Server نباید Token دریافتی برای خودش را بدون بررسی به سرویس دیگری بفرستد. Audience باید دقیقاً با Resource مقصد منطبق باشد و هر سرویس پایین‌دستی Credential جداگانه داشته باشد.
مرحله چهارم: Toolها را براساس اثر دسته‌بندی کنید
هر Tool را پیش از فعال‌سازی در یکی از دسته‌های Read-only، Write، Destructive یا External action قرار دهید. Annotation می‌تواند سرنخ بدهد، اما تضمین امنیت نیست؛ رفتار واقعی Server و Policy Client تعیین‌کننده‌اند.
| دسته | نمونه | سیاست مناسب |
|---|---|---|
| Read-only | خواندن مستندات | Allow با Scope محدود |
| Write | ویرایش فایل Worktree | Ask یا Allow محدود |
| Destructive | حذف Record | Deny یا تأیید همیشگی |
| External action | ارسال Issue یا پیام | تأیید در لحظه |
| Credential access | خواندن Secret | Deny مگر نیاز اثبات‌شده |
مرحله پنجم: Prompt Injection را جدی بگیرید
وقتی Server محتوای وب، Issue، سند یا فایل را به مدل می‌دهد، متن داخل آن منبع قابل‌اعتماد نیست. مهاجم می‌تواند دستورهایی بنویسد که مدل را به افشای داده یا اجرای Tool ترغیب کند. داده خارجی باید Context تلقی شود، نه Policy.
- منابع خواندنی را از ابزارهای تغییردهنده جدا کنید.
- Toolهای حساس را به تأیید انسانی وابسته کنید.
- خروجی Resource را برای Secret و داده شخصی فیلتر کنید.
- URL و Domain مقصد را پیش از درخواست شبکه نمایش دهید.
- نتیجه Tool را دوباره به‌عنوان دستور اجرایی اعتماد نکنید.
- Task را در Sandbox یا Worktree ایزوله اجرا کنید.
مرحله ششم: برای Remote Server از OAuth درست استفاده کنید
Authorization رسمی MCP برای Transportهای HTTP بر OAuth، Protected Resource Metadata و کشف Authorization Server تکیه دارد. Endpointها باید HTTPS باشند، Redirect URI باید دقیق بررسی شود و Client از PKCE استفاده کند.
Scope را کمینه کنید، Access Token را کوتاه‌عمر نگه دارید و Refresh Token را Rotate کنید. Server باید Audience Token را بررسی کند و Token صادرشده برای Resource دیگر را نپذیرد. خطای Authorization نیز نباید اطلاعات حساس درباره حساب یا ساختار داخلی افشا کند.
مرحله هفتم: Logging و Audit بسازید
برای پاسخ‌گویی باید بدانید چه Clientی، کدام Tool را، با چه Scope و چه نتیجه‌ای فراخوانده است. Log نباید خود Token، متن کامل Secret یا داده شخصی غیرضروری را ذخیره کند.
- شناسه Session یا Request بدون Credential
- نام Tool و نسخه Server
- زمان، Duration و Status
- هویت یا Authorization context قابل‌ممیزی
- اثر Read، Write یا Destructive
- Approval کاربر برای عملیات حساس
- خطا با Redaction مناسب
مرحله هشتم: Rollback و قطع دسترسی را آزمایش کنید
قبل از استفاده واقعی، راه خاموش‌کردن Server، حذف Configuration، Revoke Token و بازگرداندن تغییر را امتحان کنید. Serverی که نصب آسان و حذف مبهم دارد، ریسک عملیاتی ایجاد می‌کند.
برای ابزار نوشتن، نسخه پشتیبان یا Transaction داشته باشید. برای Git از Worktree و Commit کوچک استفاده کنید. برای Database عملیات آزمایشی را در Staging و با User محدود اجرا کنید.
خطاهای رایج در استفاده از MCP Server
نصب Package با آخرین نسخه متغیر
نسخه را Pin کنید و Release note را بخوانید. اجرای Latest بدون کنترل می‌تواند Dependency تازه یا رفتار ناسازگار وارد سیستم کند.
دادن کل Home به File Server
فقط Workspace لازم را Mount کنید. Desktop، Documents، SSH و فایل‌های Credential خارج از Scope بمانند.
استفاده از Token شخصی پرقدرت
حساب فنی و Scope محدود بسازید. Token جدا امکان Rotation و Audit دقیق‌تر می‌دهد.
اعتماد به Tool Description
Description خوداظهاری است. کد، مستندات، Permission واقعی و اثر خروجی را بررسی کنید.
فعال‌کردن Write قبل از اثبات Read
ابتدا جریان فقط‌خواندنی را پایدار کنید. Write را برای یک Task مشخص و با Approval اضافه کنید.
چک‌لیست اتصال امن MCP
- منبع، Publisher و نسخه Server تأیید شده است.
- فرمان نصب کامل و بدون بخش پنهان دیده شده است.
- Scope فایل، Repository، Database و Network حداقلی است.
- Credential در Secret Store یا Environment امن قرار دارد.
- Read، Write و Destructive policy جدا تعریف شده‌اند.
- عملیات خارجی و حساس در لحظه تأیید می‌شوند.
- Remote endpoint فقط HTTPS است و OAuth معتبر دارد.
- Audience، Redirect URI، PKCE و Token rotation بررسی شده‌اند.
- محتوای خارجی به‌عنوان داده نامطمئن پردازش می‌شود.
- Log بدون Secret، Rate limit و Alert وجود دارد.
- Revoke، حذف Server و Rollback آزمایش شده‌اند.
مسیرهای مکمل یادگیری
برای اجرای Agent در محیط پروژه با Permission و Worktree، آموزش Google Antigravity در ویندوز را ببینید. اگر محیط Terminal را ترجیح می‌دهید، راهنمای GitHub Copilot CLI مسیر نصب و تنظیم مجوزها را توضیح می‌دهد. برای طراحی یک جریان چندمرحله‌ای با State و تأیید انسانی نیز آموزش LangGraph و Human-in-the-loop مفید است.
جمع‌بندی
MCP Server پلی استاندارد میان Agent و ابزار واقعی است. ارزش آن در این است که Capabilityها ساختاریافته و قابل‌کشف می‌شوند؛ خطر آن نیز در همان نقطه است، زیرا یک Tool می‌تواند از خواندن داده تا تغییر سیستم پیش برود.
از Server معتبر، Scope کوچک و حالت Read-only شروع کنید. Credential را جدا نگه دارید، عملیات حساس را به Approval وابسته کنید و برای Remote Server از OAuth و HTTPS صحیح استفاده کنید. اتصال موفق زمانی کامل است که علاوه بر کارکرد، Audit، Revoke و Rollback آن نیز آزمایش شده باشد.
امروز فهرست MCP Serverهای فعال خود را بنویس و برای هرکدام دقیقاً مشخص کن چه داده‌ای می‌خواند، چه چیزی را تغییر می‌دهد و چگونه دسترسی‌اش قطع می‌شود.