معرفی WebMCP؛ زمانی که هوش مصنوعی مستقیماً با سیستم شما کار می‌کند

پیش از آنکه وارد جزئیات WebMCP شویم، بهتر است ابتدا بدانیم MCP (Model Context Protocol) چیست و چرا در مدت کوتاهی به یکی از مهم‌ترین استانداردهای دنیای هوش مصنوعی تبدیل شده است.

اگر به مخزن GitHub این پروژه که توسط Anthropic معرفی شده نگاهی بیندازید، هدف آن کاملاً مشخص است: ایجاد یک استاندارد متن‌باز و یکپارچه برای اتصال مدل‌های هوش مصنوعی به منابع داده، سرویس‌ها و ابزارهای موجود در سیستم‌های نرم‌افزاری.

به زبان ساده، MCP را می‌توان USB-C دنیای هوش مصنوعی دانست. همان‌طور که USB-C یک رابط استاندارد برای اتصال دستگاه‌های مختلف فراهم می‌کند، MCP نیز یک زبان مشترک در اختیار مدل‌های هوش مصنوعی قرار می‌دهد تا بتوانند با سیستم‌ها و سرویس‌های گوناگون ارتباط برقرار کنند.

تا پیش از ظهور MCP، مدل‌های هوش مصنوعی عمدتاً در محیطی ایزوله فعالیت می‌کردند. اگر می‌خواستید یک مدل AI به پایگاه داده، فایل‌های سیستم یا سرویس‌های داخلی نرم‌افزار شما دسترسی داشته باشد، معمولاً باید برای هر مورد یک Integration اختصاصی طراحی می‌کردید. اما MCP این مسئله را استاندارد می‌کند.

در چنین معماری‌ای، هوش مصنوعی دیگر صرفاً یک Chatbot نیست. مدل می‌تواند در نقش یک Agent ظاهر شود، داده‌های موردنیاز را از سرویس‌های مختلف دریافت کند و حتی عملیات واقعی را در سیستم اجرا کند.

اما یک نکته مهم وجود دارد: برای اینکه هوش مصنوعی بتواند با سیستم شما کار کند، خود سیستم نیز باید برای این نوع تعامل آماده شده باشد.

سیستم شما باید زبان هوش مصنوعی را بفهمد

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

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

اگر منطق اصلی سیستم شما پشت Buttonها، Formها، Modalها و Workflowهای رابط کاربری پنهان شده باشد، عملاً چیزی برای استفاده Agentها وجود نخواهد داشت.

به همین دلیل، اگر می‌خواهید سیستم شما واقعاً آماده استفاده توسط هوش مصنوعی باشد، باید نگاه خود را به معماری نرم‌افزار تغییر دهید. اینجاست که مفاهیمی مانند Headless Architecture، Separation of Concerns و Service-Oriented Design اهمیت پیدا می‌کنند.

معماری Headless (Headless Architecture): خداحافظی با وابستگی به UI

یکی از مهم‌ترین پیش‌نیازهای استفاده مؤثر از MCP، داشتن یک معماری Headless است.

منظور از Headless Architecture این است که رابط کاربری (UI) صرفاً وظیفه دریافت ورودی و نمایش خروجی را بر عهده داشته باشد و هیچ بخش مهمی از Business Logic در آن قرار نگرفته باشد.

در بسیاری از پروژه‌ها، عملیات اصلی سیستم در دل کامپوننت‌های Frontend پیاده‌سازی می‌شود. این رویکرد شاید در کوتاه‌مدت ساده به نظر برسد، اما در بلندمدت باعث می‌شود قابلیت‌های سیستم فقط از طریق UI قابل استفاده باشند.

فرض کنید در یک سامانه معاملات سهام، قابلیت ثبت سفارش خرید یا فروش دارید.

در معماری صحیح، باید سرویسی مستقل با متدی مانند زیر وجود داشته باشد:

await createOrder(data)

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

مزیت این رویکرد این است که همان متد می‌تواند توسط:

• رابط کاربری وب

• اپلیکیشن موبایل

• یک Job زمان‌بندی‌شده

• یک Script داخلی

• یا یک Agent مبتنی بر MCP

فراخوانی شود.

به بیان دیگر، سیستم شما دیگر به وجود یک صفحه یا دکمه خاص وابسته نخواهد بود.

پایان دوران God Componentها

یکی از رایج‌ترین مشکلات در پروژه‌های Frontend، ایجاد کامپوننت‌هایی است که تقریباً همه مسئولیت‌های سیستم را بر عهده می‌گیرند؛ چیزی که معمولاً با عنوان God Component شناخته می‌شود.

چنین کامپوننت‌هایی علاوه بر نمایش رابط کاربری، مسئول مواردی مانند:

• فراخوانی APIها

• Validation

• مدیریت Cache

• مدیریت State

• اعمال Business Ruleها

• مدیریت Workflow

نیز هستند.

نتیجه این رویکرد، کدی است که به‌شدت به UI وابسته می‌شود و استفاده مجدد از منطق سیستم را دشوار می‌کند.

اگر قرار است یک Agent هوشمند مستقیماً با سیستم شما تعامل داشته باشد، باید این مسئولیت‌ها از UI جدا شوند. کامپوننت‌ها باید تنها نقش نمایش و تعامل با کاربر را بر عهده داشته باشند و منطق اصلی سیستم در لایه‌های مستقل پیاده‌سازی شود.

تابع باید واقعاً Self-Contained باشد

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

یک سؤال ساده می‌تواند وضعیت معماری شما را مشخص کند:

«آیا این متد بدون وابستگی به Stateهای Vue یا React، بدون Watcherها، بدون Router و بدون Contextهای رابط کاربری نیز قابل اجرا است؟»

اگر پاسخ منفی باشد، آن متد هنوز Self-Contained نیست.

برای مثال، متدی مانند:

await createOrder({
  symbol,
  quantity,
  price,
  accountId
});

باید بتواند تمام Validationها، Business Ruleها و منطق اجرایی موردنیاز را خودش مدیریت کند.

فرقی نمی‌کند این متد از طریق UI فراخوانی شود، توسط یک Cron Job اجرا شود یا یک Agent از طریق MCP آن را صدا بزند؛ رفتار سیستم باید در تمام سناریوها یکسان باشد.

مدیریت جریان کار (Orchestration) کجاست؟

زمانی که سرویس‌های شما مستقل و Self-Contained باشند، مدیریت Workflowها نیز بسیار ساده‌تر خواهد شد.

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

فردا ساعت ۹ صبح، اگر قیمت سهم X در بازه مشخصی قرار داشت، برای من خرید انجام بده.

در چنین شرایطی Agent می‌تواند به‌سادگی جریان کار را Orchestrate کند:

const price = await getPrice(symbol);

await validatePrice(symbol, price);

await createOrder(data);

در اینجا Agent فقط نقش هماهنگ‌کننده (Orchestrator) را بر عهده دارد و هر سرویس مسئول انجام وظیفه تخصصی خود است.

این دقیقاً همان مدلی است که MCP برای آن طراحی شده است.

معرفی قابلیت‌های سیستم به هوش مصنوعی

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

در MCP هر قابلیت سیستم به‌صورت یک Tool معرفی می‌شود. هر Tool دارای یک Schema مشخص است که به مدل توضیح می‌دهد:

• این ابزار چه کاری انجام می‌دهد.

• چه پارامترهایی نیاز دارد.

• فرمت ورودی‌ها چیست.

• چه محدودیت‌هایی وجود دارد.

نمونه زیر یک Tool برای ثبت سفارش خرید یا فروش سهام را نشان می‌دهد:

{
  "name": "create_order",
  "description": "ثبت یک سفارش جدید برای خرید یا فروش سهام در سیستم",
  "inputSchema": {
    "type": "object",
    "properties": {
      "symbol": {
        "type": "string",
        "description": "نماد سهم"
      },
      "quantity": {
        "type": "integer",
        "description": "تعداد سهم"
      },
      "price": {
        "type": "number",
        "description": "قیمت سفارش"
      },
      "accountId": {
        "type": "string",
        "description": "شناسه حساب کاربری"
      }
    },
    "required": [
      "symbol",
      "quantity",
      "price",
      "accountId"
    ]
  }
}

زمانی که مدل این Schema را دریافت می‌کند، دقیقاً متوجه می‌شود که برای اجرای Tool مربوط به ثبت سفارش چه اطلاعاتی لازم است.

سپس مقادیر موردنیاز را از درخواست کاربر استخراج می‌کند و آن‌ها را به سرویس مربوطه ارسال می‌کند.

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

جمع‌بندی

WebMCP صرفاً یک فناوری جدید برای اتصال هوش مصنوعی به نرم‌افزارها نیست؛ بلکه توسعه‌دهندگان را وادار می‌کند معماری سیستم‌های خود را بازنگری کنند.

هرچه Business Logic مستقل‌تر باشد، وابستگی به UI کمتر شود و سرویس‌ها Self-Contained‌تر طراحی شوند، استفاده از Agentهای هوشمند نیز ساده‌تر و مؤثرتر خواهد بود.

در چنین معماری‌ای، UI دیگر تنها مصرف‌کننده قابلیت‌های سیستم نیست. وب‌سایت، اپلیکیشن موبایل، سرویس‌های داخلی، Scriptها و Agentهای مبتنی بر هوش مصنوعی همگی می‌توانند از همان قابلیت‌های مشترک استفاده کنند.

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