ما الذي يجب تسجيله مع كل استدعاء لأداة MCP

في 8 يونيو 2026 منحت Anthropic أصحاب الموصِّلات في دليل Claude لوحة تحكم. تعرض اللوحة المستخدمين النشطين وإجمالي استدعاءات الأدوات والترتيب في الدليل. وتعرض “مؤشر الصحة ومعدلات الأخطاء وزمن الاستجابة في لمحة واحدة، مع تفصيل الأخطاء لكل أداة لتحديد ما يفشل بدقة”.

قبل ذلك بعام، وصف Alex Volkov من Weights & Biases المشكلة نفسها من الطرف الآخر. فبمجرد أن بدأ وكيله يستدعي الأدوات عبر MCP، “كل تلك القدرة على المراقبة التي اعتدت عليها حين يعمل الكود الخاص بي من البداية إلى النهاية أصبحت معتمة قليلًا”. وأظهر شريكه في المحاضرة، Benjamin Eckel من Dylibso، السبب. فخادم MCP البعيد “يظهر لنا في التتبع كامتداد خدمة واحد” لأنه يعمل خارج سيطرة الجهة التي تستدعيه.

كلتا الرؤيتين تقفان خارج الخادم. يرى العميل امتدادًا واحدًا معتمًا. ويرى الدليل المجاميع. لم يرَ أيٌّ منهما ما طُلب من الخادم، وما رفضه، وما لمسه. الخادم وحده رأى ذلك، لذا فالخادم وحده يستطيع تدوينه.

هذا ما تدوّنه خوادم MCP في Tajo، مقروءًا من الكود الذي يشغّلها وكما هو موضّح في الوثائق. يشرح مقال ما هو خادم MCP البروتوكول. وهذا المقال يشرح السطر.

سطر واحد لكل استدعاء

لوحة التحكم هي نظرة مدير الميناء: سفن تدخل، وسفن تخرج، وأيها تأخر. أما سجل الطلبات فهو دفتر السفينة نفسها، يُكتب على متنها في اللحظة نفسها.

كل tools/call على خادم مساحة العمل في Tajo وعلى كل خادم موصِّل ينتهي بسطر واحد. يُكتب السطر بعد بناء الاستجابة، أيًّا كانت الاستجابة. والاستدعاء المرفوض لأن المفتاح لا يملك صلاحية الكتابة، أو لأن نقطة النهاية للقراءة فقط، يحصل على سطر مثل أي استدعاء آخر. وكذلك الاستدعاء لأداة غير موجودة.

هذا ما يحتويه السطر، وما يرفض أن يحتويه.

الحقل	ما يُحفظ	ما لا يُحفظ
من	معرّف مفتاح API الذي أجرى الاستدعاء. والرمز (token) الناتج عن تسجيل الدخول عبر OAuth مفتاح أيضًا.	سرّ المفتاح أو بادئته.
أين	خادم مساحة العمل أو خادم موصِّل، مع الموصِّل وملف التعريف الخاص به.
الأداة	الاسم، إذا كان لدى الخادم أداة بهذا الاسم.	أي اسم آخر يرسله العميل: يُخزَّن بوصفه (unknown).
التأثير	read أو write أو send أو destructive: أثقل تأثير يمكن أن يحدثه الاستدعاء.
النتيجة	ok، أو رمز خطأ قصير بصيغة snake_case مثل unknown_tool.	نص الخطأ: كل ما ليس رمزًا يُخزَّن بوصفه tool_error.
المدة والحجم	الأجزاء من الألف من الثانية من الوصول حتى الاستجابة، والبايتات التي تلقّاها المستدعي.
معرّف التتبع	معرّف الطلب، من ترويسة x-request-id أو x-trace-id أو W3C traceparent، وإلا فمعرّف جديد.	قيمة ترويسة ليست بصيغة ست عشرية ولا UUID.
السجلات	ما يصل إلى 20 معرّفًا لسجلات سمّاها الاستدعاء أو أنتجها: جهة اتصال، أو رسالة، أو موافقة.	السجلات نفسها.
المحتوى	الوسائط والإجابة، بعد تنقيتها، بحد أقصى 4 KB لكل منهما.	الأسرار، والنص الحر، والبيانات الشخصية المذكورة أدناه.

ثلاثة من حالات الرفض هذه تتعلق بالعميل لا بالبيانات. اسم الأداة ورمز الخطأ ومعرّف التتبع كلها تأتي من الخارج. ولا يُحفظ أيٌّ منها إلا بشكل يستطيع الخادم أن يضمنه. السجل الذي يخزّن كل ما أرسله المستدعي يمكن أن يُملأ بأي شيء، بما في ذلك عنوان البريد الإلكتروني لأحد العملاء في عمود اسم الأداة.

كان السؤال المفتوح الذي طرحه Benjamin Eckel في نهاية المحاضرة هو كيف يعرف المُجمِّع “أنه استدعاء لأداة MCP فيه خطأ”. على خادم واحد، الجواب عمود. قيمة ok هي false، والرمز يقول أي خطأ حدث.

الوسائط: قاعدة تراجعنا عنها

الاعتراض وجيه، وهو اعتراضنا نحن. سجّل الوسائط وستكون قد بنيت نسخة ثانية من بيانات عملائك، خارج نطاق كل طلب حذف. حتى 18 أكتوبر 2026 كانت هذه قاعدتنا نحن. لم يكن السجل يحتفظ بالوسائط ولا بمحتوى النتيجة، لأن كليهما قد يحمل بيانات شخصية.

كانت تلك مقايضة خاطئة. سجل الطلبات الذي لا يستطيع أن يُظهر ما أُرسل وما عاد لا يستطيع الإجابة عن السؤال الوحيد الذي وُجد من أجله: لماذا فشل استدعاء الوكيل الخاص بي؟

لذلك يُحتفظ بالمحتوى، ويُعالَج سبب عدم الاحتفاظ به بطريقة أخرى. يمر كل محتوى عبر مرور حتمي واحد قبل وضعه في قائمة الانتظار.

• لا يبقى أي سر. الحقل الذي يدل اسمه على token أو password أو secret أو signature أو cookie أو session أو نحو عشرين كلمة مشابهة لا يحتفظ إلا بـ [secret]. وكذلك القيمة التي تأخذ شكل بيانات اعتماد معروفًا، أينما ظهرت. يشمل ذلك رموز bearer، ورموز JWT، والمفاتيح الخاصة، وعناوين URL التي تحتوي على كلمة مرور، وأي تسلسل معتم من 40 حرفًا من أحرف المفاتيح أو أكثر.
• لا يُحتفظ بالنص النثري إطلاقًا. الحقل المسمّى html أو text أو body أو markdown أو content لا يحتفظ إلا بـ [redacted]. فالنص النثري يحمل أسماء وعناوين سكن لا يكتشفها أي نمط.
• تُخفى البيانات الشخصية نهائيًا. الحقل الذي يدل اسمه على بيانات شخصية، مثل البريد الإلكتروني أو الهاتف أو الاسم أو العنوان أو الملاحظة، لا يحتفظ إلا بـ [redacted]. ويُخفى عنوان البريد الإلكتروني أو رقم الهاتف أو البطاقة أو رقم IBAN داخل أي سلسلة نصية أخرى.
• يبقى المحتوى صغيرًا. تُقصّ السلاسل النصية عند 512 حرفًا، والقوائم عند 20 عنصرًا، والكائنات عند 50 مفتاحًا، والتداخل عند 6 مستويات. ويُقصّ المحتوى كله عند 4 KB ويُعلَّم بأنه مقطوع.

نوعان من الاستدعاءات يحتفظان بأقل من ذلك. جهات الاتصال التي جلبتها محادثة شخص ما من تطبيق آخر تُسجَّل كعلامة وعدد، ولا تُسجَّل كمحتوى أبدًا. والاستدعاء الذي يقرأ السجل لا يحتفظ بإجابة، لأن الإجابة لن تكون سوى أسطر أخرى من السجل.

والآن التكلفة. الإخفاء دائم، وليس تشفيرًا بمفتاح يحتفظ به أحد. لا يستطيع السجل أن يُظهر لك عنوان البريد الإلكتروني الذي ارتدّت إليه الرسالة. إنه يُظهر لك معرّف جهة الاتصال، وجهة الاتصال، وفق قواعدها الخاصة، على بُعد استدعاء واحد. يقع السجل خارج عملية المحو الشاملة لمساحة العمل، ولهذا لا يمكن للإخفاء أن ينتظرها.

لماذا ليس السجل هو مسار التدقيق

لدى Tajo بالفعل سجل تدقيق لا يقبل إلا الإضافة. يحمل كل سطر فيه تجزئة (hash) للسطر الذي قبله، لذا فإن أي تعديل في أي مكان يكسر السلسلة. فلماذا لا تُكتب استدعاءات الأدوات هناك؟

لأن للسلسلة ثمنًا. كل إضافة تأخذ قفلًا على مستوى مساحة العمل وتقرأ السطر السابق لتمديد السلسلة. ولو مرّت كل عملية قراءة عبرها لاصطفت استدعاءات مساحة العمل خلف قفل واحد. كما أنها ستدفن تغييرات الحالة، التي وُجد سجل التدقيق لإظهارها، تحت آلاف القراءات.

لذلك ينقسم السجلان حسب السؤال. يقول سجل الطلبات ما الذي طلبه الوكيل وما الذي حدث، لمدة 30 يومًا. ويقول سجل التدقيق ما الذي تغيّر، ومن سمح به، وهل عدّل أحد السجل منذ ذلك الحين.

تقع الموافقات في جانب التدقيق. في ملفات تعريف الموصِّلات في Tajo، تجهّز أداة propose إجراءً مُعلنًا وتنفّذه أداة apply بعد الموافقة عليه. لا يصل شيء إلى المزوّد حتى تتم الموافقة على الاقتراح، من قِبل شخص أو بقاعدة فعّلتها مساحة العمل. يذكر سطر استدعاء propose الموافقة التي أنشأها ضمن سجلاته. والموافقة نفسها مرتبطة ببصمة SHA-256 للمدخلات بدقة. تغطي الموافقة المدخلات نفسها التي رأيتها بالضبط: غيّر حقلًا واحدًا ولن تعود مطابقة. وعندما تُنفَّذ الكتابة، يحتفظ سطر التدقيق الخاص بها ببصمة المدخلات وببصمة استجابة المزوّد، ولا يحتفظ أبدًا بقيم الاستجابة.

ما تكلفة السطر

السطر عملية كتابة في قاعدة البيانات، ولكل كتابة عملية تثبيت (commit). حتى 8 أكتوبر 2026 كان كل استدعاء ينتظر عملية التثبيت الخاصة به قبل الاستجابة، نحو 2.6 ms على خادمنا. وبالنسبة إلى عميل واحد، كان ذلك ربع استدعاء أداة صغير.

الآن يُبنى السطر عند انتهاء الاستدعاء ويوضع في قائمة الانتظار. تكتب عملية تفريغ قائمة الانتظار بعد 100 ms على الأكثر، بمعاملة واحدة لكل مساحة عمل، فتتشارك استدعاءات كثيرة عملية تثبيت واحدة. لا يتغيّر شيء في السطر، بما في ذلك طابعه الزمني. وإذا كانت 5,000 سطر في الانتظار، ينتظر الاستدعاء التالي عملية التفريغ بدلًا من إسقاط سطر.

التسجيل لا يُفشل أي استدعاء أبدًا. الكتابة التي تفشل تُعاد محاولتها سطرًا سطرًا، ثم تُسجَّل وتُسقَط. وما يخسره الإيقاف القسري للعملية هو ما كان في قائمة الانتظار: على الأكثر آخر 100 ms من الاستدعاءات.

قراءة السجل

تُعيد logs.list استدعاءات مساحة العمل، الأحدث أولًا، دون المحتوى. وتُرشِّح حسب الوقت، وحسب النتيجة أو حالة HTTP، وحسب المصدر (MCP أو REST API الذي يتشارك الجدول نفسه)، وحسب مفتاح API. وتعرض 50 سطرًا في الصفحة افتراضيًا، حتى 100. وتُعيد logs.get استدعاءً واحدًا مع الاسم الحالي للمفتاح، وحالته، ومدته، والطلب والاستجابة بعد تنقيتهما، والسجلات التي لمسها.

كلتاهما لا تقرأ إلا مساحة عمل المستدعي. ومعرّف سطر من مساحة عمل أخرى لا يُعثر عليه.

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

ما بُني وما لم يُبنَ

ما بُني حتى وقت كتابة هذا المقال:

• سطر واحد لكل tools/call على خادم مساحة العمل وعلى كل خادم موصِّل، بما في ذلك الاستدعاءات المرفوضة وغير المعروفة.
• معرّف المفتاح، والخادم، والموصِّل، وملف التعريف، والأداة، والتأثير، والنتيجة، والمدة، وحجم النتيجة، ومعرّف التتبع، وما يصل إلى 20 سجلًا لمسها الاستدعاء.
• الوسائط والإجابات بعد تنقيتها، بحد أقصى 4 KB لكل منها.
• logs.list وlogs.get، ضمن نطاق مساحة العمل، مع الاحتفاظ لمدة 30 يومًا.
• موافقات مرتبطة ببصمة المدخلات، وعمليات كتابة مُنفَّذة مسجّلة ببصمات المدخلات والمخرجات في سجل التدقيق المتسلسل بالتجزئة.

ما لم يُبنَ، ومن المفيد معرفته قبل الاعتماد عليه:

• لا مؤشر صحة، ولا رسم بياني لكل أداة، ولا تنبيه عند ارتفاع معدل الأخطاء. يوجد ملخص لكل أداة بالاستدعاءات والأخطاء وأبطأ المدد لمشغّلي Tajo، وليس على أي واجهة يمكنك فتحها.
• لا تستطيع logs.list الترشيح حسب اسم الأداة أو معرّف التتبع. للعثور على السطر الذي يقف خلف معرّف طلب، ضيّق البحث حسب الوقت والمفتاح.
• لا تُصدَّر الأسطر إلى نظام تتبع تديره أنت. يُقرأ معرّف التتبع من ترويسات HTTP فقط، لا من حقل _meta في MCP الذي استخدمته المحاضرة لنقل سياق التتبع.
• بعد 30 يومًا يُحذف السطر. لا يوجد أرشيف ولا تصدير.
• ما أُخفي لا يمكن استعادته من السجل.
• قد يُفقد الإيقاف القسري آخر 100 ms من الأسطر.

اختُتمت المحاضرة بأن قابلية المراقبة في MCP “ليست موزّعة بالتساوي”. لا تستطيع لوحة تحكم في مرحلة لاحقة إصلاح ذلك، ولا يستطيعه تتبع يتوقف عند باب الخادم. المزامنة التي تفشل تحتاج إلى سجل خاص بها، وكذلك كل استدعاء طلب شيئًا.

رأى الخادم الاستدعاء. لم يره أحد غيره. دوّنه هناك.