قواعد أذونات Claude Code MCP: تم اختبار الإصدار 2.1.299

في اختباراتي باستخدام claude -p على إصدارات Claude Code 2.1.299 و 2.1.307، غطت قاعدة السماح mcp__a خادم MCP المسمى a فقط. أما في الإصدار 2.1.296، فقد سمحت أيضاً بتشغيل أدوات خادم مسمى a__b. ومع ذلك، ظلت قاعدة المنع لـ mcp__a تحظر كلا الخادمين.

لقد اختبرت ذلك باستخدام خادمي stdio وثلاثة إصدارات (builds). إليكم ما تم تشغيله، وما لم يتم، والقاعدة التي يجب كتابتها بدلاً من ذلك.

ما ستتعلمه

• ما الذي تغير بالنسبة لقواعد MCP في الإصدار 2.1.299، وماذا تقول المستندات عن الأسماء التي تحتوي على __
• كيف اختبرت قواعد السماح والمنع باستخدام خادمين متشابهين
• أي أشكال القواعد تصرفت بشكل مختلف في الإصدارات 2.1.296 و 2.1.299 و 2.1.307
• ما هي القواعد التي يجب كتابتها لخادم يحتوي اسمه على __
• ما الذي لم أقم باختباره

ما الذي تغير في الإصدار 2.1.299

يسرد سجل تغييرات Claude Code ثلاثة بنود حول كيفية مطابقة قواعد MCP لأسماء الخوادم في الإصدار 2.1.299، بتاريخ ١٤ أكتوبر ٢٠٢٦.^١

يقول البند الأول أن قواعد السماح الآن "تصل فقط إلى الخادم الذي تسميه". ومثاله هو أن mcp__a لم تعد تسمح بخادم يسمى a__b أو a_. نصيحة Anthropic هي كتابة mcp__<server>__* باستخدام الاسم الموحد بالكامل.

البند الثاني يفعل الشيء نفسه لقوائم أدوات الوكيل tools:. أما الثالث فهو إصلاح: حيث كانت قواعد المنع والسؤال لـ mcp__<server> لا تُطبق عندما يحتوي اسم الخادم الموحد على شرطة سفلية مزدوجة.

الغموض يكمن في الأسماء. تُسمى أداة MCP بـ mcp__<server>__<tool>، لذا فإن mcp__reports__v2__summary قد تكون الأداة v2__summary على الخادم reports، أو الأداة summary على الخادم reports__v2. تقول وثائق الأذونات إن كلاً من mcp__reports__v2 المجردة و mcp__reports الأقصر يتم قراءتهما كقواعد لخادم يسمى reports. كقواعد سماح، لا تطابق أي منهما أدوات reports__v2. أما كقواعد منع أو سؤال، فكلاهما يغطي أيضاً reports__v2.^٢

تتفق المستندات وسجل التغييرات، ولكن من السهل قراءة قاعدة اسم الخادم المجردة بشكل خاطئ، لذا قمت بتجربة الأشكال الشائعة على خوادم حقيقية.

كيف اختبرت ذلك

لقد قمت بتثبيت ثلاث نسخ من npm، كل واحدة في مجلد خاص بها: 2.1.296، و2.1.299، و2.1.307. تم نشر النسخة 2.1.296 في ٩ أكتوبر ٢٠٢٦، تلتها النسخة 2.1.299 في ١٤ أكتوبر، ثم 2.1.307 في ٢١ أكتوبر. كانت النسخة 2.1.307 هي الأحدث عندما قمت بتشغيل الـ ٢١٦ عملية تشغيل رئيسية. أما النسخة 2.1.308 فقد نُشرت في ٢٢ أكتوبر الساعة ٠٤:١٩ بالتوقيت العالمي المنسق (UTC)، بعد تلك العمليات، ولم أقم باختبارها. وفي فحص لاحق لـ ١٥ عملية تشغيل، موصوفة أدناه، استخدمت نفس النسخ الثلاث المثبتة. لا يوجد في npm نسخ برقم 2.1.297 أو 2.1.298.^٣

الخادمان هما نفس الملف ولكن تم تشغيلهما بأسماء مختلفة. الخادم a لديه أداة واحدة، وهي ping، لذا فإن اسمه الكامل هو mcp__a__ping. والخادم a__b لديه أيضاً أداة ping، مما يعطي الاسم mcp__a__b__ping. كلا الاسمين يبدآن بـ mcp__a__، وهذا هو الهدف. تقوم كل أداة بإضافة سطر إلى ملف سجل (log) عند تشغيلها، لذا يوضح السجل ما تم تنفيذه بغض النظر عما قاله النموذج.

يستخدم الخادم MCP TypeScript SDK إصدار 1.32.1 و zod 4.6.7، وهي تبعية المخطط (schema dependency) الخاصة بـ SDK.^٤

// server.mjs
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { appendFileSync } from "node:fs";

const [name, toolName] = process.argv.slice(2);
const s = new McpServer({ name, version: "1.0.0" });

s.registerTool(
  toolName,
  { description: `Ping tool of server ${name}. Returns a fixed string.`, inputSchema: {} },
  async () => {
    appendFileSync(process.env.PING_LOG, `${process.env.RUN_ID}\tserver=${name}\ttool=${toolName}\n`);
    return { content: [{ type: "text", text: `pong from ${name}` }] };
  }
);

await s.connect(new StdioServerTransport());

{
  "mcpServers": {
    "a": { "command": "node", "args": ["server.mjs", "a", "ping"] },
    "a__b": { "command": "node", "args": ["server.mjs", "a__b", "ping"] }
  }
}

كانت كل عملية تشغيل عبارة عن استدعاء حقيقي لـ claude -p. كان النموذج هو الاسم المستعار haiku، والذي ظهر في مخرجات JSON كـ claude-haiku-5-5. لقد مررت --strict-mcp-config بحيث تأتي خوادم الاختبار الخاصة بي فقط من إعدادات MCP الخاصة بي، و --setting-sources "" لتخطي ملفات إعدادات المستخدم والمشروع والإعدادات المحلية، ومجموعة قواعد واحدة لكل عملية تشغيل. طلب الأمر (prompt) كلا الأداتين بالترتيب، حتى لو تم رفض الأولى.

npm i @modelcontextprotocol/sdk@1.32.1 zod@4
npm i @anthropic-ai/claude-code@2.1.299   # one folder per build

PING_LOG=$PWD/ping.log RUN_ID=t1 npx claude -p \
  "Call the MCP tool mcp__a__ping and then the MCP tool mcp__a__b__ping, one after the other, even if the first one is refused. Then reply with exactly two lines: 'mcp__a__ping: ran' or 'mcp__a__ping: refused', and the same for mcp__a__b__ping." \
  --mcp-config mcp.json --strict-mcp-config --setting-sources "" \
  --model haiku --output-format json --allowedTools "mcp__a" < /dev/null

cat ping.log

بالنسبة للحالات الأخرى، قمت بتغيير أعلام القواعد فقط: --allowedTools و --disallowedTools مع قواعد مفصولة بفاصلة، أو --settings التي تشير إلى ملف JSON صغير في حالة ملف الإعدادات. استخدم اختبار تعارض الأسماء ملف إعدادات ثانٍ وأمر يطلب أداة واحدة.

قمت بتشغيل ٢٤ تكويناً للقواعد، ثلاث عمليات تشغيل لكل نسخة، بإجمالي ٢١٦ عملية تشغيل. يذكر هذا المنشور ١٢ منها. أما الـ ١٢ الأخرى فكانت سبعة متغيرات رفض مبكر، وثلاثة عناصر تحكم إضافية للسماح وملف الإعدادات، ومتغيرين آخرين لتعارض الأسماء. سمحت متغيرات الرفض المبكر بـ mcp__a و mcp__a__b (استخدم أحدها mcp__a__*). لا يغطي أي من هذه الحالات a__b في النسختين 2.1.299 و 2.1.307، لذا فإن الرفض هناك قد يكون ناتجاً عن فقدان السماح بدلاً من قاعدة الرفض. لقد أعدت تنفيذ خمس منها مع مجموعة سماح تتكون من mcp__a__b__* و mcp__a__ping، وأذكر فقط نتائج إعادة التنفيذ. كان هناك تكوين واحد يتضمن تسعة استدعاءات فشلت بسبب مسافة زائدة في قائمة الحالات الخاصة بي، وقد استبدلتها بإعادة التشغيل.

كل حالة ذكرتها أعطت نفس النتيجة ثلاث مرات من أصل ثلاث، باستثناء اختبار تعارض الأسماء في النهاية. جميع عمليات التشغيل تمت في ٢٢ أكتوبر ٢٠٢٦، على نظام Linux x86_64. عملت خوادم الاختبار على Node.js 22.22.0.

في وضع -p، يتم رفض الاستدعاء الذي لا تمنحه أي قاعدة ويُدرج تحت permission_denials في ملف JSON. أما الأداة التي يتم حظرها بواسطة قاعدة رفض فهي مختلفة: لم تظهر أبداً في permission_denials في عمليات التشغيل الخاصة بي. وفي فحص منفصل مكون من ١٥ عملية تشغيل، قمت بتشغيل حالات الرفض الخمس الموضحة في الشكل (عنصر التحكم، mcp__a__b، mcp__a، mcp__a__b__* و mcp__a__ping) مرة واحدة لكل نسخة مع --output-format stream-json --verbose. في كل واحدة من تلك العمليات، استبعدت رسالة init التي تسرد أدوات الجلسة كل أداة حظرتها قاعدة الرفض، وأدرجتها عندما لم تكن قاعدة الرفض سارية. لذا، في هذه العمليات، قامت قاعدة الرفض بإزالة الأداة من قائمة أدوات الجلسة بدلاً من رفض الاستدعاء. تسمية "refused" (مرفوض) الخاصة بالنموذج لا توضح أي من الأمرين حدث، هل هو رفض إذن أم أداة مفقودة. في ٨ من أصل ١١ عملية تشغيل في ذلك الفحص حيث كانت الأداة مفقودة من القائمة، حاول النموذج مع ذلك استدعاءها وحصل على خطأ "No such tool available" (لا توجد أداة متاحة). يوضح ملف السجل ما تم تشغيله، وتوضح قائمة init ما قدمته الجلسة. كما أدرجت الجلسات في ذلك الفحص خادماً باسم claude-in-chrome من بيئتي، ولا تتطابق أي من القواعد هنا مع أدواته.

قواعد السماح (Allow rules)

يوضح الشكل أدناه الحالات الرئيسية. كل خلية تمثل أداة الخادم التي تم تشغيلها، والخلايا العريضة (bold) تختلف بين الإصدارات.

مع استخدام mcp__a كقاعدة سماح، قام الإصدار 2.1.296 بتشغيل كلتا الأداتين. أما الإصداران 2.1.299 و 2.1.307 فقد قاما بتشغيل أداة الخادم a فقط ورفضا الأداة الأخرى. وسلكت قاعدة الرمز العام (wildcard) نفس السلوك: حيث تطابقت mcp__a__* مع a__b في الإصدار 2.1.296 ولم تتطابق في 2.1.299 أو 2.1.307. ووضع mcp__a تحت permissions.allow في ملف إعدادات يتم تمريره باستخدام --settings أعطى نفس النتيجة، لذا فإن علامة CLI والملف متفقان.

القاعدة mcp__a__b كانت هي المفاجأة. كنت أتوقع أن تسمح للخادم a__b. ولكن في جميع الإصدارات الثلاثة، لم تسمح بأي من الأداتين. وهذا يتطابق مع الوثائق، التي تقول إن mcp__reports__v2 المجردة تُقرأ كقاعدة لخادم يسمى reports. وهنا يعني ذلك الخادم a، الذي لا يملك أداة تسمى b.

هناك شكلان عملا في كل إصدار للخادم الذي يحتوي على شرطة سفلية مزدوجة: سمحت mcp__a__b__* بـ a__b ورفضت a، وقام الاسم الدقيق mcp__a__b__ping بنفس الشيء. يوصي سجل التغييرات (changelog) بصيغة الرمز العام، وتذكر الوثائق كليهما.

بالنسبة لسكربت يعمل بدون تدخل بشري، فإن لهذا ميزة عملية. إذا كانت قاعدة السماح لديك هي mcp__a وكنت تشغل أيضاً خادماً يسمى a__b، فإن هذه القاعدة غطت أدوات a__b في الإصدار 2.1.296. أما في 2.1.299 و 2.1.307، يتم رفض نفس الاستدعاء في وضع -p. كل عملية تشغيل كانت تحتوي على تكوين كلا الخادمين، لذا لم أختبر تكويناً يحتوي على a__b فقط. كما لم أختبر جلسة تفاعلية، حيث أتوقع ظهور طلب إذن بدلاً من ذلك.

قواعد المنع (Deny rules)

بالنسبة لحالات المنع التي أذكرها، فقد سمحت بكلتا الأداتين صراحة (mcp__a__b__* و mcp__a__ping)، لذا فإن أي حظر يأتي من قاعدة المنع. أما الاختبار الضابط، وهو المنع على خادم غير موجود، فقد ترك كلتا الأداتين تعملان في جميع الإصدارات.

المنع على mcp__a__b هو المكان الذي يظهر فيه الإصلاح. في الإصدار 2.1.296 لم يفعل شيئاً: عمل كلا الخادمين، بما في ذلك a__b، وهو الخادم الذي كان من المفترض أن توقفه القاعدة. أما في 2.1.299 و 2.1.307 فقد حظر a__b وترك أداة الخادم a تعمل. وهذا يتطابق مع بند سجل التغييرات المتعلق بقواعد المنع والطلب.^١

المنع على mcp__a حظر كلا الخادمين في جميع الإصدارات الثلاثة، على الرغم من السماح بـ mcp__a__b__*. تصف الوثائق هذا الأمر: كقاعدة منع، تغطي الصيغة القصيرة أيضاً الأسماء المشابهة.^٢ هذا هو الاتجاه الآمن، ولكنه يعني أن المنع المكتوب كـ mcp__a لا يمكنه ترك a__b وشأنه. لم أختبر منعاً مكتوباً بصيغة mcp__a__*.

المنع على mcp__a__b__* حظر a__b فقط. والمنع على الأداة الدقيقة mcp__a__ping حظر فقط أداة الخادم a وترك a__b تعمل. تقترح الوثائق نفس المسار: قاعدة واحدة لكل أداة عندما تحتاج إلى تغطية a دون المساس باسم مشابه.^٢ الخادم a لديه أداة واحدة فقط، لذا كانت قاعدة واحدة كافية. لم أختبر خادماً يحتوي على عدة أدوات.

أي قاعدة يجب كتابتها

بالنسبة للخوادم التي قمت بتكوينها بنفسك، فإن الاسم في القاعدة هو الاسم الموحد الذي يظهر في أسماء الأدوات، مع تحويل أحرف مثل . والمسافات إلى _.^٢ إذا كان الاسم الموحد يحتوي على __ أو ينتهي بـ _، تنص الوثائق على استخدام صيغة الرمز العام (wildcard) مع الاسم بالكامل.

عندما ينتج خادمان نفس اسم الأداة

لقد جربت أيضاً إعداداً أكثر تعقيداً: خادم a يقدم أداة تسمى b__ping وخادم a__b يقدم ping. كلاهما يتم تحويلهما إلى mcp__a__b__ping. طلبت تلك الأداة الواحدة، مع قاعدة سماح لهذا الاسم بالضبط، وتغير الخادم الذي أجاب بين عمليات التشغيل في كل إصدار. في كل إصدار، أجاب a__b مرتين وأجاب a مرة واحدة في ثلاث عمليات تشغيل. لا يمكنني معرفة السبب، ولا أدعي أي خادم هو الذي يفوز. النصيحة العملية بسيطة: لا تقم بتشغيل خوادم تؤدي أسماؤها وأدواتها إلى نفس السلسلة النصية عند التوحيد.

ما لم أختبره

• الجلسات التفاعلية، حيث أتوقع أن تطلب الأداة غير الممنوحة إذناً بدلاً من أن تفشل.
• الوضع التلقائي (Auto mode) والمصنف الخاص به. يذكر نفس قسم سجل التغييرات في إصدار 2.1.299 أيضاً إصلاحاً للأدوات الخاصة بخادم MCP يسمى constructor أو toString تطلب إذناً في الوضع التلقائي ووضع تجاوز الأذونات.^١ لم أختبر ذلك.
• قواعد الطلب (Ask rules). يغطيها سجل التغييرات، لكني قمت بتشغيل قواعد السماح والمنع فقط.
• تغيير قائمة tools: الخاصة بالعميل من نفس إدخال سجل التغييرات.
• الخوادم المقدمة من الإضافات (plugins)، والقواعد من الإعدادات المدارة، والخوادم التي تنتهي بشرطة سفلية مثل a_، والتي ذكرها سجل التغييرات أيضاً.
• النماذج الأخرى. لا أتوقع أن يعتمد مطابقة الأذونات على النموذج، ولكن كل عملية تشغيل استخدمت haiku.
• إصدارات أخرى غير 2.1.296 و 2.1.299 و 2.1.307. يشمل ذلك من 2.1.300 إلى 2.1.306 و 2.1.308. لا يوجد في npm إصدار 2.1.297 أو 2.1.298.

بحثت أيضاً في أقسام سجل التغييرات من 2.1.300 إلى 2.1.307 عن مصطلحات mcp__، وقاعدة السماح (allow rule)، وقاعدة المنع (deny rule)، وقاعدة الإذن (permission rule)، وقرأت كل نقطة تتعلق بـ MCP فيها. لم أجد أي تغيير آخر في كيفية مطابقة قواعد أذونات MCP.^٥ مراجعة سريعة، لم أقم بتشغيلها كاختبار: قم بإدراج خوادمك باستخدام claude mcp list، وطبق توحيد الأسماء المذكور في الوثائق على كل اسم (الأحرف مثل . والمسافات تصبح _)، وأعد كتابة القواعد لأي اسم يحتوي بعد ذلك على __ أو ينتهي بـ _ إلى صيغة الرمز العام.

قراءات ذات صلة

• إخفاقات Claude Code Hook: اختبار حظر onFailure
• خطافات Claude Code updatedInput: اختبار تغيير 2.1.300

الخلاصة

في تشغيلات claude -p الخاصة بي على الإصدارين 2.1.299 و 2.1.307، وصلت قاعدة السماح mcp__a فقط إلى الخادم المسمى a. هذا يقلل من نطاق مطابقة القاعدة، ويؤدي إلى تعطل أي قاعدة سماح -p كانت تعتمد على أن mcp__a تغطي أيضاً a__b. تقول الوثائق إن قاعدة مثل mcp__a__b تُقرأ كخادم a، لذا استخدم mcp__a__b__* من أجل a__b.

راجع كل اسم خادم في إعداداتك. إذا كان الاسم الموحد يحتوي على __ أو ينتهي بـ _، اكتب mcp__<name>__* في قواعد السماح. استخدم قواعد مخصصة لكل أداة لمنع الخادم ذو الاسم الأقصر دون المساس بالخادم المشابه له، وقم بإجراء استدعاء واحد لكل خادم للتأكيد.

المراجع