وكيل تداول TON عبر MCP: اقرأ، سعّر، وبادِل بلا وصاية

المشكلة التي يبدأ منها كل وكيل تداول على TON

تطلب من وكيل ذكاء اصطناعي أن «يبادل 50 USDT بـ GRAM عندما يهبط السعر» — فيرسل معاملة بقيمة 50,000 USDT بدلًا من 50. والسبب أن USDT على TON لها decimals = 6 (أي أن 50 USDT = 50,000,000 وحدة خام)، بينما حسبها الوكيل افتراضيًا كأي جيتون عادي بتسعة أصفار، فضخّم المبلغ ألف مرة. خطأ بمقدار 1000 ضعف، بأموال حقيقية، في معاملة لا رجعة فيها. والخطأ المعاكس له الجذر ذاته: يرى الوكيل في الرصيد القيمة الخام 1000000000 فيبلّغك بثقة «لديك مليار USDT»، بينما الرقم الحقيقي هو 1000.

هذه ليست قصص رعب مؤلَّفة، بل هي بالضبط الألغام التي يدوسها كل من يربط نموذجًا لغويًا بـ DeFi على TON مباشرةً عبر RPC خام: خلط في decimals، واستحالة قراءة رصيد جيتون بدون عنوان محفظة الجيتون، ومفتاح خاص يتسرّب عبر السياق. فيما يلي كيف تبني وكيل تداول على TON (trading agent TON) يقرأ الأرصدة، ويأخذ عرض سعر ثابتًا، ويجمّع المبادلة، دون أن يلمس مفاتيحك ولو مرة واحدة. الأداة هي TONNode، خادم MCP مُستضاف لشبكة TON.

ما هو وكيل التداول على TON ولماذا يحتاج إلى MCP

وكيل التداول هو نموذج لغوي (Claude أو Cursor أو Codex أو أي عميل MCP آخر) يعرف — بناءً على طلب المستخدم — كيف يقرأ حالة الشبكة ويجهّز الصفقات: «اعرض لي رصيد USDT»، «كم GRAM سأحصل مقابل 500 USDT»، «جمّع لي المبادلة». النموذج بمفرده لا يرى البلوكتشين؛ فهو يحتاج إلى أدوات.

وهذا بالضبط ما يفعله MCP (Model Context Protocol) — المعيار الذي يستدعي عبره الوكلاء أدوات خارجية. فبدلًا من أن تعلّم النموذج تأليف طلبات ADNL خام وتحليل خلايا BOC، تسلّمه مجموعة دوال ذات أنواع محددة: «أعطني الرصيد»، «أعطني عرض السعر»، «جمّع المعاملة». ويتصل TONNode بصفته مصدرًا لهذه الأدوات، فيمنح الوكيل 16 دالة بالضبط للعمل مع الشبكة: القراءة، والمبادلة، والتحويل عبر السلاسل، وتوليد المحفظة.

لا يحتاج وكيل التداول إلا إلى خمس منها، وكلها متاحة حتى في الخطة المجانية:

قراءة (get_balance, get_jetton_balance)
   -> تحديد decimals (get_jetton_info)
      -> تسعير (get_swap_quote)
         -> تجميع المبادلة (build_swap_tx)
            -> المحفظة توقّع عبر TonConnect

التفصيلة الجوهرية في الخطوة الأخيرة: من يوقّع هو محفظة المستخدم، لا الخادم. يعيد TONNode رسائل غير موقّعة — وسنفصّل في النهاية لماذا يُعدّ هذا أمرًا جوهريًا.

الخطوة 1: الوكيل يقرأ الأرصدة (get_balance, get_jetton_balance)

قبل أن يبادل أي شيء، على الوكيل أن يفهم ما الذي يملكه. أداتان:

• get_balance — رصيد GRAM على عنوان ما. و GRAM هو Toncoin بعد إعادة تسميته في يونيو 2026؛ أما الشبكة نفسها فما زالت تُسمى TON.
• get_jetton_balance — رصيد الجيتون: USDT أو NOT أو أي جيتون آخر. والسحر هنا أن عنوان محفظة الجيتون يُحسب على السلسلة. أنت تمرّر عنوان المالك وعنوان ماستر الجيتون، ويشتقّ TONNode بنفسه عنوان محفظة الجيتون ويقرأ رصيدها. لا حاجة إلى معرفة هذا العنوان مسبقًا ولا إلى تخزينه في أي مكان.

والموجّه الذي تعطيه للوكيل يبدو حرفيًا هكذا:

تحقّق من رصيد المحفظة UQAbc...xyz:
كم فيها من GRAM وكم فيها من USDT؟

تحت الغطاء يستدعي النموذج get_balance للرصيد الأصلي و get_jetton_balance لـ USDT. المشكلة الوحيدة أن ما يعود ليس مبالغ «بشرية» بعد، بل وحدات خام. وهنا يبدأ الأهم. أما كيف تحصل على رصيد USDT باستدعاء واحد دون عناء عناوين محافظ الجيتون، فله شرح مستقل: /blog/usdt-balance-ton-one-call.

decimals تحسم كل شيء: get_jetton_info ولماذا USDT = 6

تُخزَّن الأرصدة والمبالغ في TON بـ وحدات خام — أعداد صحيحة بلا جزء عشري. وللحصول على مبلغ يقرأه البشر، عليك قسمة العدد الخام على 10^decimals. والمصيدة هنا: عدد الـ decimals يختلف من جيتون إلى آخر.

• لدى USDT القيمة decimals = 6. أي أن 1 USDT = 1 000 000 وحدة خام.
• ولدى معظم الجيتونات على TON القيمة decimals = 9 (مثل GRAM). أي أن 1 جيتون = 1 000 000 000 وحدة خام.

الخلط بين 6 و 9 يعني خطأً في المبلغ بمقدار 1000 ضعف بالضبط. إنه «مليار USDT» نفسه الذي بدأنا به المقال. وبالنسبة لوكيل التداول هذه ليست مسألة تجميلية، بل هي جذر الثقة: إن كان يخلط بين المراتب فلا يصحّ أن تدعه يجمّع الصفقات.

لهذا يُدرَج get_jetton_info داخل خط الأنابيب — فهو يعيد بيانات الجيتون الوصفية: الاسم والرمز وإجمالي المعروض، والأهم من ذلك كله: decimals. المنطق الصحيح داخل الوكيل:

raw       = get_jetton_balance(...)   // مثال: 1000000000
decimals  = get_jetton_info(...)      // بالنسبة لـ USDT → 6
human     = raw / 10 ** decimals      // 1000000000 / 1e6 = 1000 USDT

القيمة الخام نفسها عند decimals = 9 كانت ستعطي توكنًا واحدًا — والفارق هائل. لا تكتب decimals ثابتة داخل الموجّه، ولا تترك النموذج «يخمّنها» من ذاكرته: مع جيتون جديد سيخطئ حتمًا. دعه يسحبها من get_jetton_info في كل مرة ويعيد الحساب على أساسها. تفصيل هذه المصيدة ولماذا تكلّف الناس أموالًا حقيقية: /blog/jetton-decimals-ton.

الخطوة 2: عرض سعر ثابت عبر Omniston (get_swap_quote)

قُرئت الأرصدة وحُوّلت إلى الوحدات الصحيحة — الآن يحتاج الوكيل إلى السعر. في DeFi لا ينفع «سعر تقريبي من الرأس»: السيولة موزّعة على عدة منصات DEX، والسعر يتحرّك، وعلى الوكيل أن يستند إلى عرض سعر آنيّ لا إلى تخمين.

get_swap_quote يعطي عرض سعر ثابتًا لمبادلة GRAM ⇄ جيتون عبر بروتوكول Omniston، الذي يجمّع سيولة أكبر منصتَي DEX على TON دفعةً واحدة — STON.fi و DeDust. لا يحتاج الوكيل إلى أن يستعلم عن مجمّعات السيولة بنفسه ويقارن الأسعار ويحسب الانزلاق السعري: يعيد Omniston أفضل مسار من السيولة المدمجة.

أعطني عرض سعر: كم GRAM سأحصل مقابل 50 USDT الآن؟

يستدعي النموذج get_swap_quote بالمبلغ 50000000 (تلك الوحدات الخام نفسها من الخطوة السابقة) فيحصل على أرقام محددة: كم في المدخل، وكم في المخرج، وعبر أي مسار، وبأي انزلاق سعري. هذه هي نقطة اتخاذ القرار: إن كان لدى الوكيل شرط («بادِل فقط إذا كان السعر أفضل من X») فهو يقارن العرض بالعتبة، ثم إما يمضي قدمًا أو ينتظر الدورة التالية. والمهم: عرض السعر ليس صفقة بعد. لا أموال تتحرك، ولا شيء يُوقَّع. إنها قراءة صافية للسوق.

الخطوة 3: تجميع مبادلة غير موقّعة (build_swap_tx) والتوقيع في المحفظة

رأى المستخدم عرض السعر وقال «نعم، لنبادل». يستدعي الوكيل build_swap_tx فيحصل على معاملة مبادلة غير موقّعة جاهزة لـ TonConnect.

وأشدّد على كلمة «غير موقّعة». الخادم يجمّع رسالة صحيحة — عنوان المستلم، والـ payload، والمبلغ، ومعطيات المسار — ويعيدها كما هي. بعدها تذهب الرسالة إلى محفظة المستخدم (Tonkeeper أو MyTonWallet أو أي محفظة متوافقة مع TonConnect)، فيرى المستخدم ما الذي يوقّعه بالضبط ويؤكّده بنفسه. ومن يضع التوقيع هو المفتاح الخاص للمستخدم، الذي يعيش داخل محفظته، لا الخادم.

get_balance / get_jetton_balance   →  اقرأ ما لديك
        ↓
get_jetton_info                     →  تحديد decimals وإعادة الحساب
        ↓
get_swap_quote (Omniston)           →  عرض سعر ثابت
        ↓
build_swap_tx                       →  معاملة غير موقّعة
        ↓
محفظة المستخدم (TonConnect)        →  التوقيع والإرسال

كل خطوة هي استدعاء أداة صريح ومستقل. والوكيل لا يتصرّف بالأموال «حسب تقديره الخاص»: هو يجهّز فقط، أما القرار والتوقيع فيبقيان للإنسان. السيناريو الكامل للمبادلة بلا وصاية، من عرض السعر إلى التوقيع، مشروح خطوة بخطوة هنا: /blog/agent-swap-ton-noncustodial.

بلا وصاية: لماذا لا يحتفظ الخادم بمفاتيح الوكيل أبدًا

هذه ليست صياغة تسويقية، بل حدّ معماري. أدوات المبادلة والتحويل عبر السلاسل وتوليد المحفظة في TONNode غير وصائية بشكل صارم:

• الخادم لا يوقّع المعاملات أبدًا.
• الخادم لا يخزّن المفاتيح الخاصة ولا الأموال أبدًا.
• وكل ما يخرجه إلى الخارج هو رسائل TonConnect غير موقّعة.

ولماذا هذا مهم لوكيل التداول تحديدًا؟ لأن الوكيل بحكم التعريف يتعامل مع المال، وبحكم التعريف قد يخطئ — أن يسيء فهم الطلب، أو يخلط في المبلغ، أو يدخل في حلقة لا تنتهي. لو كانت المفاتيح على الخادم وكان يوقّع بنفسه، لكان خطأ الوكيل يعني ضياع الأموال دون علمك. أما في المخطط غير الوصائي فخط الدفاع الأخير هو أنت: لا معاملة تغادر قبل أن تؤكّدها محفظتك.

قارن هذا بـ @ton/mcp الرسمي من TON Foundation — فهو محفظة وكيل وصائية: يحتفظ بمفتاح operator ويوقّع بنفسه (مخطط split-key حيث مفتاح operator لدى الوكيل ومفتاح owner لدى المستخدم). وله نقاط قوّته — الإنفاق المستقل دون مشاركة الإنسان، والعمل مع NFT و DNS، والصفة الرسمية من Foundation. لكن نموذج الثقة مختلف: هناك يستطيع الوكيل فعلًا تحريك الأموال. أما TONNode فيختار عمدًا الحدّ المعاكس: الخادم لا يوقّع أي شيء إطلاقًا. مقارنة مفصّلة بين المنهجين: /blog/custodial-vs-noncustodial-mcp.

كيف تربطه ومن أين تبدأ خلال 5 دقائق

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

الإعداد العام المحلي يمنحك مجموعة القراءة الكاملة (8 أدوات: get_masterchain_info, get_balance, get_account_state, get_transactions, run_get_method, get_jetton_balance, parse_address, get_jetton_info). يُثبَّت عبر npx، وبدون مفتاح:

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

حزمة @tonnode/mcp مفتوحة المصدر (MIT)، وموجودة على npm و GitHub (tonnode/mcp)، وتعمل ببروتوكول ADNL الأصلي لـ TON دون طبقات HTTP وسيطة بين الوكيل والشبكة. ألصِق الإعداد في Claude Desktop أو Cursor أو أي عميل MCP — وسيصبح الوكيل قادرًا فورًا على قراءة الأرصدة واستدعاء get_jetton_info.

أما عروض الأسعار نفسها — get_swap_quote و build_swap_tx — فتنتمي إلى مجموعة SWAP وتمرّ عبر نقطة النهاية المستضافة (hosted endpoint). والنقطة المفصلية: على مفتاح Hobby المجاني تتوفر الأدوات الـ16 كلها، بما فيها عرض السعر وتجميع المبادلة. أي أن خط أنابيب التداول بالكامل (قراءة → تسعير → مبادلة) يُبنى مجانًا — لكن عبر مفتاح Hobby المستضاف تحديدًا، لا عبر الإعداد العام المحلي. إعداد نقطة النهاية المستضافة:

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

لدى TONNode 16 أداة بالضبط، وفي جميع الخطط تتوفر الـ16 كلها — أنت تدفع مقابل سعة الطلبات فقط، لا مقابل الوظائف:

• Hobby — مجاني إلى الأبد، 60 طلبًا/دقيقة، بلا بطاقة.
• Pro — 29 دولارًا شهريًا، 300 طلب/دقيقة.
• Scale — 199 دولارًا شهريًا، 1200 طلب/دقيقة.

ولبدء خط أنابيب التداول وتجريبه يكفي مفتاح Hobby المجاني بفائض: 60 طلبًا في الدقيقة تعني عددًا كبيرًا من الاستدعاءات المتتالية للوكيل. لا حاجة إلى بطاقة، والمفتاح يُصدر فور تسجيل الدخول.

احصل على مفتاح Hobby مجانًا (60 req/min، بلا بطاقة): tonnode.io/dashboard?plan=hobby

القائمة الكاملة للأدوات الـ16: tonnode.io/mcp · الخطط والأسعار: tonnode.io/pricing

---

ابنِ خط الأنابيب من خمس أدوات — get_balance, get_jetton_balance, get_jetton_info, get_swap_quote, build_swap_tx — وأبقِ decimals تحت السيطرة، واترك التوقيع للمحفظة. عندئذٍ يكون لديك وكيل تداول يقرأ الأرصدة بأمانة، ويأخذ عرض سعر ثابتًا، ويجهّز مبادلة بمبالغ حقيقية، دون أن يصل ولو للحظة إلى مفاتيح أحد. هكذا بالضبط يجب أن يعمل وكيل التداول على TON.