في 28 مايو 2026، قمت بمسح 111,076 موقعًا من بين أفضل 200,000 موقع على الإنترنت بحثًا عن ترويسة HTTP محددة. النتيجة كانت صفرًا بالضبط. لم يقم أي نطاق بتطبيق WebMCP في بيئة الإنتاج. ولا حتى موقع واحد من شركات Fortune 500. ولا شركة ناشئة تسعى للبقاء في المقدمة. ولا حتى بيئة تطوير نسي مطورها إزالتها. صفر. لذلك، قمت بتطبيقه على موقعين. وإليكم ما اكتشفته.
المتطلبات المسبقة
لمتابعة أقسام التنفيذ، ستحتاج إلى:
- Node.js 18+ و npm أو pnpm.
- مشروع SvelteKit أو Next.js (يغطي المقال كليهما).
- Chrome 146+ Canary للاختبار.
- تسجيل أداة WebMCP (يمكن تنزيلها من قناة Chrome Canary).
- إلمام أساسي بـ TypeScript وتعريفات JSON schema.
- موقع منشور على Vercel أو Netlify أو ما شابه (لمقاربة
.well-known manifest).
لا تحتاج إلى أي وكيل AI أو إضافة متصفح خاصة. يتدهور التنفيذ بصمت في متصفحات غير Canary، لذا لن يتعطل موقعك الإنتاجي.
ما هو WebMCP في الواقع (ولماذا يهم في عام 2026)؟
إذا كنت تتابع بيانات حركة مرور وكلاء الذكاء الاصطناعي (AI)، فإن رقمًا واحدًا يجب أن يثير قلقك قليلًا: نسبة الزحف إلى الإحالة لـ ClaudeBot هي 10,600:1. وهذا يعني أنه مقابل كل 10,600 صفحة يزحف إليها Claude، يرسل نقرة إحالة واحدة فقط. هذه النسبة تتحسن بالفعل، حيث انخفضت بنسبة 16.9% في الأشهر الأخيرة. لكن النمط الذي تكشف عنه مهم. وكلاء AI يقرؤون الويب للإجابة على الأسئلة. إنهم لا يعيدون المستخدمين إلى موقعك لقراءته بأنفسهم. في الوقت الحالي، النموذج القياسي هو: زحف، استخراج، استجابة. يحصل المستخدم على إجابة. ولا تحصل أنت على شيء.
يقترح WebMCP نموذجًا مختلفًا. فبدلاً من مجرد الزحف إلى ملفات HTML الخاصة بك، يمكن لوكيل AI استدعاء أدوات موقعك مباشرةً. البحث في محتواك. استرداد البيانات المنظمة. التفاعل مع API الخاص بك. ليس مجرد كشط وتلخيص، بل استعلام واستجابة. المواصفة هي مسودة مجموعة مجتمعية من W3C Community Group Draft. يتضمن Chrome 146 Canary تطبيقًا جزئيًا. ومن المرجح أن يكون دعم المتصفحات في بيئة الإنتاج في عام 2027 على أقرب تقدير. لقد قمت بتطبيقه على أي حال. وإليكم القصة كاملة.
منحنى التبني الذي لا يتحدث عنه أحد
قبل أن أصف ما قمت ببنائه، إليكم البيانات التي دفعتني للقيام بذلك. لقد استخرجت بيانات Cloudflare Radar AI Insights للأسبوع من 17 إلى 23 مايو 2026، والتي تغطي 111,076 نطاقًا تم مسحها من بين أفضل 200,000 موقع.
Standard Adoption Rate Approx. Domains
robots.txt 83% ~92,193
AI rules (ai.txt / llms.txt) 79% ~87,750
Sitemap 68% ~75,532
Link headers 9.6% ~10,663
Markdown negotiation 5.3% ~5,887
OAuth discovery 5.2% ~5,776
Content signals ~4.7% ~5,221
Universal Commerce Protocol 4.4% ~4,888
API catalog 0.15% ~167
Agent Skills 0.13% ~144
MCP Server Card 0.11% ~122
WebBotAuth 0.022% ~24
A2A Agent Card 0.0081% ~9
ACP 0.0036% ~4
MPP 0.0018% ~2
x402 Payment 0.0009% ~1
WebMCP 0% 0
AP2 0% 0
اقرأ هذا الجدول مرة أخرى. هناك 17 معيارًا مميزًا يتجه الويب نحوها للبنية التحتية لعصر الذكاء الاصطناعي. الفئة الدنيا، من MCP Server Card حتى نهاية الجدول، تقترب من الصفر حتى بين أكثر المواقع التقنية على الإنترنت. WebMCP لا يكافح للوصول إلى 1%؛ بل لم يبدأ بعد.
برزت لي عدة أمور من هذه البيانات. أولاً: قصة هيمنة Googlebot قد انتهت. انخفضت Google من حوالي 70% من إجمالي نشاط الروبوتات إلى حوالي 40% خلال العام الماضي. تمثل أفضل 5 روبوتات AI الآن 71% من إجمالي حركة مرور HTTP لروبوتات AI: Googlebot بنسبة 26.2%، و Meta-ExternalAgent بنسبة 13.3%، و Bytespider بنسبة 11.4%، و GPTBot بنسبة 10.5%، و ClaudeBot بنسبة 9.3%.
ثانيًا: 8.7% من طلبات روبوتات AI تتلقى أخطاء 403 Forbidden. هذا ليس عرضيًا. هناك من يتخذ قرارًا سياسيًا بحظر زواحف AI. لكن حظر الزواحف لا يمنع وكلاء AI من الإجابة على الأسئلة حول نطاقك إذا كان هذا المحتوى قد تم فهرسته بالفعل. لقد فات الأوان.
ثالثًا، وهذا هو الجزء الذي حفز هذا المشروع بأكمله: الاتجاه طويل المدى لهذه المعايير يتجه نحو التفاعل، وليس مجرد الفهرسة. robots.txt و ai.txt يتعلقان بالإذن. بينما WebMCP و A2A Agent Cards و x402 Payment تتعلق بالقدرة. إنها تصف ما يمكن لوكلاء AI فعله بموقعك، وليس فقط ما يُسمح لهم بالنظر إليه. هذا التحول من الإذن إلى القدرة هو ما أعتقد أنه يمثل العمل المثير للاهتمام في البنية التحتية لعام 2026.
تحديث (أواخر مايو 2026): منذ صياغة هذا المقال، قدمت Google أقوى حجة لذلك. فقد قام Lighthouse 13.3.0 (في 7 مايو 2026) بترقية فئة تدقيق "Agentic Browsing" لتكون افتراضية في Chrome، حيث تقوم بتقييم أي صفحة بناءً على تسجيل أداة WebMCP، وجودة شجرة إمكانية الوصول (accessibility-tree)، ووجود ملف llms.txt. يقوم مالك المنصة ببناء لوحة النتائج قبل أن تبدأ اللعبة، ولا يزال تبني المواقع يقارب 0%. هذه الفجوة بين وجود الأدوات وعدم استخدامها هي محور هذا المقال.
ما قمت بتطبيقه فعليًا: موقعان، مقاربتان
أدير موقعين: chudi.dev (موقعي الشخصي، SvelteKit) و citability.dev (منتج يقيس معدلات استشهاد AI). لقد تعاملت معهما كمختبر لتجربتين في هذا السياق.
التجربة 1: chudi.dev (SvelteKit، مقاربة polyfill)
موقعي الشخصي هو تطبيق SvelteKit. يتميز SvelteKit بالسرعة في التكرار، ومحتواي بسيط، مما أتاح لي التحرك بسرعة. تصف مواصفة WebMCP الحالية واجهة برمجة تطبيقات المتصفح navigator.modelContext. على وجه التحديد، طريقة registerTool() التي تسمح للصفحة بالإعلان عن أدوات قابلة للاستدعاء لوكيل AI يعمل في نفس سياق المتصفح. لا تزال المواصفة تتطور. يتضمن Chrome 146 Canary تطبيقًا جزئيًا، لكنه لا يزال غير متوافق تمامًا مع المواصفة فيما يخص registerTool(). يقوم polyfill @mcp-b/global بسد هذه الفجوة. إنه يطبق اتفاقية provideContext() التي تعمل في Chrome 146+ Canary وتتدهور بصمت في المتصفحات الأخرى (لا يتم طرح أخطاء، ولا يوجد تجربة مستخدم معطلة). إليكم جوهر ملف src/lib/webmcp.ts، والذي يبلغ إجماليه 146 سطرًا:
// src/lib/webmcp.ts
// WebMCP polyfill integration for chudi.dev
// Spec: W3C Community Group Draft (pre-production)
// Polyfill: @mcp-b/global (navigator.modelContext.provideContext convention)
import { browser } from '$app/environment';
interface WebMCPTool {
name: string;
description: string;
inputSchema: Record<string, unknown>;
handler: (args: Record<string, unknown>) => Promise<unknown>;
}
interface PostSearchResult {
slug: string;
title: string;
excerpt: string;
publishedAt: string;
tags: string[];
}
// Only runs in browser context; degrades silently in SSR + non-Canary
export async function initWebMCP(posts: PostSearchResult[]) {
if (!browser) return;
// Feature-detect the polyfill convention, not the spec method
const ctx = (navigator as any).modelContext;
if (!ctx?.provideContext) return;
const tools: WebMCPTool[] = [
{
name: 'searchPosts',
description: 'Search chudi.dev articles by keyword. Returns matching posts with title, excerpt, and URL.',
inputSchema: {
type: 'object',
properties: {
query: {
type: 'string',
description: 'Search term to match against post titles and content'
}
},
required: ['query']
},
handler: async ({ query }: { query: string }) => {
const q = String(query).toLowerCase();
return posts
.filter(p => p.title.toLowerCase().includes(q) || p.excerpt.toLowerCase().includes(q) || p.tags.some(t => t.toLowerCase().includes(q))
)
.map(p => ({ title: p.title, excerpt: p.excerpt, url: `https://chudi.dev/blog/${p.slug}`, publishedAt: p.publishedAt }));
}
},
{
name: 'listPosts',
description: 'List all published posts on chudi.dev, newest first.',
inputSchema: {
type: 'object',
properties: {
limit: {
type: 'number',
description: 'Maximum number of posts to return (default: 10)'
}
}
},
handler: async ({ limit = 10 }: { limit?: number }) => {
return posts.slice(0, limit).map(p => ({ title: p.title, url: `https://chudi.dev/blog/${p.slug}`, publishedAt: p.publishedAt, tags: p.tags }));
}
},
{
name: 'getAuthorContext',
description: 'Get structured context about Chudi Nnorukam: expertise, current projects, contact.',
inputSchema: {
type: 'object',
properties: {}
},
handler: async () => ({
name: 'Chudi Nnorukam',
role: 'AI Harness Engineer',
focus: ['AI-visible web architecture', 'agentic SEO', 'Claude Code harness engineering'],
currentProjects: ['citability.dev', 'chudi.dev', 'Tradeify'],
contact: 'https://chudi.dev/contact',
writing: 'https://chudi.dev/blog'
})
}
];
try {
await ctx.provideContext({
name: 'chudi-dev',
description: 'Content and context for chudi.dev - AI harness engineering and agentic web architecture',
tools
});
} catch (e) {
// Silently swallow; polyfill convention may change before spec lands
console.debug('[webmcp] provideContext failed:', e);
}
}الأدوات هي للقراءة فقط بشكل متعمد. لا توجد عمليات كتابة، ولا مصادقة، ولا حالة جلسة. لا تحدد المواصفة المصادقة في هذه الطبقة، ولم أكن أرغب في تطبيق شيء ينشئ سطحًا أمنيًا لمعيار لا يزال يتطور. أقوم باستدعاء initWebMCP() من دالة load الخاصة بتخطيط SvelteKit، مع تمرير مصفوفة posts:
// src/routes/+layout.ts
import { initWebMCP } from '$lib/webmcp';
import type { LayoutLoad } from './$types';
export const load: LayoutLoad = async ({ fetch }) => {
const res = await fetch('/api/posts');
const posts = await res.json();
// Non-blocking; runs only in browser context
initWebMCP(posts);
return { posts };
};
فصل نظيف. لا يهتم التخطيط بما إذا كان WebMCP قد نجح أم لا. فـ polyfill إما أن يُرفق أو لا.
التجربة 2: citability.dev (Next.js، مقاربة manifest)
موقعي الثاني، citability.dev، احتاج إلى مقاربة مختلفة. إنه منتج يحتوي على API فعلي. إذا وصل WebMCP إلى مرحلة الإنتاج يومًا ما، أريد أن يكون citability.dev قابلاً للاستدعاء فورًا بواسطة وكلاء AI. لهذا، اخترت مسار .well-known/webmcp manifest بدلاً من polyfill. تتوافق مقاربة manifest بشكل أكبر مع كيفية عمل اكتشاف MCP من جانب الخادم مع نضوج المواصفة. يعيش الـ manifest في public/.well-known/webmcp:
{
"name": "citability",
"version": "1.0.0",
"description": "AI citation rate measurement for websites. Run a scan to see how often ChatGPT, Claude, and Perplexity cite your domain.",
"tools": [
{
"name": "run_citability_scan",
"description": "Run a free citation rate scan for a domain. Checks how often ChatGPT, Claude, and Perplexity cite the domain across 20 test queries.",
"inputSchema": {
"type": "object",
"properties": {
"domain": {
"type": "string",
"description": "The domain to scan, e.g. example.com"
}
},
"required": ["domain"]
},
"endpoint": "/api/scan",
"method": "POST",
"pricing": {
"type": "free",
"cost": 0
}
},
{
"name": "request_audit",
"description": "Request a full citation audit with detailed recommendations. Returns a Stripe checkout URL for the selected tier.",
"inputSchema": {
"type": "object",
"properties": {
"domain": {
"type": "string",
"description": "The domain to audit"
},
"tier": {
"type": "string",
"enum": ["starter", "growth", "authority"],
"description": "Audit tier"
}
},
"required": ["domain", "tier"]
},
"endpoint": "/api/audit/request",
"method": "POST"
},
{
"name": "get_audit_result",
"description": "Retrieve a completed audit result by audit ID.",
"inputSchema": {
"type": "object",
"properties": {
"audit_id": {
"type": "string"
}
},
"required": ["audit_id"]
},
"endpoint": "/api/audit/{audit_id}",
"method": "GET"
},
{
"name": "list_audit_tiers",
"description": "List available citability audit tiers with pricing and feature details.",
"inputSchema": {
"type": "object",
"properties": {}
},
"endpoint": "/api/tiers",
"method": "GET"
}
]
}لقد قمت أيضًا بتطبيق A2A AgentCard في .well-known/agent.json:
{
"@context": "https://schema.org",
"@type": "SoftwareApplication",
"name": "citability",
"url": "https://citability.dev",
"description": "Measure and improve your AI citation rate across ChatGPT, Perplexity, and Claude.",
"applicationCategory": "DeveloperApplication",
"featureList": [
"AI citation rate scanning",
"Per-AI-engine breakdown",
"Citation improvement recommendations",
"Audit reports with actionable fixes"
],
"offers": {
"@type": "Offer",
"price": "0",
"priceCurrency": "USD",
"description": "Free scan available"
},
"provider": {
"@type": "Person",
"name": "Chudi Nnorukam",
"url": "https://chudi.dev"
}
}إن A2A AgentCard الخاص بـ citability.dev يضعني ضمن نسبة 0.0081% من النطاقات التي تم مسحها والتي قامت بتطبيقها. إنه ليس ناديًا كبيرًا.
ما تعلمته من تطبيق شيء لم يطبقه أحد غيري
هذا ما كنت أتوقعه: صفر حركة مرور من وكلاء AI، لا شيء مثير للاهتمام في السجلات، تطبيق نظيف ولكنه غير فعال لأشير إليه. إليكم ما حدث بالفعل. لقد قمت بتطبيق أدوات WebMCP الخاصة بموقع chudi.dev في 23 فبراير 2026. خلال الـ 93 يومًا التي تلت ذلك، لم يستدعِ أي وكيل AI خارجي أدوات searchPosts أو listPosts أو getAuthorContext. صفر. لقد قمت بتطبيق manifest الخاص بـ .well-known/webmcp لموقع citability.dev في 22 مايو بأربع أدوات جاهزة للإنتاج، بما في ذلك نقطة نهاية فحص مجانية. خلال الأيام الخمسة التي تلت ذلك، صفر استدعاءات من وكلاء AI لـ run_citability_scan. تظهر سجلات استدعاء وظائف Vercel Edge لكلا الموقعين بالضبط حركة المرور التي تتوقعها: متصفحات بشرية، Googlebot يزحف إلى HTML، ClaudeBot يزحف إلى HTML، GPTBot يزحف إلى HTML. لا أحد يستدعي أدوات WebMCP.
النتيجة الصفرية هي الجزء الأكثر إفادة في هذه التجربة. اتفاقية polyfill (.provideContext()) ليست المواصفة النهائية. يستهدف تطبيق Chrome 146 Canary توقيع طريقة مختلفة عن تلك التي يستخدمها polyfill. وهذا يعني أنه في الوقت الحالي، لا يوجد متصفح في بيئة الإنتاج ينفذ الكود الذي قمت بتطبيقه بالكامل. يتدهور polyfill بصمت. أدواتي معلنة وجاهزة. لا شيء يستدعيها بعد. هذا ليس فشلاً. هذا بالضبط ما يبدو عليه التموضع كـ "متبنٍ مبكر" قبل استقرار المواصفة.
أريد أن أكون محددًا بشأن ما يعنيه "التموضع" هنا، لأنه ليس مجرد لغة تسويقية. عندما تصل مواصفة إلى متصفحات الإنتاج، فإن المواقع التي لديها تطبيقات صحيحة يتم فهرستها بواسطة أي آلية اكتشاف تظهر أولاً. بالنسبة لـ robots.txt في عام 2009، كان المتبنون الأوائل قد وضعوا سياسات الزحف قبل أن تغير روبوتات Google سلوكها. بالنسبة لـ Open Graph في عام 2010، حصلت الصفحات ذات البيانات الوصفية الصحيحة على معاينات أكثر ثراءً قبل أن يُفهم المعيار على نطاق واسع. بالنسبة لـ WebMCP في عام 2027، عندما يتم إطلاقه، ستكون المواقع التي تحتوي على إعلانات أدوات عاملة قابلة للاستدعاء فورًا بواسطة وكلاء AI الذين يطبقون المواصفة.
البديل هو الانتظار والتطبيق لاحقًا. لكن "لاحقًا" في هذا السياق يعني التطبيق في نفس الوقت الذي يطبقه فيه الجميع، عندما تكون ميزة البنية التحتية قد اختفت. هناك أيضًا قيمة ثانية: تتعلم المواصفة بينما لا تزال مرنة. لقد تغيرت مسودة W3C Community Group بطرق لم أتوقعها. تتصرف طريقة registerTool() في المواصفة بشكل مختلف عن اتفاقية polyfill provideContext(). موقع الـ manifest (/.well-known/webmcp) ليس بعد قانونيًا. ولا تزال المصادقة على طبقة WebMCP غير محسومة. من خلال التطبيق المبكر، واجهت بالفعل اثنتين من هذه الفجوات وتكيفت معها.
الجزء الذي فاجأني حقًا: ماذا يعني منحنى التبني اليوم؟
عد إلى جدول البيانات ذاك. انظر أين ينكسر المنحنى. كل ما هو فوق الخط المزدوج (من robots.txt حتى OAuth discovery) قد تجاوز مرحلة التبني الهادف. المواقع تقوم بهذه الأمور بالفعل. حتى المعايير الأقل في تلك المجموعة العليا، مثل Markdown negotiation بنسبة 5.3% و OAuth discovery بنسبة 5.2%، تمثل آلاف النطاقات التي تخبر وكلاء AI بنشاط شيئًا منظمًا حول محتواها أو هويتها. كل ما هو تحت الخط المزدوج هو صفر بشكل أساسي. ليس أرقامًا أحادية منخفضة. بل صفر أو قريب من الصفر. هذا ليس منحنى خطيًا. إنه جرف. وهذا الجرف يتطابق تقريبًا تمامًا مع التمييز بين الإشارات السلبية والقدرات النشطة.
- الإشارات السلبية: robots.txt، ai.txt، sitemaps، link headers، content signals. هذه تخبر الوكلاء بما لديك وما إذا كنت توافق على استخدامهم له.
- القدرات النشطة: WebMCP، A2A Agent Cards، x402 Payment، ACP. هذه تخبر الوكلاء بما يمكنهم فعله ببنيتك التحتية.
الجرف ليس موجودًا لأن المطورين لا يعرفون عن معايير القدرات النشطة. إنه موجود لأن تلك المعايير ليست مستقرة بعد. لا يمكنك تطبيق بروتوكول دفع يكلفك المال إذا تغيرت المواصفة في منتصف الطريق. ولكن إليكم الأمر: المعايير فوق الجرف ليست مستقرة أيضًا. يتم إضافة امتدادات إلى robots.txt باستمرار. و ai.txt/llms.txt لا يزال قيد التعديل. ومع ذلك، قامت المواقع بتطبيقها لأن مساحة الخطأ صغيرة. WebMCP لديه مساحة خطأ أكبر إذا أخطأت. لكن يمكنك القيام بذلك بشكل صحيح لحالة القراءة فقط. ثلاث أدوات تسمح لوكيل AI بالبحث في محتواك واسترداد بيانات منظمة عن هويتك، هذه الأدوات لديها نطاق تأثير قريب من الصفر. إذا تغيرت المواصفة، تقوم بتحديث 146 سطرًا وتعيد النشر. تكلفة أن تكون مبكرًا منخفضة جدًا. تكلفة أن تكون متأخرًا غير واضحة ولكنها محتملة.
كيفية تطبيق WebMCP اليوم (مسار التنفيذ الكامل)
إذا كنت ترغب في تطبيق هذا بنفسك، فإليكم المسار الدقيق الذي اتبعته.
الخطوة 1: تثبيت polyfill (لمشاريع SvelteKit / Vite)
npm install @mcp-b/globalبالنسبة لـ Next.js، مقاربة manifest أنظف من polyfill:
# No npm package needed; just create the manifest file
mkdir -p public/.well-known
touch public/.well-known/webmcpالخطوة 2: تحديد أدواتك كـ "للقراءة فقط" أولاً
قبل أي شيء آخر، حدد البيانات المنظمة التي تريد أن يتمكن وكلاء AI من الاستعلام عنها. ابدأ بما يلي:
- أداة بحث (تأخذ استعلامًا، وتعيد المحتوى المطابق).
- أداة قائمة (تعيد العناصر الحديثة أو ذات الصلة).
- أداة سياق (تعيد بيانات وصفية منظمة حول موقعك أو منتجك).
لا تبدأ بعمليات الكتابة. لا تحدد المواصفة المصادقة في هذه الطبقة. الأدوات التي هي للقراءة فقط ليس لها سطح أمني.
الخطوة 3: تكامل SvelteKit polyfill
أنشئ ملف src/lib/webmcp.ts بناءً على النمط المذكور أعلاه. الفحوصات الرئيسية هي:
if (!browser) return; // Guard SSR
const ctx = (navigator as any).modelContext;
if (!ctx?.provideContext) return; // Guard non-Canaryكلا الحارسين غير قابلين للتفاوض. نسيان حارس browser سيؤدي إلى خطأ ReferenceError: navigator is not defined أثناء SSR. نسيان حارس provideContext سيؤدي إلى خطأ في أي متصفح لم يقم بتطبيق polyfill لـ modelContext.
الخطوة 4: مقاربة Next.js manifest
أنشئ ملف public/.well-known/webmcp (بدون امتداد، ويتم تقديمه كـ application/json) واملأه بتعريفات أدواتك. قدمه بنوع محتوى صحيح:
// app/api/well-known/webmcp/route.ts
import { NextResponse } from 'next/server';
export async function GET() {
const manifest = {
name: 'your-site',
version: '1.0.0',
description: 'What your site does',
tools: [
// your tool definitions
]
};
return NextResponse.json(manifest, {
headers: {
'Access-Control-Allow-Origin': '*',
'Cache-Control': 'public, max-age=86400'
}
});
}ترويسة CORS مهمة. سيقوم وكلاء AI الذين يعملون في سياقات المتصفح بضرب نقطة النهاية هذه من مصدر مختلف عن صفحتك.
الخطوة 5: أضف A2A AgentCard بينما أنت هناك
أنت بالفعل تقوم بإنشاء دليل .well-known. إن A2A AgentCard يتكون من 20 سطرًا من JSON ويضعك ضمن أعلى 0.0081% من النطاقات التي تم مسحها. عدم تطبيقه بينما أنت موجود بالفعل هو ترك ميزة تموضع سهلة على الطاولة.
الخطوة 6: الاختبار في Chrome Canary
قم بتنزيل Chrome 146+ Canary. افتح موقعك. افتح DevTools، علامة تبويب Console. قم بتشغيل:
navigator.modelContext?.provideContext
إذا تم تحميل polyfill، سترى الدالة. إذا أعادت undefined، فهذا يعني أن polyfill لم يتم تحميله (تحقق من كود التهيئة الخاص بك) أو أنك لست على إصدار Canary متوافق. لا يوجد حاليًا وكيل AI إنتاجي سيستدعي هذه الأدوات. أنت تختبر أن البنية التحتية جاهزة، وليس أنها قيد الاستخدام.
الإجابة العملية على سؤال "لماذا أهتم الآن؟"
كل مطور وصفت له هذا المشروع يطرح نفس السؤال: لماذا أطبق شيئًا بنسبة تبنٍ صفرية بينما يمكنني الانتظار وتطبيقه في عام 2027 عندما تدعمه المتصفحات أصلاً وتكون المواصفة مستقرة؟ الإجابة تتكون من ثلاثة أجزاء.
أولاً: تكلفة التنفيذ الآن منخفضة. تطبيق chudi.dev الخاص بي يتكون من 146 سطرًا. و manifest الخاص بـ citability.dev يتكون من 60 سطرًا من JSON ومسار واحد في Next.js. هذا ليس مشروع بنية تحتية متعدد الدورات. إذا تغيرت المواصفة بشكل كبير، أقوم بتحديث 146 سطرًا.
ثانيًا: التعلم يتراكم. المواصفة لا تزال مرنة. القراءة عن WebMCP وتطبيقه هما نشاطان مختلفان. الأسئلة التي لدي بعد التطبيق، لماذا تختلف registerTool() عن provideContext()، كيف يعمل الاكتشاف عبر المصادر المختلفة، ماذا يحدث عندما يكون لأداتين نفس الاسم، هي أسئلة لم أكن لأمتلكها لو أنني قرأت المواصفة فقط. هذه المعرفة تستحق الحصول عليها قبل عام 2027، وليس بعده.
ثالثًا: تشير البيانات إلى وجود "جرف" في منحنى التبني، والجروف لها ديناميكيات "المبادرين الأوائل". عندما تجاوز دعم robots.txt من شبه الصفر إلى تبني هادف، لم يحدث ذلك تدريجيًا. لقد حدث لأن Googlebot بدأ في فرضه، وحصلت المواقع ذات التطبيقات الصحيحة على ميزة. من المرجح أن تتبع أي آلية فرض أو اكتشاف تؤدي إلى تبني WebMCP نفس المنحنى. أن تكون على الجانب الصحيح من هذا الجرف عندما يتحرك أسهل إذا كنت موجودًا بالفعل.
لا شيء من هذا مؤكد. قد تتغير المواصفة بشكل كبير. قد يصل دعم المتصفحات بعد عام 2027. قد يطبق وكلاء AI آلية اكتشاف مختلفة تمامًا. لقد قمت بتطبيق حلول قد تحتاج إلى إعادة عمل كبيرة. وهذا جيد. البديل هو الانتظار، والانتظار يعني البدء متأخرًا عن الأشخاص الذين قاموا بالتطبيق مبكرًا.
إلى أين يتجه هذا الأمر بعد ذلك؟
تظهر بيانات Cloudflare وجود 17 معيارًا تتنافس على اهتمام البنية التحتية للذكاء الاصطناعي على الويب. لقد طبق معظم المطورين الثلاثة أو الأربعة الأوائل: robots.txt، وبعض المتغيرات من ai.txt، و sitemap. الجزء السفلي من المنحنى هو صفر. هذا ليس سقفًا، بل هو نقطة بداية. إذا كان موقعك يحتوي على محتوى قد يكون مفيدًا لوكيل AI في سياق المتصفح، فلديك أداة WebMCP للقراءة فقط لتبنيها. إذا كان منتجك يحتوي على API يجب أن يتمكن وكلاء AI من استدعائه، فلديك manifest لكتابته. لا يتطلب أي من هذين الأمرين انتظار استقرار المواصفة. لدي كلاهما يعملان. لا يتم استدعاء أي منهما بعد. لكن البنية التحتية موجودة عندما يحين الوقت لذلك. إذا كنت ترغب في قياس كيفية تفاعل وكلاء AI مع محتواك اليوم، وليس فقط في عام 2027، فقد بنيت citability.dev لهذا الغرض بالضبط. فحص مجاني، لا يتطلب حسابًا. منحنى التبني يبدأ من مكان ما. في الوقت الحالي، بالنسبة لـ WebMCP، هذا المكان هو أنت.
💡 الخلاصة التقنية
بالنسبة للمطور والمستخدم العربي، يمثل معيار WebMCP فرصة ذهبية للريادة في مشهد الويب المتغير بسرعة. بينما لا يزال التبني العالمي في مراحله الأولية، فإن المبادرة لتطبيق WebMCP الآن تضع المطورين العرب في طليعة الابتكار. في منطقة تشهد نموًا متسارعًا في تبني الذكاء الاصطناعي، يمكن للمواقع التي تدعم WebMCP أن تكتسب ميزة تنافسية كبيرة من خلال جعل محتواها وخدماتها قابلة للاكتشاف والتفاعل المباشر مع وكلاء الذكاء الاصطناعي. هذا لا يعزز فقط ظهور المحتوى العربي في استجابات الذكاء الاصطناعي، بل يفتح أيضًا آفاقًا جديدة لتطوير تطبيقات وخدمات عربية تعمل بتناغم مع البيئة الذكية للويب. الاستثمار المبكر في فهم وتطبيق هذه المعايير سيضمن أن المحتوى والخدمات العربية لا تزال ذات صلة ومتاحة في عصر الذكاء الاصطناعي، مما يعزز حضورنا الرقمي ويساهم في بناء مستقبل ويب أكثر ذكاءً وشمولية.