---

Agentic Internet / 02

چرا AI باید دنبال دکمه بگرده؟ WebMCP چیه؟

۸ شهریور ۱۴۰۵

سلام سلام!

قسمت قبلی درباره‌ی Kitesurf حرف زدیم.

Cloudflare یه Browser Engine ساخته که از اول برای Agent طراحی شده. سبک‌تره، لازم نیست همه‌ی چیزهایی که ما آدم‌ها از Chrome انتظار داریم رو داشته باشه و می‌تونه یه Task رو انجام بده و بعد هم جمع کنه بره.

ولی آخر مقاله یه سؤال گذاشتیم وسط.

چرا Agent اصلاً باید با یه سایت مثل من و شما کار کنه؟

فرض کنید به Agent می‌گید:

برو توی یه فروشگاه، یه مانیتور ۲۷ اینچ زیر ۳۰۰ دلار پیدا کن.

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

Search Box رو پیدا می‌کنه.

توش تایپ می‌کنه.

دکمه Search رو پیدا می‌کنه.

نتایج رو می‌خونه.

Filter قیمت رو پیدا می‌کنه.

Filter سایز رو پیدا می‌کنه.

بعد امیدواریم طراح سایت وسط این مدت تصمیم نگیره همه‌ی دکمه‌ها رو جابه‌جا کنه :))

یه سؤال ساده.

خود سایت که می‌دونه Search چطوری کار می‌کنه.

پس چرا مستقیم به Agent نگه:

search_products

؟

خب، این تقریباً همون چیزیه که WebMCP می‌خواد درست کنه.

اول یه سوءتفاهم رو جمع کنیم

WebMCP یه MCP Server معمولی نیست که یه جایی روی VPS روشنش کنید و بعد Claude Code رو بهش وصل کنید.

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

WebMCP داخل خود Browser اتفاق می‌افته.

سایت می‌تونه یه سری Tool تعریف کنه و Browser اون‌ها رو در اختیار Agentی بذاره که داره با اون صفحه کار می‌کنه.

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

Agent
  ↓
Screenshot
  ↓
"فکر کنم این دکمه Search باشه"
  ↓
Click
  ↓
DOM
  ↓
"این احتمالاً نتیجه‌ی جست‌وجوعه"

می‌رسیم به چیزی شبیه این:

Agent
  ↓
search_products({
  query: "27 inch monitor",
  max_price: 300
})
  ↓
Result

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

و دقیقاً به همین دلیل خیلی بهتره.

یه سایت برای انسان، یه interface برای Agent

تا امروز Frontend رو برای آدم‌ها می‌ساختیم.

Button.

Form.

Dropdown.

Modal.

Menu.

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

وقتی یه دکمه می‌بینید که روش نوشته "Add to cart"، لازم نیست سورس JavaScript صفحه رو بخونید تا بفهمید چه کاری انجام می‌ده.

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

Agent اما چنین شانسی نداره.

یه Agent با Browser Automation معمولاً باید از DOM، Accessibility Tree، Screenshot یا ترکیبی از این‌ها بفهمه صفحه چه شکلیه و چه کاری می‌تونه توش انجام بده.

WebMCP یه قرارداد جدا برای اون می‌سازه.

مثلاً فروشگاه می‌تونه بگه:

document.modelContext.registerTool({
  name: "search_products",
  description: "Search products in the store",
  inputSchema: {
    type: "object",
    properties: {
      query: {
        type: "string"
      }
    }
  },

  execute: async ({ query }) => {
    return searchProducts(query);
  }
});

Agent دیگه لازم نیست Search Box رو پیدا کنه.

مرورگر بهش می‌گه:

این صفحه یه Tool داره به اسم search_products.

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

کارش هم اینه.

اگر لازم داری، صداش بزن.

WebMCP در نسخه‌ی فعلی خودش این Toolها رو از طریق document.modelContext در صفحه در اختیار Browser Agent قرار می‌ده. این استاندارد هنوز آزمایشیه و Cloudflare می‌گه Chrome 146 به‌صورت experimental ازش پشتیبانی می‌کنه.

این خیلی شبیه API نیست؟

آره.

و نه.

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

GET /api/products?q=monitor

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

ولی از کجا باید بفهمه این Endpoint وجود داره؟

Authenticationش چیه؟

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

Schema خروجیش چیه؟

آیا اصلاً Publicـه؟

شاید شما یه Swagger عالی هم داشته باشید، ولی Browser Agentی که همین الان توی صفحه است الزاماً چیزی درباره‌ی اون نمی‌دونه.

WebMCP Tool رو کنار همون تجربه‌ی وب قرار می‌ده.

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

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

مثلاً کاربر الان داخل سایت Loginـه.

Agentی که از طرف همین کاربر کار می‌کنه شاید بخواد سفارش‌های خودش رو ببینه.

در مدل Cloudflare، Site MCP Server Pack می‌تونه درخواست رو از همون Origin و با Session موجود کاربر به MCP Server سایت بفرسته. یعنی قرار نیست Agent لزوماً از صفر یه Login عجیب جداگانه راه بندازه.

یه مثال واقعی‌تر

فرض کنید یه سایت بلیت هواپیما داریم.

الان یه Agent ممکنه مجبور بشه این کارها رو انجام بده:

مبدأ رو پیدا کن.

تهران رو تایپ کن.

صبر کن Dropdown باز شه.

روی Tehran کلیک کن.

مقصد رو پیدا کن.

Istanbul رو تایپ کن.

Calendar رو باز کن.

ماه بعد رو بزن.

روز مورد نظر رو پیدا کن.

روی Search کلیک کن.

صبر کن.

کارت‌های پرواز رو بخون.

اگر طراح Frontend فردا Calendar رو عوض کنه، Agent دوباره باید یاد بگیره باهاش چطوری کار کنه.

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

search_flights({
  from: "IKA",
  to: "IST",
  date: "2026-09-20"
})

UI انسان می‌تونه هرچقدر دوست داره تغییر کنه.

دکمه گرد بشه.

Calendar بره توی Modal.

React بره، Svelte بیاد.

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

قراردادش search_flightsـه.

این بخش WebMCP به نظرم از همه جذاب‌تره.

Frontend دیگه تنها راه استفاده از یه Web App نیست.

اصلاً MCP این وسط چه‌کاره‌ست؟

اسم کامل MCP می‌شه Model Context Protocol.

اگر با Agentها کار کرده باشید احتمالاً دیگه اسمش از یخچال هم براتون آشناتره.

ایده‌ی پایه‌ش اینه که یه Agent بتونه بفهمه یه سرویس چه Toolهایی داره و چطور باید اون‌ها رو صدا بزنه.

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

Tools:

- search_issues
- create_issue
- get_repository

مدل لازم نیست implementation این توابع رو بدونه.

اسم، توضیح و Schema ورودی رو می‌بینه و تصمیم می‌گیره کدوم Tool رو لازم داره.

WebMCP همین مدل فکری رو میاره داخل Browser.

Cloudflare هم توی پیاده‌سازی خودش از نوع‌های Tool و CallToolResult خود MCP استفاده می‌کنه. برای Agentی که از قبل MCP رو می‌فهمه، این‌ها هم Tool معمولی محسوب می‌شن.

یه جورایی Browser داره تبدیل می‌شه به یکی دیگه از جاهایی که MCP توش زندگی می‌کنه.

ولی یه مشکل داریم

همه‌ی سایت‌ها قرار نیست فردا بشینن WebMCP پیاده کنن.

اصلاً خیلی از سایت‌ها هنوز Accessibility درست ندارن، چه برسه به اینکه برای Agentها Tool تعریف کنن :))

Cloudflare برای همین یه راه جالب ساخته.

اگر سایت پشت Cloudflare باشه، WebMCP Developer Preview رو می‌شه از Dashboard فعال کرد.

Cloudflare موقع ارسال HTML یه Script کوچیک به صفحه اضافه می‌کنه.

تقریباً چیزی شبیه این:

<script
  type="module"
  src="/.webmcp/bridge.js"
  data-packs="c2pa,mcp-server-client"
  data-mcp-url="/mcp"
></script>

خود Origin لازم نیست تغییر کنه.

Bridge داخل صفحه اجرا می‌شه، Tool Packهای فعال رو پیدا می‌کنه و Toolها رو از طریق registerTool ثبت می‌کنه.

اگر Browser هم WebMCP نداشته باشه؟

هیچی.

Bridge کاری نمی‌کنه و سایت مثل قبل باز می‌شه.

Cloudflare در Developer Preview فعلی این تزریق رو روی Edge با HTMLRewriter انجام می‌ده، بنابراین برای فعال کردن نسخه‌ی خودش لازم نیست کد Origin سایت تغییر کنه.

Tool Pack دیگه چیه؟

Cloudflare برای WebMCP یه مفهوم به اسم Pack گذاشته.

به‌جای اینکه هر قابلیت رو جدا جدا فعال کنید، چند Tool مرتبط می‌تونن داخل یه Pack باشن.

نسخه‌ی Developer Preview فعلی دو Pack داره.

یکی مربوط به Content Credentialsـه.

اون یکی Site MCP Serverـه.

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

اگر سایت از قبل MCP Server داشته باشه، Bridge می‌تونه Toolهای اون Server رو بگیره و داخل WebMCP ثبت کنه.

فرض کنید MCP Server شما این Tool رو داره:

search_products

Bridge از tools/list می‌فهمه وجود داره و یه Proxy برایش ثبت می‌کنه.

بعد Agent داخل Browser می‌تونه اون رو مثل یه WebMCP Tool عادی صدا بزنه.

Cloudflare درخواست رو از داخل صفحه به MCP Endpoint همون سایت می‌فرسته.

یعنی لازم نیست یه بار Toolهای MCP رو بسازید و یه بار دوباره برای WebMCP.

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

داستان Content Credentials هم جالبه

Pack دیگه‌ی Cloudflare مربوط به C2PAـه.

C2PA یه استاندارد برای ثبت اطلاعات منشأ و تاریخچه‌ی محتوای دیجیتاله.

مثلاً یه عکس ممکنه Metadata داشته باشه که بگه با چه ابزاری ساخته شده یا چه اطلاعاتی درباره‌ی سازنده‌اش ثبت شده.

Cloudflare یه Tool به اسم scan_images_c2pa نشون داده که می‌تونه عکس‌های صفحه رو بررسی کنه و خلاصه‌ای از Credentialهای موجود بده.

Agent لازم نیست یکی‌یکی تصاویر رو دانلود کنه و خودش Formatهای Metadata رو بفهمه.

یه Tool مشخص داره.

البته یه نکته‌ی مهم هست.

در Preview فعلی، Cloudflare Metadata رو می‌خونه ولی Signature رو cryptographically verify نمی‌کنه. نتیجه صراحتاً signatureVerified: false برمی‌گردونه.

این از اون جزئیاتیه که اگر فقط تیتر خبر رو بخونیم راحت گم می‌شه.

"اطلاعات C2PA پیدا شد" با "این اطلاعات cryptographically تأیید شد" یکی نیست.

حالا Kitesurf رو دوباره بیاریم وسط

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

Kitesurf مشکل Browser رو حل می‌کرد.

Agent یه Browser سبک‌تر می‌خواست که برای کار خودش ساخته شده باشه.

WebMCP مشکل Interface رو هدف گرفته.

Agent اصلاً چرا باید توی اون Browser دنبال Button بگرده؟

Cloudflare BrowserRun هم الان WebMCP رو می‌فهمه.

در نتیجه یه طرف ماجرا Browser داریم که Toolهای سایت رو Discover و Call می‌کنه.

اون طرف سایت داریم که Toolهاش رو ارائه می‌ده.

این دو با WebMCP وسط راه همدیگه رو پیدا می‌کنن.

یه تصویر ساده:

Human
  ↓
Website UI
  ↓
Buttons / Forms / Menus

و کنارش:

AI Agent
  ↓
Browser
  ↓
WebMCP
  ↓
Tools

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

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

و اینجاش یکم ترسناکه

فرض کنید یه سایت این Toolها رو بده:

search_products
get_product
add_to_cart
checkout

سه تای اول خیلی عادیه.

چهارمی دیگه یه سؤال مهم ایجاد می‌کنه.

Agent واقعاً اجازه داره checkout رو اجرا کنه؟

اگر قیمت رو اشتباه فهمیده باشه چی؟

اگر Prompt Injection داخل یه صفحه باعث بشه Tool اشتباه رو صدا بزنه چی؟

اگر Agent به‌جای یه بار، ده بار عملیات رو اجرا کنه چی؟

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

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

اینجا بحث Permission، Identity و Confirmation خیلی جدی‌تر می‌شه.

یه انسان شاید در یک دقیقه دو تا دکمه اشتباه بزنه.

یه Agent می‌تونه در همون زمان صدها Tool Call اشتباه انجام بده.

Cloudflare هم در بحث امنیت Agentها دقیقاً روی همین تفاوت تأکید کرده. Agentها با سرعت انسانی کار نمی‌کنن و یک تصمیم اشتباه می‌تونه بارها تکرار بشه.

پس Agentic Internet فقط این نیست که "وای چه باحال، AI می‌تونه سایت رو کنترل کنه."

باید بفهمیم چه کسی Agent رو فرستاده.

Agent به چه چیزی دسترسی داره.

هر Tool تا کجا اجازه‌ی عمل داره.

و کجا باید دوباره از خود آدم اجازه بگیره.

این قسمت رو نگه داریم برای یه مقاله‌ی جدا، چون خودش به‌اندازه‌ی کافی دردسر داره :))

آیا WebMCP قراره API رو بکشه؟

نه.

بعید می‌دونم اصلاً هدفش این باشه.

API هنوز برای ارتباط مستقیم بین نرم‌افزارها خیلی خوبه.

MCP Server برای ارائه‌ی Tool به Agent خارج از Browser کاربرد خودش رو داره.

Browser Automation هم برای سایت‌هایی که هیچ Interface مخصوص Agent ندارن باقی می‌مونه.

WebMCP یه مسیر دیگه اضافه می‌کنه.

وقتی Agent واقعاً داخل یه Web Session قرار داره، خود سایت می‌تونه بهش بگه:

"این کارهایی هست که اینجا می‌تونی انجام بدی."

این خیلی تمیزتر از اینه که Agent هر بار Screenshot بگیره و حدس بزنه کدوم مستطیل روی صفحه دکمه‌ی Searchـه.

هنوز خیلی زوده

این قسمت رو نباید فراموش کنیم.

WebMCP هنوز یه استاندارد جاافتاده و همه‌گیر نیست.

پشتیبانی Chrome فعلاً experimentalـه.

نسخه‌ی Cloudflare هم Developer Previewـه.

API و شکل استاندارد ممکنه در طول مسیر تغییر کنه.

پس اگر فردا دیدید یکی نوشته:

"از امروز همه‌ی سایت‌ها باید WebMCP داشته باشن"

احتمالاً یه مقدار جوگیر شده :))

ولی این دلیل نمی‌شه ایده‌ش رو نادیده بگیریم.

چند سال پیش اینکه یه Agent خودش وارد سایت بشه و کاری انجام بده بیشتر Demo بود.

الان داریم درباره‌ی Browser مخصوص Agent، Protocol مخصوص Toolها، Identity مخصوص Botها و حتی Payment برای Agentها حرف می‌زنیم.

Cloudflare برای چیزی که داره شکل می‌گیره چهار کلمه استفاده می‌کنه:

Readable.

Discoverable.

Callable.

Payable.

سایت برای Agent قابل خوندن باشه.

Agent بتونه قابلیت‌هاش رو پیدا کنه.

بتونه اون قابلیت‌ها رو صدا بزنه.

و وقتی لازم شد، بتونه پول هم پرداخت کنه.

Kitesurf قسمت Browser این داستان بود.

WebMCP قسمت Callableـشه.

من هنوز Button رو دوست دارم

برای خودم؟

صددرصد.

من دوست ندارم سایت فروشگاه تبدیل بشه به یه صفحه‌ی خالی که فقط search_products() داره :))

UI برای آدم‌هاست و همچنان لازمش داریم.

نکته اینه که AI مجبور نیست ادای آدم رو دربیاره تا از همون سرویس استفاده کنه.

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

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

حالا شاید برای Agent هم یه Interface مخصوص خودش داشته باشیم.

این به نظرم منطقی‌تر از آینده‌ایه که توش میلیون‌ها Agent شبانه‌روز Screenshot می‌گیرن و سعی می‌کنن بفهمن یه دکمه کجاست.

و البته یه مشکل کوچیک باقی می‌مونه.

وقتی به Agent Tool واقعی بدیم، باید مطمئن بشیم باهاش چه غلطی می‌کنه.

قسمت بعدی می‌ریم سراغ خود MCP.

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

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