TON MCP: TONNode مقابل @ton/mcp الرسمي — مقارنة صريحة

@ton/mcp مقابل TONNode: مقارنة صريحة — والسؤال الأول هو من يحتفظ بالمفاتيح؟

هذه المقارنة بين خادمَي MCP لشبكة TON لا تبدأ بقائمة مزايا، بل بسؤال أمني واحد. تخيّل أنك منحت Claude أو Cursor وصولًا إلى TON. الوكيل يقرأ الأرصدة، ويبني معاملات المبادلة، ويستدعي get-methods. كل شيء يعمل — إلى اللحظة التي يلزم فيها توقيع معاملة. وعند الثالثة فجرًا يقرّر الوكيل، بناءً على مطالبة ملتوية (أو تعليمة مدسوسة من صفحة ويب)، أن «يحسّن المحفظة الاستثمارية» فيوقّع المعاملة بنفسه. وتكون الأموال قد غادرت. ولا تعلم بالأمر إلا في الصباح.

ليست هذه قصة تخويف، بل نتيجة مباشرة لخيار معماري واحد: هل يوقّع الوكيل بنفسه بمفتاحه، أم يبقى التوقيع دائمًا من نصيب محفظة المستخدم؟ عند هذه النقطة تحديدًا يفترق خادما MCP الناضجان لشبكة TON — الحزمة الرسمية @ton/mcp من TON Foundation، وTONNode. كلاهما يمنح الوكيل يدًا فاعلة داخل البلوكتشين. ولنستعرضهما بإنصاف، دون انتقاص من أيّ منهما — فلكلا النهجين ما يبرّره في سيناريوهات مختلفة.

لماذا نقارن أصلًا: نهجان مختلفان لـ MCP في TON

MCP (Model Context Protocol) معيار يستدعي عبره وكلاء الذكاء الاصطناعي (Claude وCursor وChatGPT/Codex وأي عميل MCP) الأدوات. وفي حالة TON يعني ذلك أن الوكيل يحصل على مجموعة دوال من نوع get_balance أو build_swap_tx، ويستدعيها بنفسه أثناء الحوار متى رأى ذلك مناسبًا.

الفارق بين @ton/mcp وTONNode ليس في قائمة الأوامر، بل في الفلسفة. والتشبيه بسيط: @ton/mcp أشبه بأن تعطي مساعدك بطاقة الشركة بسقف محدّد — يدفع بنفسه، بسرعة واستقلالية، لكن البطاقة في يده. أما TONNode فهو مساعد يجهّز أمر الدفع ويضعه أمامك لتوقّعه: لا يغادر شيء من دون محفظتك. النموذجان يعملان. والسؤال هو: لأي مهمة؟

وإن كان الجانب النظري أقرب إليك، فهناك تحليل مستقل لـ MCP الاحتجازي في مقابل غير الاحتجازي. أما هنا فنقارن التفاصيل الملموسة.

@ton/mcp الرسمي: محفظة وكيل احتجازية مع NFT وDNS

@ton/mcp هو الحزمة الرسمية من TON Foundation، وهذه نقطة قوّته: دعم من فريق الشبكة، وتطوير يمكن التنبؤ به، ومكانة المرجع المعياري.

ومن حيث البنية، هو محفظة وكيل احتجازية بنموذج split-key:

• مفتاح operator — لدى الوكيل. وبه يوقّع الوكيل المعاملات بنفسه، دون مشاركة منك.
• مفتاح owner — لدى المستخدم، بوصفه حلقة تحكّم ثانية في المحفظة.

وما يقدّمه جاهزًا دون إعداد إضافي:

• قراءة حالة الشبكة والحسابات والأرصدة؛
• إرسال GRAM والجيتونات وNFT (الوكيل يوقّع بنفسه)؛
• المبادلة عبر مجمّع DEX؛
• إنشاء محافظ الوكلاء واستيرادها؛
• قراءة NFT وDNS — وهو ما لا يتوفّر في TONNode حتى الآن، وميزة حقيقية تُحسب للحزمة الرسمية.

يُشغَّل محليًا، أو عبر HTTP، أو بصيغة serverless. والقيد التصميمي واضح: TON فقط، بلا كروس-تشين.

والجوهر هنا هو الاستقلالية. فالوكيل ينفق بنفسه، دون إنسان في حلقة التوقيع. ولسيناريوهات من نوع «دع الوكيل يدفع بنفسه ثمن الاشتراك أو الغاز أو المهام الصغيرة» فهذا بالضبط هو المطلوب. لكن الاستقلالية نفسها تعني أن المفتاح التشغيلي الذي يتصرّف بالأموال موجود في جانب الوكيل — أي أن حقن المطالبات أو هلوسة النموذج قد يؤدّي إلى إنفاق حقيقي.

TONNode: خادم MCP غير احتجازي، مع كروس-تشين وخيار hosted

TONNode خادم MCP مُستضاف لشبكة TON (الموقع tonnode.io) بـ 16 أداة بالضبط. والثابت الأساسي في جملة واحدة:

الخادم لا يوقّع أبدًا ولا يحتفظ بأموال ولا بمفاتيح خاصة. وأدوات المبادلة والكروس-تشين والمحفظة تعيد رسائل TonConnect غير موقّعة. وتوقّعها محفظة المستخدم.

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

القراءة (7+1)

تغطّي الاحتياجات اليومية:

get_masterchain_info — رأس الـ masterchain
get_balance          — رصيد GRAM
get_account_state    — الحالة والرايات وآخر معاملة
get_transactions     — سجل المعاملات
run_get_method       — أي get-method للقراءة فقط في أي عقد
get_jetton_balance   — رصيد الجيتون/USDT (محفظة الجيتون تُحسب على السلسلة)
get_jetton_info      — بيانات الجيتون الوصفية: الاسم والرمز وdecimals والإصدار
parse_address        — تحويل EQ/UQ/raw، دون اتصال بالشبكة

تعيد get_jetton_info قيمة decimals، وهي لازمة لإعادة حساب الوحدات الخام: قيمتها 6 في USDT، و9 في معظم الجيتونات.

المبادلة (2)

تمرّ عبر بروتوكول Omniston — أي السيولة المجمَّعة من STON.fi وDeDust:

• get_swap_quote — عرض سعر مؤكَّد GRAM⇄جيتون؛
• build_swap_tx — معاملة غير موقّعة جاهزة لـ TonConnect.

الكروس-تشين (5)

وهو ما لا وجود له إطلاقًا في الحزمة الرسمية. إسكرو HTLC ذرّي، تكون فيه TON دائمًا هي المصدر:

• get_crosschain_quote — عرض السعر؛
• build_crosschain_swap_tx — معاملة إسكرو HTLC غير موقّعة + السرّ؛
• track_crosschain_swap — مراحل الصفقة على الشبكتين؛
• disclose_crosschain_secret — كشف السرّ لإتمام التسوية، بعد التحقق من الجاهزية على السلسلة؛
• build_crosschain_refund — استرداد الأموال من الإسكرو إذا تعلّقت الصفقة.

الشبكات المدعومة: Ethereum وArbitrum وBase وBNB Chain وPolygon وAvalanche. أما TRON فغير مدعومة حتى الآن. وكيفية سير مثل هذه الصفقة موضّحة في مقالة أول كروس-تشين لوكيل على TON.

المحفظة (1): تنشئ generate_wallet محفظة بإصدارات v3r2/v4/v5r1/highload_v3، وتسلّم العبارة التذكيرية والمفاتيح والعنوان إلى المستخدم — والخادم لا يخزّنها.

أما ما لا يتوفّر في TONNode بعد فهو أدوات NFT وDNS — وهي مدرجة في خارطة الطريق. فإن كانت مهمتك اليوم قراءة مجموعات NFT أو تحويل نطاقات .ton إلى عناوين، فهذه منطقة الحزمة الرسمية. وانتبه أيضًا: لا توجد في TONNode أداة مباشرة لـ «الإرسال/التحويل» لا لـ GRAM ولا للجيتونات. فكل أدوات بناء المعاملات غير الموقّعة هي build_swap_tx وbuild_crosschain_swap_tx وbuild_crosschain_refund، أي أن تحريك الأموال ممكن فقط في إطار مبادلة أو كروس-تشين أو استرداد من الإسكرو. ولا وجود لـ «send» اعتباطي هنا، وذلك بحكم التصميم.

جدول المقارنة: @ton/mcp مقابل TONNode

المعيار	@ton/mcp الرسمي	TONNode
من يوقّع	الوكيل بنفسه (مفتاح operator، split-key)	محفظة المستخدم (الخادم لا يوقّع)
النموذج	احتجازي	غير احتجازي بصرامة
الإنفاق المستقل	نعم	لا (بحكم التصميم)
الإرسال المباشر لـ GRAM/الجيتونات	نعم، باستقلالية	لا توجد أداة مخصّصة؛ التحويل داخل المبادلة/الكروس-تشين فقط، كمعاملة غير موقّعة
المبادلة	مجمّع DEX	Omniston (STON.fi + DeDust)
الكروس-تشين	لا (TON فقط)	نعم، إسكرو HTLC على 6 شبكات
NFT / DNS	متوفّر (قراءة)	ضمن خارطة الطريق
توليد المحفظة	إنشاء/استيراد محافظ الوكلاء	v3r2/v4/v5r1/highload_v3، والمفاتيح لدى المستخدم
التشغيل	محليًا / HTTP / serverless	محليًا (npx) + نقطة hosted
الحالة	رسمي، من TON Foundation	مستقل، مفتوح المصدر (MIT)

المفترق الجوهري: من يحتفظ بمفاتيح الوكيل

وكل ما عدا ذلك تفاصيل. فالاختيار الحقيقي يكمن في سؤال واحد: هل أنت مستعد لأن يوقّع الوكيل المعاملات بنفسه؟

في @ton/mcp يوجد مفتاح operator لدى الوكيل — أي أن الوكيل قادر على إنفاق الأموال استجابةً لمطالبة، دون عامل ثانٍ على هيئة توقيع بشري. وهذا قويّ على صعيد الاستقلالية، وخطير عند حقن المطالبات أو هلوسة النموذج: سياق مخترَق = أموال قد تُنفَق فعلًا.

أما في TONNode فلا يمكن أن يحدث التوقيع على الخادم فيزيائيًا. وحتى لو «جُنّ» الوكيل واستدعى build_swap_tx بمعاملات عبثية، فأقصى ما سيحصل عليه هو كائن معاملة غير موقّع. وما لم تؤكّده محفظة المستخدم، لن يتحرك شيء. هذه ضمانة معمارية، لا سياسة داخلية.

ولا أحد من النهجين «أفضل» على الإطلاق — فهما يعبّران عن مستويين مختلفين من الثقة باستقلالية الوكيل.

متى تختار @ton/mcp الرسمي ومتى تختار TONNode

اختر @ton/mcp إذا:

• كنت تحتاج إنفاقًا مستقلًا — يدفع الوكيل ويوقّع بنفسه، دون إنسان في الحلقة؛
• كنت تعمل داخل TON حصرًا ولا تحتاج الكروس-تشين؛
• كنت تحتاج NFT وDNS اليوم لا غدًا؛
• كانت الصفة الرسمية لحزمة Foundation مهمة بالنسبة إليك.

اختر TONNode إذا:

• كان يجب ألّا يتصرّف بالأموال إلا محفظة المستخدم لا الوكيل — والنمط مشروح في مقالة المبادلة غير الاحتجازية لوكلاء TON؛
• كنت تحتاج كروس-تشين TON⇄EVM (Ethereum وArbitrum وBase وBNB Chain وPolygon وAvalanche)؛
• كنت تحتاج مبادلة عبر سيولة Omniston المجمَّعة؛
• كنت تحتاج نقطة hosted بسعة تمرير مضمونة، لا مجرّد تشغيل محلي.

المسألة ليست «أفضل/أسوأ»، بل أدوات مختلفة. والنهجان غير متنافيين: فكثير من الفرق تُبقي الخادمين معًا في ملف الإعداد — الرسمي لأجل NFT/DNS والمهام المستقلة، وTONNode لأجل المبادلة غير الاحتجازية والكروس-تشين.

كيف تربط كلًّا منهما

وإن كانت هذه زيارتك الأولى، فالمقدّمة العامة لـ MCP في TON موجودة في دليل MCP لشبكة TON.

TONNode محليًا — مجانًا، مع مجموعة القراءة الكاملة

حزمة @tonnode/mcp مفتوحة المصدر (MIT، على npm وGitHub باسم tonnode/mcp)، وتعمل عبر بروتوكول ADNL الأصلي في TON دون طبقات HTTP وسيطة:

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

TONNode hosted — مفتاحك الخاص وسعة تمرير مضمونة

{
  "mcpServers": {
    "ton": {
      "type": "http",
      "url": "https://mcp.tonnode.io/mcp",
      "headers": { "Authorization": "Bearer tn_live_…" }
    }
  }
}

وبعد الربط يمكنك أن تعطي الوكيل مهامّ نصية عادية — وهو يختار الأداة بنفسه:

تحقّق من رصيد USDT في محفظتي EQ… عبر get_jetton_balance.
ثم خذ get_swap_quote لمبادلة 50 USDT إلى GRAM
وجمّع المعاملة عبر build_swap_tx.
لا ترسل المعاملة — أعِدها لي لأوقّعها في المحفظة.

سيستدعي الوكيل get_jetton_balance ثم get_swap_quote ثم build_swap_tx، ويسلّمك رسالة TonConnect غير موقّعة. ولن تتحرك الأموال إلا بعد التأكيد في المحفظة.

ومهمة الكروس-تشين تبدو طبيعية بالقدر نفسه:

جمّع مبادلة 100 GRAM من TON إلى USDC على Base.
أعطني get_crosschain_quote، ثم build_crosschain_swap_tx.
احفظ السرّ، وتابع الحالة عبر track_crosschain_swap.

الأدوات الـ16 كاملةً متاحة في جميع الباقات — فأنت تدفع مقابل سعة التمرير فقط: Hobby مجانية إلى الأبد، بـ 60 طلبًا/دقيقة؛ وPro بـ 29 دولارًا/شهر و300 طلب/دقيقة؛ وScale بـ 199 دولارًا/شهر و1200 طلب/دقيقة. ويُصدر مفتاح Hobby فور تسجيل الدخول، دون بطاقة.

@ton/mcp الرسمي

تُثبَّت @ton/mcp وفق تعليمات TON Foundation، وتُشغَّل محليًا أو عبر HTTP أو بصيغة serverless. وعند الإعداد الأولي تُنشأ للوكيل محفظة وكيل بمفتاح operator أو تُستورد. وضَع النموذج الاحتجازي في حسبانك: فكّر مسبقًا في السقوف، وفي الأموال التي سيصل إليها الوكيل.

الخلاصة

@ton/mcp محفظة وكيل احتجازية رسمية: split-key، وإنفاق مستقل، وNFT وDNS، وTON فقط. أما TONNode فخادم غير احتجازي بـ 16 أداة: لا يوقّع الخادم أبدًا، ويضيف كروس-تشين على 6 شبكات وخيار hosted. الفارق صريح ومعماري — وهو يدور حول من تمنحه حق التوقيع. ومن يوقّع هو من يحدّد ملف المخاطر.

وتجد مقارنة تفصيلية لكل أداة على حدة في صفحة TONNode مقابل MCP الرسمي. ولتجربة النهج غير الاحتجازي الآن، بمفتاح Hobby مجاني ودون بطاقة، من هنا: tonnode.io/dashboard?plan=hobby.