Agentic Internet / 03

MCP اصلاً چیه و چرا همه دارن براش Server می‌سازن؟

۱۲ شهریور ۱۴۰۵

سلام سلام!

دو قسمت قبلی یه عبارت رو هی استفاده کردیم.

MCP.

Kitesurf می‌تونست با ابزارهای Agent کار کنه.

WebMCP می‌خواست قابلیت‌های یه سایت رو به شکل Tool به Agent نشون بده.

و احتمالاً اگر این یکی دو سال با Claude Code، Cursor، Codex، OpenCode یا تقریباً هر Agent دیگه‌ای ور رفته باشید، یه جایی یکی بهتون گفته:

یه MCP Server نصب کن.

بعد یه JSON عجیب بهتون داده، چند تا Environment Variable وارد کردید و یهو AI تونسته GitHub رو بخونه.

یا دیتابیس رو Query کنه.

یا توی Linear Issue بسازه.

و احتمالاً با خودتون گفتید:

خب...

این دیگه چیه؟

قبل از MCP چه خبر بود؟

فرض کنید سال ۲۰۲۴ـه و دارید یه AI Assistant می‌سازید.

می‌خواید بهش GitHub وصل کنید.

پس برای GitHub یه Integration می‌نویسید.

بعد می‌خواید Slack رو هم بخونه.

یه Integration دیگه.

بعد PostgreSQL.

یکی دیگه.

Google Drive.

باز یکی دیگه.

حالا یه شرکت دیگه یه AI Assistant جدید می‌سازه.

اون هم دقیقاً باید همین Integrationها رو دوباره بسازه.

یعنی تقریباً این وضعیت رو داشتیم:

AI App A ───── GitHub
         ├──── Slack
         ├──── Postgres
         └──── Google Drive

AI App B ───── GitHub
         ├──── Slack
         ├──── Postgres
         └──── Google Drive

AI App C ───── GitHub
         ├──── Slack
         ├──── Postgres
         └──── Google Drive

هر App زبان خودش رو داشت.

هر Service هم API خودش رو.

و وسط این داستان یه عالمه Glue Code داشتیم که هیچ‌کس واقعاً دوست نداشت بنویسه.

Anthropic اواخر ۲۰۲۴ گفت:

چرا یه قرارداد مشترک وسط این دو تا نذاریم؟

و Model Context Protocol یا همون MCP متولد شد.

Anthropic در ۲۵ نوامبر ۲۰۲۴ MCP رو به‌عنوان یه استاندارد Open Source معرفی کرد تا AI Applicationها بتونن با یه روش مشترک به Data Sourceها و Toolها وصل بشن. (Anthropic)

خیلی ساده، MCP چیه؟

بیاید فعلاً Specification رو پرت کنیم بیرون.

MCP در ساده‌ترین حالت یه قرارداد بین دو طرفه.

یه طرف می‌گه:

من این کارها رو بلدم.

طرف دیگه می‌گه:

عالیه، پس وقتی لازم داشتم صدات می‌کنم.

مثلاً یه MCP Server برای GitHub ممکنه بگه:

tools:

- search_repositories
- get_issue
- create_issue
- create_pull_request

Agent لیست رو می‌بینه.

کاربر می‌گه:

برای این باگ یه Issue بساز.

مدل متوجه می‌شه Tool مناسبی به اسم create_issue وجود داره.

ورودی مناسبش رو می‌سازه.

Server کار واقعی رو انجام می‌ده.

نتیجه رو برمی‌گردونه.

مدل هم ادامه‌ی کارش رو انجام می‌ده.

همین.

قرار نیست خود LLM بدونه GitHub API چطور کار می‌کنه.

قرار نیست Token شما رو بلد باشه.

قرار نیست Endpointها رو حفظ کرده باشه.

فقط باید بفهمه:

چه Toolهایی وجود دارن؟

هر Tool چه کاری می‌کنه؟

چه ورودی‌ای می‌خواد؟

و چه چیزی برمی‌گردونه؟

داستان USB-C

احتمالاً معروف‌ترین تشبیهی که درباره MCP شنیدید اینه:

MCP مثل USB-C برای AIـه.

خود Anthropic هم برای توضیحش از این تشبیه استفاده کرده. (Claude Platform Docs)

و برای فهم اولیه واقعاً تشبیه خوبیه.

قبل از USB-C یه عالمه کابل مختلف داشتیم.

این دستگاه Mini USB.

اون یکی Micro USB.

اون یکی یه پورت عجیب که فقط سازنده‌ی خودش می‌فهمید چیه.

USB-C اومد و گفت:

بیاید حداقل روی یه Interface مشترک توافق کنیم.

MCP هم یه ایده‌ی مشابه داره.

به‌جای اینکه:

Claude ↔ GitHub integration مخصوص Claude
Cursor ↔ GitHub integration مخصوص Cursor
App X ↔ GitHub integration مخصوص App X

داشته باشیم، می‌تونیم داشته باشیم:

             ┌── Claude
             │
GitHub MCP ──┼── Cursor
             │
             ├── VS Code
             │
             └── Your Agent

یه Server.

چند Client.

البته اگر خیلی جدی به تشبیه USB-C بچسبیم، یه جاهایی خراب می‌شه.

MCP یه کابل نیست.

یه Protocolـه.

Authentication داره.

Schema داره.

Transport داره.

Permission داره.

و مهم‌تر از همه، طرف دیگه‌ش یه مدل زبانیه که ممکنه تصمیم اشتباه بگیره :))

ولی برای شروع:

USB-C برای Toolهای AI؟

قبوله.

Client و Server دقیقاً کی‌ان؟

اینجا اسم‌ها اولش یه کم گیج‌کننده‌ن.

فرض کنید Claude Code دارید.

Claude Code می‌شه MCP Host.

داخلش یه MCP Client وجود داره که به Server وصل می‌شه.

و مثلاً Server شما GitHub MCPـه.

به شکل ساده:

┌──────────────────────────┐
│       Claude Code        │
│                          │
│      MCP Client          │
└────────────┬─────────────┘
             │
             │ MCP
             │
┌────────────▼─────────────┐
│      GitHub MCP Server   │
│                          │
│  search_issue            │
│  create_issue            │
│  get_pull_request        │
└────────────┬─────────────┘
             │
             │ GitHub API
             ▼
          GitHub

MCP Server الزاماً خود سرویس اصلی نیست.

این نکته مهمه.

GitHub یه API داره.

MCP Server می‌تونه نقش Adapter بین اون API و Agent رو بازی کنه.

برای دیتابیس هم همینه.

برای Filesystem هم همینه.

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

SDK رسمی فعلی MCP هم دقیقاً همین مدل رو توضیح می‌ده: Server می‌تونه Tool، Resource و Prompt ارائه کنه و Hostهایی مثل Claude Code، VS Code یا Cursor بهش وصل بشن. (MCP TypeScript SDK)

MCP فقط Tool نیست

اینجا یکی از چیزهاییه که معمولاً توی توضیح‌های ساده‌ی MCP گم می‌شه.

MCP فقط این نیست که یه سری Function به AI بدیم.

سه مفهوم مهم داره:

Tools
Resources
Prompts

Tools

Tool یعنی:

یه کاری انجام بده.

مثلاً:

create_issue()
send_message()
query_database()
deploy_project()

یه Action داریم.

ممکنه چیزی رو تغییر بده.

ممکنه فقط Query کنه.

ولی مدل معمولاً Tool رو انتخاب و اجرا می‌کنه.

Resources

Resource بیشتر یعنی:

یه چیزی برای خوندن دارم.

مثلاً:

file:///project/README.md
database://schema/users
docs://company/refund-policy

به‌جای اینکه همه‌چی رو از اول توی Context Window مدل بچپونیم، Server می‌تونه Resourceهایی ارائه بده که Client در صورت نیاز بخونه.

Prompts

Prompt هم می‌تونه Template یا Workflow آماده‌ای باشه که Server ارائه می‌کنه.

مثلاً یه Server می‌تونه Promptی داشته باشه برای:

review_pull_request

که یه Workflow مشخص برای Review کردن PR به Host بده.

پس تصویر کامل‌تر اینه:

MCP Server

├── Tools
│   ├── create_issue
│   └── search_code
│
├── Resources
│   ├── repository://README
│   └── repository://CONTRIBUTING
│
└── Prompts
    └── review_pull_request

این تفاوت مهمه.

همه‌چی قرار نیست Function Call باشه.

یه MCP Server واقعاً چقدر کد می‌خواد؟

جالب اینجاست که برای یه Server ساده، خیلی کم.

مثلاً در TypeScript امروز می‌تونید با SDK رسمی یه Server بسازید و یه Tool تعریف کنید.

از نظر مفهومی تقریباً این شکلی:

const server = new McpServer({
  name: "my-server",
  version: "1.0.0"
});

server.registerTool(
  "get_weather",
  {
    description: "Get weather for a city",
    inputSchema: {
      city: z.string()
    }
  },
  async ({ city }) => {
    return {
      content: [
        {
          type: "text",
          text: `Weather for ${city}`
        }
      ]
    };
  }
);

Server می‌گه:

من یه Tool دارم.

اسمش اینه.

توضیحش اینه.

Schema ورودی‌ش اینه.

وقتی صداش کردی، این Function رو اجرا کن.

بقیه‌ی داستان رو Protocol و SDK هندل می‌کنن.

و این یکی از دلایلیه که MCP این‌قدر سریع پخش شد.

ساختن Adapter برای یه سرویس حالا نسبتاً ساده‌ست.

و اگر درست ساخته شده باشه، فقط برای یه AI خاص نیست.

لوکال یا روی اینترنت؟

هر دو.

مثلاً یه MCP Server می‌تونه روی سیستم خودتون اجرا بشه.

Claude Code یا Cursor یه Process رو Start می‌کنه و از طریق stdio باهاش حرف می‌زنه.

تقریباً:

Cursor
   │
   │ stdin / stdout
   ▼
Local MCP Server
   │
   ▼
Your Files

این برای چیزهایی مثل Filesystem، Git یا Toolهای لوکال خیلی خوبه.

ولی MCP Server می‌تونه Remote هم باشه.

مثلاً:

Your Agent
     │
     │ HTTPS
     ▼
https://example.com/mcp
     │
     ▼
Company Services

و اینجا دیگه داستان خیلی بزرگ‌تر می‌شه.

چون داریم از یه Plugin کوچیک روی لپ‌تاپ می‌ریم سمت Infrastructure واقعی.

Load Balancer.

OAuth.

Rate Limit.

Observability.

Identity.

Permission.

Multi-tenancy.

و دقیقاً به همین دلیل MCP سال ۲۰۲۶ با MCP اواخر ۲۰۲۴ خیلی فرق کرده.

MCP دیگه اون پروتکل کوچیک ۲۰۲۴ نیست

اینجا یه نکته‌ی زمانی خیلی مهم داریم.

اگر یه Tutorial قدیمی MCP پیدا کنید، ممکنه معماری‌ای رو توضیح بده که همین الان دیگه جدیدترین روش نیست.

آخرین Specification در زمان نوشتن این مقاله نسخه‌ی:

2026-07-28

ـه.

و یکی از بزرگ‌ترین تغییراتش اینه که Core Protocol برای HTTP به سمت Stateless رفت.

در نسخه‌های قبلی، Client اول یه Session ایجاد می‌کرد و یه Mcp-Session-Id می‌گرفت.

بعد درخواست‌های بعدی باید به همون Session مربوط می‌بودن.

برای یه ابزار لوکال مشکل بزرگی نیست.

برای Infrastructure بزرگ؟

داستان فرق می‌کنه.

فرض کنید صد تا Instance از MCP Server دارید پشت Load Balancer.

Session یعنی باید بدونید درخواست بعدی بره سمت کدوم Instance.

یا Shared State داشته باشید.

یا Sticky Session.

نسخه‌ی جدید می‌گه درخواست تا حد ممکن خودش همه‌ی اطلاعات لازم رو داشته باشه.

در نتیجه می‌تونه به هر Instance سالمی برسه.

یعنی MCP داره کم‌کم بیشتر شبیه چیزی می‌شه که واقعاً می‌تونه روی Infrastructure وب در Scale بالا زندگی کنه. (Model Context Protocol Blog)

این تغییر شاید برای یه نفر که فقط یه Filesystem MCP روی لپ‌تاپش داره خیلی هیجان‌انگیز نباشه.

ولی برای کسی که می‌خواد MCP رو برای ده هزار Agent سرو کنه؟

خیلی مهمه.

یعنی الان Session کلاً مرده؟

در Core جدید Protocol، مدل HTTP جدید Stateless شده.

ولی Application شما هنوز می‌تونه State داشته باشه.

مثلاً یه Tool ممکنه بگه:

create_checkout_session()

و یه Handle برگردونه:

checkout_92841

بعد Tool بعدی اون Handle رو بگیره.

State ناپدید نشده.

فقط Protocol دیگه سعی نمی‌کنه یه Session مخفی رو پشت Connection برای شما مدیریت کنه.

State می‌تونه واضح و قابل‌حمل بشه.

این فرق کوچیکی نیست.

پس چرا یهو همه MCP دارن؟

چون Network Effect شروع شده.

وقتی MCP معرفی شد، صرفاً پروژه‌ی Anthropic بود.

ولی داستان همون‌جا نموند.

تا دسامبر ۲۰۲۵ MCP روی محصولاتی مثل ChatGPT، Claude، Cursor، Gemini، Microsoft Copilot و VS Code پشتیبانی می‌شد و بیش از ۱۰ هزار MCP Server عمومی فعال گزارش شده بود. (Anthropic)

بعد اتفاق مهم‌تری افتاد.

Anthropic مالکیت پروژه رو به Agentic AI Foundation زیرمجموعه‌ی Linux Foundation منتقل کرد.

AAIF با مشارکت Anthropic، Block و OpenAI شکل گرفت و شرکت‌هایی مثل Google، Microsoft، AWS و Cloudflare هم ازش حمایت کردند. (Anthropic)

یعنی MCP قرار نبود:

Anthropic Protocol™

بمونه.

حرکت به سمت Governance مستقل و Vendor-neutral دقیقاً چیزیه که یه استاندارد برای رشد بلندمدت لازم داره.

و رشدش هم کم نبوده.

Maintainerهای MCP در انتشار Specification جولای ۲۰۲۶ گفتن SDKهای Tier 1 در مجموع به نزدیک نیم میلیارد Download در ماه رسیده‌اند و SDKهای TypeScript و Python هرکدوم از مرز یک میلیارد Download کلی عبور کرده‌اند. (Model Context Protocol Blog)

البته Download تعداد User نیست.

CI، Cache، Build و نصب‌های تکراری می‌تونن عدد Package Download رو شدیداً بالا ببرن.

ولی برای فهمیدن Scale اکوسیستم، عدد کوچیکی هم نیست.

مشکل N×M

به نظرم دلیل اصلی موفقیت MCP رو می‌شه با یه مسئله‌ی خیلی خسته‌کننده توضیح داد.

فرض کنید:

۱۰ تا AI App داریم.

و ۱۰۰ تا Service.

اگر هر App بخواد برای هر Service یه Integration اختصاصی بسازه، در بدترین حالت داریم درباره‌ی:

10 × 100 = 1000 integrations

حرف می‌زنیم.

با یه Protocol مشترک، هدف اینه که سمت AI یک بار MCP رو بفهمه و سمت Service هم یک بار MCP رو ارائه بده.

تصویر از این:

A ─ X
A ─ Y
A ─ Z

B ─ X
B ─ Y
B ─ Z

C ─ X
C ─ Y
C ─ Z

به چیزی شبیه این تبدیل می‌شه:

A ─┐
B ─┼── MCP ── X
C ─┘          Y
              Z

دنیا در عمل هیچ‌وقت به این تمیزی نیست :))

هر Client Compatibility خودش رو داره.

هر Server ممکنه Extensionهای متفاوتی داشته باشه.

نسخه‌های Protocol فرق می‌کنن.

Authentication فرق می‌کنه.

ولی کاهش Integrationهای اختصاصی، ارزش اصلی داستانه.

چرا مدل نمی‌تونه مستقیم API رو بخونه؟

می‌تونه.

این خیلی مهمه.

MCP جادو نیست.

شما می‌تونید OpenAPI Spec سرویس رو به Agent بدید.

می‌تونید Function Calling خود Provider رو استفاده کنید.

می‌تونید SDK مستقیم بنویسید.

می‌تونید یه REST endpoint معمولی داشته باشید.

MCP نیومده بگه همه‌ی اینا اشتباه بودن.

موضوع Interoperabilityـه.

اگر Tool رو مستقیم برای یه Provider خاص تعریف کنید، شاید به همون Runtime بچسبه.

اگر به‌عنوان MCP Server ارائه‌ش کنید، Hostهای مختلفی که MCP رو پشتیبانی می‌کنن می‌تونن ازش استفاده کنن.

فرقش بیشتر شبیه اینه:

"چطوری یه API بسازیم؟"

در مقابل:

"چطوری قابلیت این API رو به Agentهای مختلف معرفی کنیم؟"

MCP بیشتر جواب سؤال دومه.

پس هر چیزی رو MCP کنیم؟

نه لطفاً :))

این همون نقطه‌ایه که هر تکنولوژی محبوب بهش می‌رسه.

یه چیزی خوب می‌شه.

بعد همه سعی می‌کنن هر چیزی رو باهاش بسازن.

یه Calculator دارید که فقط دو عدد جمع می‌کنه؟

احتمالاً لازم نیست Cluster هشت‌نودی از MCP Serverها براش راه بندازید.

اگر Agent شما فقط یه Function داخلی نیاز داره که هیچ جای دیگه‌ای استفاده نمی‌شه، یه Tool عادی شاید خیلی ساده‌تر باشه.

MCP وقتی جذابه که:

قابلیتی قراره بین چند Agent یا Host قابل استفاده باشه.

داده یا ابزار بیرون از مدل دارید.

می‌خواید Integration قابل‌حمل باشه.

یا می‌خواید یه Interface استاندارد برای Agentها ارائه بدید.

استاندارد بودن خودش هدف نیست.

باید یه مشکل واقعی رو حل کنه.

یه MCP Server خوب با یه MCP Server بد فرق داره

اینکه یه API رو برداریم و همه‌ی ۴۰۰ Endpointش رو تبدیل کنیم به Tool، الزاماً MCP Server خوبی نمی‌سازه.

Agent قرار نیست Postman باشه.

مثلاً این:

get_api_v2_users_id_orders_status_update()

اسم Tool خوبی نیست.

Server باید Interfaceـی بسازه که مدل بتونه بفهمتش.

مثلاً:

get_order
cancel_order
refund_order

Descriptionها مهمن.

Schema مهمه.

اسم Tool مهمه.

Result مهمه.

و حتی تعداد Toolها هم مهمه.

اگر ۷۰۰ Tool رو یه‌جا جلوی مدل پرت کنید، مشکل Integration رو حل کردید و یه مشکل جدید ساختید:

حالا مدل باید بفهمه کدوم یکی از ۷۰۰ تا رو استفاده کنه.

استاندارد خوب، Design بد رو درمان نمی‌کنه.

و بعد UI وارد MCP شد

داستان حتی از Tool هم جلوتر رفته.

MCP الان Extension Framework داره و یکی از Extensionهای جدیدش MCP Appsـه.

ایده اینه که یه Tool فقط Text یا JSON برنگردونه.

بتونه یه UI تعاملی هم همراه خودش ارائه کنه.

یعنی مثلاً Tool یه نمودار، Form یا Interface کوچیک داخل Host نمایش بده.

این خیلی جالبه.

چون اول داستان این بود:

مدل رو به Data وصل کنیم.

بعد شد:

مدل رو به Tool وصل کنیم.

حالا داریم می‌رسیم به:

خود Tool حتی UI قابل نمایش داخل AI App هم داشته باشه.

Specification جولای ۲۰۲۶ Extensionها رو به بخش رسمی‌تری از معماری MCP تبدیل کرد تا قابلیت‌هایی مثل MCP Apps و Tasks بدون باد کردن Core Protocol رشد کنن. (Model Context Protocol Blog)

پروتکل داره از یه Connector ساده تبدیل می‌شه به یه Ecosystem.

WebMCP حالا خیلی منطقی‌تره

حالا برگردیم به قسمت قبلی.

WebMCP عجیب به نظر می‌رسید چون گفتیم یه Website می‌تونه Toolهاش رو به Agent معرفی کنه.

ولی الان رابطه‌ش مشخص‌تره.

MCP می‌گه:

Agentها باید یه زبان مشترک برای کشف و استفاده از Toolها داشته باشن.

WebMCP می‌گه:

خب، چرا Website هم نتونه همین قابلیت‌ها رو داخل Browser به Agent ارائه بده؟

Kitesurf هم گفت:

اصلاً چرا Browser مورد استفاده‌ی Agent باید دقیقاً همون Browser انسان باشه؟

تکه‌ها دارن کنار هم قرار می‌گیرن.

             AGENT

               │
        ┌──────┴──────┐
        │             │
     Browser        MCP Client
        │             │
     WebMCP        MCP Server
        │             │
     Website        Services

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

Agentic Internet.

اینترنتی که فقط Document و UI برای انسان نداره.

کم‌کم Interface برای Agent هم داره.

ولی یه مشکل خیلی بزرگ داریم

تا اینجا همه‌چی قشنگ بود.

Agent می‌تونه GitHub رو کنترل کنه.

فایل بخونه.

دیتابیس Query کنه.

Email بفرسته.

Deploy کنه.

Issue بسازه.

شاید حتی خرید کنه.

خب...

یه سؤال.

چه کسی گفته اجازه داره؟

فرض کنید این Tool رو داریم:

delete_database()

Schema هم عالیه.

Description هم عالیه.

MCP Connection هم کاملاً استاندارده.

Congratulations.

الان یه راه استاندارد و بسیار تمیز برای پاک کردن دیتابیس داریم :))

خود Protocol نمی‌تونه به‌تنهایی تصمیم بگیره:

کاربر واقعاً این کار رو خواسته؟

مدل درست متوجه شده؟

Prompt Injection وسط کار نبوده؟

این Agent باید اجازه‌ی Delete داشته باشه؟

آیا قبلش باید Confirmation بگیریم؟

Credential متعلق به کیه؟

اگر یه MCP Server مخرب Tool Description خودش رو طوری نوشته باشه که مدل رو گول بزنه چی؟

اینجا دیگه مشکل Connectivity نیست.

مشکل Trustـه.

و هرچی MCP قوی‌تر بشه، این سؤال مهم‌تر می‌شه.

ساختن پلی که AI رو به همه‌چیز وصل کنه خیلی باحاله.

تا وقتی نفهمیم دقیقاً چه کسی اجازه داره از روی اون پل رد بشه.

قسمت بعدی می‌ریم سراغ همین داستان:

Agent Security.

Permission، OAuth، Identity، Prompt Injection و اینکه واقعاً تا کجا باید به یه AI اجازه بدیم از طرف ما کاری انجام بده.

تا وبلاگ بعدی، بدرود!