پروتکل MCP چیست و چگونه کار می‌کند؟

فرض کنید می‌خواهید دستیار هوش مصنوعی به سندهای داخلی، یک پایگاه داده، مخزن کد و وب دسترسی داشته باشد. پیش از MCP راه این کار نوشتن یکپارچه‌سازی جداگانه برای هر ابزار در هر برنامه دستیار بود: افزونه پایگاه داده برای دستیار ویرایشگر کد، افزونه دیگری برای همان پایگاه داده در برنامه گفت‌وگو و نسخه سومی برای ابزارهای داخلی. با افزایش تعداد ابزارها و برنامه‌ها، تعداد یکپارچه‌سازی‌ها چند برابر می‌شد.

MCP (Model Context Protocol) این مسئله را حل می‌کند: ابزار را یک بار به‌صورت «سرور MCP» می‌نویسید و در هر برنامه هوش مصنوعی که از MCP پشتیبانی کند به کار می‌برید. در این نوشته توضیح می‌دهیم MCP چیست، چه مسئله‌ای را حل می‌کند، معماری میزبان و کلاینت و سرور، ابزارها، منابع و پرامپت‌هایی که سرورها ارائه می‌دهند و دو روش استاندارد انتقال. سپس بررسی می‌کنیم سرور MCP چگونه به داده وب می‌رسد و پروکسی کجا قرار می‌گیرد، خطرهای امنیتی پروتکل، تفاوت MCP با استفاده مستقیم از API و کوچک‌ترین سرور MCP قابل اجرا در پایتون.

MCP چیست؟#

Model Context Protocol پروتکلی باز است که شیوه وصل شدن برنامه‌های مدل زبانی بزرگ به منابع داده و ابزارهای بیرونی را استاندارد می‌کند. مشخصات رسمی پروتکل ارتباط را با پیام‌های JSON-RPC 2.0 تعریف می‌کند و خود را با Language Server Protocol (LSP) مقایسه می‌کند که پشتیبانی زبان‌های برنامه‌نویسی را در ابزارهای توسعه استاندارد کرد. همان‌طور که LSP اجازه داد پشتیبانی یک زبان یک بار نوشته و در هر ویرایشگری به کار رود، MCP می‌خواهد ابزار یک بار نوشته شود و در هر برنامه هوش مصنوعی دارای MCP به کار رود.

برای فهم MCP بهتر است دو چیز را از هم جدا کنیم:

• MCP مدل یا محصول هوش مصنوعی نیست. قرارداد ارتباطی است: قالب و معنای پیام‌های میان برنامه و ابزار را تعریف می‌کند.
• MCP ابزار را برای شما نمی‌نویسد. پرس‌وجوی پایگاه داده، درخواست وب یا عملیات فایل همچنان کد شماست؛ MCP اجازه می‌دهد آن کد را طوری عرضه کنید که برنامه‌های هوش مصنوعی بتوانند آن را کشف و فراخوانی کنند.

نسخه‌های مشخصات بر اساس تاریخ نام‌گذاری می‌شوند. هنگام نوشتن این نوشته نسخه جاری 2026-07-28 است و نسبت به نسخه‌های پیشین تغییر مهمی دارد: پروتکل بی‌حالت (stateless) است؛ هر درخواست نسخه پروتکل و قابلیت‌های کلاینت را با خود دارد. در نسخه‌های پیشین، در آغاز اتصال با handshake (initialize) نشست برقرار می‌شد. چون پروتکل سریع تحول می‌یابد، پیشنهاد می‌کنیم پیش از نوشتن یکپارچه‌سازی مشخصات جاری را بررسی کنید.

MCP چه مسئله‌ای را حل می‌کند؟#

مسئله‌ای که MCP حل می‌کند مسئله «N × M یکپارچه‌سازی» است. اگر پنج برنامه هوش مصنوعی و ده ابزار باشد، برای اینکه هر برنامه با هر ابزار حرف بزند پنجاه یکپارچه‌سازی جداگانه لازم است. هر یکپارچه‌سازی جداگانه نوشته، جداگانه آزموده و با تغییر ابزار جداگانه به‌روز می‌شود.

با MCP این به «N + M» تبدیل می‌شود:

• هر ابزار یک بار به‌صورت سرور MCP نوشته می‌شود.
• هر برنامه هوش مصنوعی یک بار پشتیبانی MCP می‌گیرد.
• هر برنامه‌ای که از MCP پشتیبانی کند می‌تواند هر سرور MCP را به کار ببرد.

در عمل: وقتی شرکتی برای پایگاه دانش داخلی خود سرور MCP بنویسد، کارکنان می‌توانند از طریق همان سرور از دستیار ویرایشگر کد، از برنامه گفت‌وگوی دسکتاپ یا از عاملی که خودشان ساخته‌اند به آن پایگاه دانش برسند.

معماری: میزبان، کلاینت و سرور#

بخش معماری مشخصات سه نقش تعریف می‌کند.

یکی از مهم‌ترین اصول طراحی معماری جداسازی است: سرور نمی‌تواند کل گفت‌وگو را بخواند یا درون سرورهای دیگر را ببیند. تاریخچه گفت‌وگو نزد میزبان می‌ماند؛ سرور فقط اطلاعاتی را که برای انجام کارش لازم دارد می‌گیرد. تعامل میان سرورها را هم میزبان کنترل می‌کند.

درخواست کاربر به این شیوه از این ساختار می‌گذرد:

1. کاربر درخواستی در برنامه میزبان می‌نویسد.
2. میزبان فهرست ابزارهایی را که سرورهای وصل ارائه می‌دهند همراه توضیحاتشان به مدل می‌دهد.
3. مدل تصمیم می‌گیرد ابزاری به کار ببرد و فراخوانی ابزار تولید می‌کند.
4. میزبان در صورت نیاز از کاربر رضایت می‌گیرد و فراخوانی را به کلاینت مربوط می‌دهد.
5. کلاینت درخواست را به سرور می‌فرستد؛ سرور ابزار را اجرا و نتیجه را برمی‌گرداند.
6. میزبان نتیجه را به مدل می‌دهد و مدل برای کاربر پاسخ تولید می‌کند.

منطق کلی حلقه فراخوانی ابزار را در عامل‌های هوش مصنوعی چگونه کار می‌کنند؟ مفصل توضیح داده‌ایم.

سرور MCP چه ارائه می‌دهد؟#

سرور MCP می‌تواند سه نوع قابلیت پایه ارائه دهد:

• ابزارها (tools): توابعی که مدل می‌تواند درخواست اجرایشان را بدهد. گرفتن یک صفحه وب، اجرای پرس‌وجو روی پایگاه داده، ساختن یک رکورد. هر ابزار نام، توضیحی که به مدل کمک می‌کند بفهمد کی آن را به کار ببرد و پارامترهای تعریف‌شده با JSON Schema دارد.
• منابع (resources): داده‌ای که کاربر یا مدل می‌تواند به‌عنوان زمینه به کار ببرد. محتوای یک فایل، طرح پایگاه داده، یک سند. برخلاف ابزارها کاری انجام نمی‌دهند؛ اطلاعات می‌دهند.
• پرامپت‌ها (قالب‌های پرامپت): قالب‌های پیام و جریان‌های کاری آماده‌ای که کاربر می‌تواند برگزیند. برای نمونه قالبی پارامتری مانند «این لاگ خطا را تحلیل کن».

سرورها همچنین می‌توانند برای کامل کردن یک درخواست از کلاینت ورودی بیشتر بخواهند: خواستن اطلاعات ناقص از کاربر (elicitation) یا وادار کردن مدل میزبان به تولید متن (sampling). در مشخصات جاری این درخواست‌ها درون پاسخ سرور منتقل می‌شوند.

روی هسته پروتکل، قابلیت‌هایی مانند مدیریت کارهای طولانی یا عنصرهای رابط تعاملی درون گفت‌وگو به‌صورت افزونه‌های اختیاری تعریف شده‌اند؛ هم کلاینت و هم سرور باید صراحتاً از آن‌ها پشتیبانی کنند.

روش‌های انتقال: stdio و Streamable HTTP#

شیوه جابه‌جایی پیام‌های MCP میان دو طرف در بخش انتقال مشخصات تعریف شده است. دو روش استاندارد وجود دارد:

معنای پروتکل در هر دو روش یکسان است؛ فقط شیوه رساندن پیام‌ها تغییر می‌کند. برای نیازهای ویژه روش‌های انتقال دیگری هم می‌توان تعریف کرد.

به یاد داشته باشید سروری که از راه stdio اجرا می‌شود با همه مجوزهای کاربری که آن را اجرا کرده کار می‌کند. سرور MCP که روی رایانه خود نصب می‌کنید به همان اندازه شما به فایل‌ها و شبکه‌تان دسترسی دارد.

سرور MCP چگونه به داده وب می‌رسد؟#

یکی از قابلیت‌هایی که برنامه‌های هوش مصنوعی بیش از همه لازم دارند داده به‌روز وب است. سرور MCP معمولاً آن را از یکی از این سه راه فراهم می‌کند:

• ابزار جست‌وجو: پرس‌وجویی به API جست‌وجو می‌فرستد و فهرستی از عنوان‌ها و آدرس‌ها برمی‌گرداند.
• ابزار گرفتن صفحه: آدرس مشخصی را با کلاینت HTTP می‌گیرد و متنش را برمی‌گرداند.
• ابزار مرورگر: مرورگر headless را کنترل می‌کند؛ صفحه‌هایی را که با جاوااسکریپت بارگذاری می‌شوند باز می‌کند، کلیک می‌کند و تصویر صفحه می‌گیرد.

سمت شبکه این ابزارها درخواست‌های HTTP معمولی است و همه قواعد وب اسکرپینگ اینجا هم صادق است. در این ساختار پروکسی در نقطه خروج سرور به دنیای بیرون قرار می‌گیرد:

• موقعیت: سرور از آدرسی در کشوری مشخص استفاده می‌کند تا ببیند محصول یا محتوا از آنجا چگونه دیده می‌شود. برای کارهایی که دید اتصال خانگی واقعی لازم دارند پروکسی مسکونی ترجیح داده می‌شود.
• پخش بار: ابزاری که صفحه‌های عمومی متفاوت فراوانی می‌گیرد می‌تواند با پروکسی چرخشی درخواست‌ها را از یک آدرس میان IPهای خروجی متفاوت پخش کند؛ محدودیت‌های نرخ و قواعد سایت‌ها همچنان پابرجاست.
• کنترل و ثبت خروج: اینکه سرور به کدام دامنه‌ها می‌رسد از یک نقطه پایش و محدود می‌شود.
• جداسازی: ترافیک وب سرور از شبکه داخلی و آدرس‌های IP اصلی شرکت جدا نگه داشته می‌شود.

شیوه امن کردن ابزار دسترسی وب با فهرست مجاز، محدودیت نرخ، مسدود کردن شبکه داخلی و پاک‌سازی محتوا را با نمونه آزموده در دسترسی امن LLM به وب: محدودیت نرخ و مجوزها توضیح داده‌ایم. برای ساختار کلی جمع‌آوری داده، صفحه راه‌حل استخراج داده را ببینید.

کوچک‌ترین سرور MCP#

نمونه زیر سرور MCP با یک ابزار است که با SDK رسمی پایتون نوشته شده است. ابزار فقط صفحه‌های HTTPS دامنه‌های مجاز را می‌گیرد و درخواست را از پروکسی خروجی اختیاری می‌فرستد. در نسخه 2 از SDK کلاس سرور MCPServer نام دارد؛ نمونه‌های FastMCP نسخه 1 مستقیم روی این نسخه اجرا نمی‌شوند.

pip install mcp httpx

# server.py
import os
from urllib.parse import urlsplit

import httpx
from mcp.server.mcpserver import MCPServer

ALLOWED = {d.strip().lower() for d in os.environ.get("ALLOWED_DOMAINS", "example.com").split(",")}
PROXY = os.environ.get("EGRESS_PROXY")  # e.g. http://user:pass@pr.proxynet.io:8000

mcp = MCPServer("web-reader")


@mcp.tool()
async def fetch_page(url: str) -> str:
    """Returns the first 5,000 characters of a page on an allowed domain."""
    parts = urlsplit(url)
    if parts.scheme != "https" or (parts.hostname or "").lower() not in ALLOWED:
        return f"This address is not on the allowlist: {url}"
    async with httpx.AsyncClient(proxy=PROXY, timeout=15, follow_redirects=False) as client:
        response = await client.get(url, headers={"User-Agent": "ExampleMCP/1.0"})
    return response.text[:5000]


if __name__ == "__main__":
    mcp.run(transport="stdio")

نام تابع نام ابزار، docstring توضیح ابزار و راهنمای نوع‌ها طرح پارامتر می‌شود. SDK این‌ها را خودکار به تعریف ابزار MCP تبدیل می‌کند.

برای فراخوانی سرور از یک کلاینت:

# client.py
import asyncio
import sys

from mcp.client.session import ClientSession
from mcp.client.stdio import StdioServerParameters, stdio_client

SERVER = StdioServerParameters(
    command=sys.executable,
    args=["server.py"],
    env={"ALLOWED_DOMAINS": "example.com", "EGRESS_PROXY": "http://user:pass@pr.proxynet.io:8000"},
)


async def main():
    async with stdio_client(SERVER) as (read, write):
        async with ClientSession(read, write) as session:
            await session.discover()  # learn the server's version and capabilities
            tools = await session.list_tools()
            print([t.name for t in tools.tools])

            result = await session.call_tool("fetch_page", {"url": "https://example.com/"})
            print(result.content[0].text[:200])


asyncio.run(main())

به دو نکته توجه کنید. نخست، کلاینت پیش از فهرست کردن ابزارها با discover() می‌فهمد سرور از کدام نسخه پروتکل و قابلیت‌ها پشتیبانی می‌کند؛ اگر این گام رد شود، سرور درخواست را با خطای پارامتر نامعتبر رد می‌کند. برای سرورهایی که نسخه‌های قدیمی‌تر پروتکل را به کار می‌برند، SDK فراخوانی initialize() را هم دارد. دوم، وقتی SDK سرور stdio را اجرا می‌کند همه متغیرهای محیطی را منتقل نمی‌کند، بلکه فقط فهرستی محدود مانند PATH را؛ مقدارهایی که سرور لازم دارد مانند ALLOWED_DOMAINS و EGRESS_PROXY باید صراحتاً با پارامتر env داده شوند.

در استفاده واقعی کلاینت را خودتان نمی‌نویسید؛ سرور را به تنظیمات برنامه میزبانی که از MCP پشتیبانی می‌کند می‌افزایید و میزبان آن را اجرا می‌کند. این کلاینت نمونه برای آزمودن درستی کار سرور کافی است.

نمونه عمداً کوچک است. در محیط واقعی باید محدودیت نرخ، بررسی آدرس شبکه داخلی، سقف اندازه پاسخ و پاک‌سازی محتوا به این ابزار افزوده شود.

خطرهای امنیتی#

اینکه ابزارهای MCP می‌توانند کد دلخواه اجرا کنند و از منابع بیرونی محتوا بگیرند، پروتکل را به همان اندازه که توانمند است پرخطر هم می‌کند. خود مشخصات رضایت کاربر، حریم خصوصی داده و ایمنی ابزار را اصول بنیادین می‌شمارد و از میزبان‌ها می‌خواهد پیش از فراخوانی ابزار از کاربر رضایت صریح بگیرند. خطرهای اصلی:

• آلوده‌سازی ابزار (tool poisoning). چون مدل با خواندن توضیح ابزار تصمیم می‌گیرد آن را چگونه به کار ببرد، سرور مخرب می‌تواند دستورهایی خطاب به مدل را در توضیح پنهان کند. مشخصات می‌گوید توضیح‌ها و حاشیه‌نویسی‌های ابزار باید نامطمئن دانسته شوند مگر از سرور مطمئن آمده باشند.
• مجوز بیش از حد. دادن دسترسی بیش از نیاز به سرور: نوشتن برای کاری که فقط خواندن لازم دارد، کل سامانه فایل به‌جای یک پوشه، حساب مدیر به‌جای یک جدول پایگاه داده.
• تزریق پرامپت از راه نتیجه ابزار. محتوایی که ابزار گرفتن صفحه برمی‌گرداند ممکن است متنی شبیه دستور خطاب به مدل داشته باشد. مدل با پیروی از آن ممکن است ابزاری را روی سرور دیگری فرابخواند.
• پاس دادن توکن. سرور MCP که توکن دسترسی دریافتی را بدون اعتبارسنجی به سرویس‌های دیگر بفرستد، ممکن است باعث دور زده شدن بررسی‌های مجوز شود. سند توصیه‌های امنیتی پروتکل این پاس دادن توکن را صراحتاً ممنوع می‌کند و از سرورها می‌خواهد فقط توکن‌هایی را بپذیرند که برای خودشان صادر شده است.
• SSRF. سرور مخرب می‌تواند کلاینت را در فرایند مجوزدهی به فرستادن درخواست به آدرس‌های شبکه داخلی یا آدرس‌های فراداده ابری وادارد.
• سرورهای محلی نامطمئن. چون سرورهای stdio با مجوزهای کاربر اجرا می‌شوند، نصب سروری با منشأ تأییدنشده برابر با اجرای برنامه‌ای تأییدنشده است.

تدابیر عملی:

• فقط سرورهایی را نصب کنید که منشأشان را می‌شناسید و کدشان را می‌توانید بازبینی کنید.
• به هر سرور کمترین مجوز را بدهید؛ کارهایی مانند نوشتن و حذف را در ابزارهای جداگانه بگذارید.
• رضایت کاربر را برای فراخوانی ابزارهای دارای اثر جانبی خاموش نکنید.
• خروجی ابزارهایی را که محتوای وب می‌گیرند داده نامطمئن علامت بزنید.
• در سرورهای راه دور مخاطب توکن را اعتبارسنجی کنید و توکن را پاس ندهید.
• فراخوانی ابزارها را ثبت کنید و مراقب دنباله‌های فراخوانی غیرمنتظره باشید.

تفاوت MCP و API#

MCP جایگزین API نیست؛ بیشتر سرورهای MCP از قبل یک API را دربرمی‌گیرند. تفاوت در این است که برای چه کسی طراحی شده‌اند.

MCP یا API مستقیم؟#

کاربردها#

• ابزارهای توسعه‌دهنده: وادار کردن دستیار ویرایشگر کد به خواندن مخزن کد، لاگ‌های خطا و مستندات.
• دسترسی به دانش داخلی: وادار کردن دستیاران کارکنان به جست‌وجو در ویکی داخلی، تیکت‌های پشتیبانی و مستندات محصول.
• تحلیل داده: عرضه پایگاه داده به‌صورت سرور MCP فقط‌خواندنی تا تحلیلگران با زبان طبیعی پرس‌وجو کنند.
• پژوهش وب: عامل‌هایی که از راه ابزار گرفتن صفحه با فهرست مجاز و محدودیت نرخ به اطلاعات به‌روز می‌رسند. برای نمونه‌ای از اینکه مدل‌های زبانی چگونه برای استخراج اطلاعات ساخت‌یافته از داده وب به کار می‌روند، وب اسکرپینگ با ⁦GPT-6 Astra⁩ را ببینید.
• ابزارهای عملیات: خواندن معیارها از سامانه‌های پایش و تولید خلاصه رخداد؛ کارهای مداخله در ابزارهای جداگانه‌ای که تأیید لازم دارند.

اشتباهات رایج#

• نصب سرور با منشأ نامعلوم. نصب سرور MCP همان اعتمادی را لازم دارد که اجرای یک برنامه.
• دادن همه مجوزها به یک سرور. جدا نکردن ابزارهای خواندن و نوشتن.
• نوشتن توضیح کوتاه و مبهم برای ابزار. مدل ابزار را در وضعیت نادرست فرامی‌خواند.
• مطمئن دانستن نتیجه ابزار. محتوای وب و سند ممکن است دستور داشته باشد.
• خاموش کردن گام‌های رضایت. رضایت کاربر لایه امنیتی پایه است، به‌ویژه در ابزارهای دارای اثر جانبی.
• بررسی نکردن نسخه مشخصات. چون پروتکل سریع تحول می‌یابد، نمونه‌های نوشته‌شده برای نسخه‌های قدیمی ممکن است با SDKهای جاری کار نکنند.

پرسش‌های متداول#

MCP را چه کسی توسعه داده است؟#

MCP را Anthropic به‌عنوان پروتکلی باز اعلام کرد و با مشخصات، SDKها و مستنداتش به‌صورت پروژه متن‌باز توسعه می‌یابد. برنامه‌ها و ابزارهای هوش مصنوعی شرکت‌های مختلف از پروتکل پشتیبانی می‌کنند.

آیا MCP فقط با مدل هوش مصنوعی خاصی کار می‌کند؟#

نه. MCP ارتباط میان برنامه و ابزار را تعریف می‌کند و مستقل از مدل است. برنامه میزبان هر مدلی به کار ببرد، ابزارهای سرورهای MCP را به همان مدل ارائه می‌دهد.

سرور MCP را با کدام زبان‌ها می‌توانم بنویسم؟#

پروژه برای زبان‌های فراوانی، در صدرشان پایتون و TypeScript، SDK رسمی ارائه می‌دهد. چون پروتکل بر JSON-RPC تکیه دارد، در زبانی بدون SDK هم می‌توان با پیروی از مشخصات سرور نوشت.

تفاوت MCP و function calling چیست؟#

function calling توانایی مدل در تولید فراخوانی ساخت‌یافته ابزار است و ویژه API هر ارائه‌دهنده مدل است. MCP پروتکلی است که اجازه می‌دهد آن ابزارها میان برنامه‌ها به شکلی استاندارد تعریف، کشف و فراخوانی شوند. میزبان ابزارهایی را که از سرورهای MCP می‌گیرد از راه function calling به مدل ارائه می‌دهد.

میان سرور MCP محلی و راه دور چگونه انتخاب کنم؟#

برای استفاده شخصی و دسترسی به فایل‌های محلی، سرور محلی از راه stdio کافی است. برای ابزارهایی که تیم یا شرکت به اشتراک می‌گذارد و باید متمرکز مدیریت و مجوزدهی شوند، سرور راه دور از راه Streamable HTTP مناسب است.

وقتی سرور MCP به وب دسترسی دارد پروکسی چگونه به کار می‌رود؟#

پروکسی به کلاینت HTTP یا مرورگر درون سرور داده می‌شود و ربطی به خود پروتکل MCP ندارد. در نمونه بالا آدرس پروکسی از متغیر محیطی خوانده و به کلاینت HTTP داده می‌شود، پس همه ترافیک وب سرور از نقطه خروج کنترل‌شده‌ای می‌گذرد.

خلاصه#

MCP پروتکلی باز است که برنامه‌های هوش مصنوعی را به شکلی استاندارد به ابزارها و منابع داده وصل می‌کند. هر کلاینت درون برنامه میزبان به یک سرور وصل می‌شود؛ سرورها ابزار، منبع و قالب پرامپت ارائه می‌دهند؛ پیام‌ها با JSON-RPC از راه stdio یا Streamable HTTP جابه‌جا می‌شوند. مشخصات جاری به ساختار بی‌حالت رفته و پروتکل سریع تحول می‌یابد. چون ابزارها می‌توانند کد اجرا کنند و محتوای بیرونی بگیرند، کمترین مجوز، رضایت کاربر، مدیریت محتوای نامطمئن و ثبت رویداد باید بخشی از طراحی باشند. برای مدیریت دسترسی سرورهای MCP به وب با کنترل موقعیت و خروج، نگاهی به خدمات پروکسی ما بیندازید.