OpenAI API میں فنکشن کالنگ: یہ درحقیقت کیا کرتی ہے اور اسے درست طریقے سے کیسے استعمال کریں

آپ صارف کا پیغام GPT API کو بھیجتے ہیں اور قدرتی زبان کے بجائے ماڈل آپ کو ایک ساختہ JSON آبجیکٹ واپس دیتا ہے جس میں یہ بتایا ہوتا ہے کہ کون سا فنکشن کال کرنا ہے اور کن دلائل کے ساتھ۔ یہی ہے function calling — اور یہ اس بات کو بدل دیتا ہے کہ آپ LLMs سے کس نوعیت کی ایپلیکیشنز بنا سکتے ہیں۔

زیادہ تر ڈویلپرز "function calling" سنتے ہیں اور سمجھتے ہیں کہ ماڈل ان کی طرف سے کوڈ چلا رہا ہے۔ ایسا نہیں ہے۔

Function calling استعمال کرنے پر LLM خود فنکشن ایکزیکیوٹ نہیں کرتا۔ اس کے بجائے وہ مناسب فنکشن کی شناخت کرتا ہے، درکار تمام پیرا میٹرز جمع کرتا ہے، اور معلومات ایک ساختہ JSON فارمیٹ میں فراہم کرتا ہے۔

آپ کی ایپلیکیشن اب بھی اصل لاجک چلانے کی ذمہ دار ہے۔ ماڈل صرف یہ بتا رہا ہوتا ہے کہ کیا چلانا ہے اور کن ان پٹس کے ساتھ۔

یہ فرق جتنا سنائی دیتا ہے اس سے زیادہ اہم ہے، اور یہی فرق آپ کے انٹیگریشن کے آرکیٹیکچر سے لے کر سکیورٹی کے تصور تک ہر چیز کو شکل دیتا ہے۔

Function Calling دراصل ہے کیا — اور لوگ بار بار کہاں غلط فہمی کا شکار ہوتے ہیں

Function calling (جسے tool calling بھی کہا جاتا ہے) OpenAI ماڈلز کے لیے بیرونی سسٹمز سے انٹرفیس کرنے اور اپنی تربیتی ڈیٹا سے باہر کے ڈیٹا تک رسائی حاصل کرنے کا ایک طاقتور اور لچکدار طریقہ ہے۔

نام ہی پہلی الجھن کی وجہ بنتا ہے۔ لوگ سمجھتے ہیں ماڈل کچھ ایکزیکیوٹ کر رہا ہے۔ ایسا نہیں ہے۔

Function calling کے بہت سے نام اور تشریحات ہیں، مگر بات ایک ہی جملے میں سمٹتی ہے: "function calling ایک بڑے لینگوئج ماڈل کی ساختہ آؤٹ پٹ کی صلاحیت کی ایک قسم ہے۔" LLMs خود کوئی فنکشن کال نہیں کرتے؛ وہ آپ کے فراہم کردہ پہلے سے متعین فنکشنز میں سے بتاتے ہیں کہ کون سا فنکشن آپ کو کال کرنا چاہیے۔

دوسری الجھن پرانے API انٹرفیس کے گرد ہے۔

functions اور function_call پیرا میٹرز کو 2023-12-01-preview ورژن کے ساتھ ڈپریکیکیٹ کر دیا گیا ہے۔ functions کی جگہ اب tools پیرا میٹر ہے۔

اگر آپ ایسا ٹیوٹوریل فالو کر رہے ہیں جو functions پیرا میٹر استعمال کرتا ہے، تو آپ پہلے ہی ڈپریکیکیٹڈ سنٹیکس پر ہیں۔ اس کے بجائے tools اور tool_choice استعمال کریں۔

ایک function دراصل tool کی مخصوص قسم ہے جو JSON اسکیما سے تعریف کی جاتی ہے۔ فنکشن ڈیفینیشن ماڈل کو آپ کی ایپلیکیشن تک ڈیٹا پہنچانے کی اجازت دیتی ہے، جہاں آپ کا کوڈ ماڈل کی تجویز کے مطابق ڈیٹا تک رسائی یا ایکشن لے سکتا ہے۔

یہ اسکیما ہی function calling کو سادہ پرامپٹنگ پر برتری دیتا ہے — آپ ماڈل کے درست فارمیٹ میں آؤٹ پٹ دینے پر انحصار نہیں کر رہے، آپ API لیول پر اسٹرکچر نافذ کر رہے ہیں۔

OpenAI API میں Function Calling کیسے کام کرتا ہے — مرحلہ وار

Tool calling آپ کی ایپ اور ماڈل کے درمیان OpenAI API کے ذریعے ایک کثیر مرحلہ مکالمہ ہے۔ اس کا فلو پانچ ہائی لیول مراحل پر مشتمل ہے: ماڈل کو ان tools کے ساتھ ریکویسٹ بھیجیں جو وہ کال کر سکتا ہے...

یہاں ہر مرحلہ عملی طور پر کیسا لگتا ہے:

مرحلہ 1: اپنے فنکشن اسکیماز کی تعریف کریں۔ آپ ہر دستیاب فنکشن کو tools پیرا میٹر کے اندر ایک JSON آبجیکٹ کے طور پر بیان کرتے ہیں۔ اسکیما میں فنکشن کا نام، قدرتی زبان میں ایک وضاحت جس سے ماڈل فیصلہ کرتا ہے کہ کب اسے کال کرنا ہے، اور ایک parameters بلاک شامل ہوتا ہے جو JSON Schema کنونشنز کو فالو کرتا ہے۔

جتنی مفصل آپ کی description ہو — یعنی کن حالات میں اسے کال کرنا چاہیے اور کب نہیں — اتنا بہتر۔ تاہم نوٹ کریں کہ فنکشن کی وضاحت پرامپٹ کا حصہ ہے، اس لیے وہ بھی ٹوکنز استعمال کرتی ہے۔

مرحلہ 2: ریکویسٹ بھیجیں۔ آپ Chat Completions API کو صارف کا پیغام اور اپنی tools لسٹ کے ساتھ کال کرتے ہیں۔ ماڈل دونوں دیکھتا ہے۔

مرحلہ 3: ماڈل فیصلہ کرتا ہے کہ فنکشن کال کرنا ہے یا نہیں۔

فنکشن کال ایک خاص قسم کے ریسپانس کو کہا جاتا ہے جو ماڈل اس وقت دیتا ہے جب وہ پرامپٹ کا جائزہ لے کر یہ طے کرتا ہے کہ ہدایات پر عمل کے لیے اسے دستیاب tools میں سے کسی ایک کو کال کرنا ہے۔ اگر ماڈل کو ایسا پرامپٹ ملے: "پیرس میں موسم کیسا ہے؟" تو وہ get_weather ٹول کے لیے ایک ٹول کال کے ساتھ جواب دے سکتا ہے، جس میں مقام کے طور پر پیرس شامل ہو۔

مرحلہ 4: آپ کا کوڈ فنکشن ایکزیکیوٹ کرتا ہے۔ آپ ماڈل کے ریسپانس کو پارس کرتے ہیں، فنکشن کا نام اور دلائل نکالتے ہیں، اور اپنے رن ٹائم میں اصل کوڈ چلاتے ہیں۔ API ساختہ JSON واپس کرتا ہے — آگے کیا کرنا ہے یہ آپ طے کرتے ہیں۔

مرحلہ 5: نتیجہ واپس بھیجیں۔

آپ پھر ٹول کی تعریف، اصل پرامپٹ، ماڈل کی ٹول کال، اور اس ٹول کال کا آؤٹ پٹ سب کچھ ماڈل کو واپس بھیجتے ہیں تاکہ آخرکار ایک ٹیکسٹ ریسپانس ملے

— مثلاً "آج پیرس کا موسم 25°C ہے۔"

ایک اہم بات جسے زیادہ تر ٹیوٹوریلز چھوڑ دیتے ہیں:

جب آپ اپنی فنکشن ڈیفینیشن میں strict: true سیٹ کرتے ہیں، تو Structured Outputs یہ گارنٹی دیتا ہے کہ ماڈل کے تیار کردہ دلائل آپ کے فراہم کردہ JSON Schema سے بالکل میل کھاتے ہوں گے۔

strict کو true پر سیٹ کرنے سے فنکشن کالز اسکیما کی پابندی کے ساتھ قابلِ اعتماد ہو جاتی ہیں، بجائے اس کے کہ وہ best effort ہوں۔ OpenAI ہمیشہ strict موڈ کو فعال رکھنے کی سفارش کرتا ہے۔

ہمیشہ۔ اسے بند رکھنے کی کوئی معقول وجہ نہیں۔

ساتھ ہی parallel function calling بھی موجود ہے۔

صارف کے سوال کے مطابق، اگر آپ 6 نومبر 2023 یا اس کے بعد جاری ہونے والے تازہ ماڈلز استعمال کر رہے ہیں تو ماڈل parallel function calling کا استعمال کرے گا۔

اس کا مطلب ہے کہ ایک ہی ریکویسٹ جیسے "London اور Tokyo میں موسم کیسا ہے؟" دو بیک وقت ٹول کالز ٹرگر کر سکتا ہے بجائے اس کے کہ انہیں تسلسل سے جوڑا جائے۔

Function Calling کے حقیقی دنیا کے استعمال

موسم والا مثال ہر جگہ ہے کیونکہ وہ صاف ہے۔ حقیقی پروڈکشن استعمال کے کیسز زیادہ الجھے ہوئے اور زیادہ دلچسپ ہوتے ہیں۔

لائیو ڈیٹا کے ساتھ کسٹمر سپورٹ پائپ لائنز

Function calling بہت سے استعمالات کے لیے مفید ہے — مثال کے طور پر ایک AI اسسٹنٹ جسے صارف کے "میرے حالیہ آرڈرز کیا ہیں؟" پوچھنے پر جواب دینے سے پہلے اندرونی سسٹم سے تازہ کسٹمر ڈیٹا لانا ہو۔

ماڈل نیت سمجھتا ہے، کانٹیکسٹ سے کسٹمر ID نکالتا ہے، اور آپ کے CRM کے اندرونی API کو کال کرتا ہے۔ نہ نازک regex، نہ ایسے پرامپٹ ٹیمپلیٹس جو ایک کاما کم ہونے پر ٹوٹ جائیں۔

وسیع پیمانے پر ساختہ ڈیٹا استخراج

ایک ڈیٹا ایکسٹریکشن پائپ لائن جو خام ٹیکسٹ لاتی ہے، اسے ساختہ ڈیٹا میں بدلتی ہے، اور ڈیٹا بیس میں محفوظ کرتی ہے بھی مضبوط فٹ ہے۔ اس طرح آپ ہزاروں دستاویزات میں یکساں اسکیما حاصل کرتے ہیں، بغیر ہر ڈاکومنٹ ٹائپ کے لیے پارسنگ لاجک ہاتھ سے ٹیون کیے۔

قدرتی زبان سے API ترجمہ

LLM سے تقویت پانے والے حل جو ڈیٹا ایکسٹریکٹ اور ٹیگ کرتے ہیں، ایسی ایپلیکیشنز جو قدرتی زبان کو API کالز یا درست ڈیٹا بیس کوئریز میں بدلنے میں مدد کرتی ہیں، اور ایسی گفتگو پر مبنی نالج ریٹریول انجنس جو نالج بیس کے ساتھ تعامل کرتی ہیں — یہ سب function calling کی آؤٹ پٹ فارمیٹ گارنٹی سے فائدہ اٹھاتے ہیں۔ جب آپ کو آؤٹ پٹ سے ڈاؤن اسٹریم سسٹمز چلانے ہوں، تو تغیر برداشت نہیں کیا جا سکتا۔

متعدد ٹولز کے ساتھ ایجنٹک ورک فلو

ڈویلپرز کے لیے، function calling حقیقی وقت کے ڈیٹا تک رسائی ممکن بناتی ہے تاکہ ٹریننگ کٹ آف کو لائیو اسٹاک قیمتیں، موسم، یا حالیہ ڈیٹا بیس اندراجات لا کر عبور کیا جا سکے۔ یہ ایکشن ایکزیکیوشن بھی ممکن بناتی ہے — LLM کو ایک غیر فعال مبصر سے ایک فعال شریک کار میں بدلتے ہوئے جو اسٹیٹ تبدیل کرتا ہے، جیسے ای میل بھیجنا، CRMs اپڈیٹ کرنا، یا کوڈ ڈپلائے کرنا۔

سادہ چیٹ بوٹ سے بنیادی فرق: ماڈل صرف متن پیدا نہیں کر رہا، وہ آپ کے سسٹمز میں حقیقی آپریشنز کو ہم آہنگ کر رہا ہے۔

Function Calling بہترین طریقہ کار — جہاں ڈویلپرز عموماً غلطی کرتے ہیں

یہ وہ سیکشن ہے جسے زیادہ تر ٹیوٹوریلز مکمل طور پر چھوڑ دیتے ہیں، اور اسی لیے ٹیمیں رات 2 بجے پروڈکشن میں عجیب ناکامیاں ڈیبگ کرتی ہیں۔

بہت مبہم وضاحتیں لکھنا۔ ماڈل آپ کے فنکشن کی وضاحت سے فیصلہ کرتا ہے کہ کب اسے کال کرنا ہے۔ اگر آپ کی وضاحت جنرک ہو — مثلاً "صارف کی درخواستیں پروسیس کرتا ہے" — تو ماڈل کے پاس اسے ٹرگر کرنے کے لیے قابلِ اعتماد اشارہ نہیں ہوگا۔ ٹرگر کنڈیشن اور متوقع ان پٹ شیپ کے بارے میں مخصوص ہوں۔ وضاحت کو محض لیبل نہیں، معاہدہ سمجھیں۔

ایک ساتھ بہت زیادہ فنکشنز سامنے رکھ دینا

فنکشن کی وضاحتیں ان پٹ پرامپٹ میں خاطر خواہ ٹوکنز استعمال کر سکتی ہیں۔

سِسٹم پرامپٹ میں 50+ ٹولز کی تعریفیں لوڈ کرنے سے دو مسائل جنم لیتے ہیں: لاگت اور لیٹنسی، کیونکہ ٹول ڈیفینیشنز ان پٹ ٹوکنز کھاتی ہیں؛ اور درستی میں کمی، کیونکہ جیسے جیسے ٹول آپشنز بڑھتے ہیں، درست انتخاب کرنے کی ماڈل کی صلاحیت گھٹتی ہے۔

اپنے استعمال کے کیس کے لیے درکار کم سے کم فنکشنز سے شروع کریں۔

یہ فرض کرنا کہ ماڈل پیرا میٹرز ہیلوسی نیٹ نہیں کرے گا۔ وہ کرے گا۔

ماڈل پیرا میٹرز ہیلوسی نیٹ کر سکتا ہے

— خاص طور پر ان optional فیلڈز کے لیے جو واضح طور پر کسی enum سے محدود نہیں۔ یہی وجہ ہے کہ strict: true اہم ہے: یہ ماڈل کی اس صلاحیت کو ختم کرتا ہے کہ وہ آپ کے اسکیما کے باہر فیلڈز گھڑ لے۔

ملٹی ٹرن لوپ کو ہینڈل نہ کرنا۔ ڈویلپرز اکثر خوش گوار راستہ بناتے ہیں — صارف نے پوچھا، ماڈل نے فنکشن کال کیا، بس۔

ماڈلز ایسے فنکشن کالز بھی بنا سکتے ہیں جو آپ کے متعین اسکیما سے میل نہیں کھاتے یا ایسے فنکشنز کال کرنے کی کوشش کر سکتے ہیں جو آپ نے شامل ہی نہیں کیے۔ اگر ماڈل غیر متوقع فنکشن کالز بنا رہا ہے، تو سسٹم میسج میں ایک سطر شامل کریں جیسے "Only use the functions you have been provided with."

کنارے کے کیسز کے لیے تعمیر کریں۔

رائٹ آپریشنز سے پہلے کنفرمیشن مرحلہ چھوڑ دینا۔

ان فنکشن کالز کے حقیقی دنیا پر اثرات سے باخبر رہیں جنہیں آپ ایکزیکیوٹ کرنے کا ارادہ رکھتے ہیں، خاص طور پر وہ جو کوڈ چلانے، ڈیٹا بیس اپڈیٹ کرنے، یا نوٹیفکیشنز بھیجنے جیسے ایکشنز ٹرگر کرتی ہیں۔ ایسے فنکشنز کے لیے جو ایکشن لیتے ہیں، ایک مرحلہ نافذ کرنا جس میں ایکزیکیوشن سے پہلے صارف کارروائی کی تصدیق کرے، سختی سے تجویز کیا جاتا ہے۔

اگر کوئی فنکشن کال ڈیٹا ڈیلیٹ کر سکتی ہے، پیسے بھیج سکتی ہے، یا بیرونی اسٹیٹ کو تبدیل کر سکتی ہے، تو پہلے انسان سے منظوری لیں۔

سکیورٹی اور قابلِ اعتماد ہونے کے غور و فکر

Function calling اس بات کو وسیع کرتی ہے کہ LLM کیا کر سکتا ہے۔ یہ اس بات کو بھی وسیع کرتی ہے کہ ایک اٹیکر اسے کیا کرنے پر مجبور کر سکتا ہے۔

بنیادی خطرہ یہاں prompt injection ہے۔

Prompt injections کے آخری مقاصد مختلف ہو سکتے ہیں مگر ان میں ڈاؤن اسٹریم ٹول کالز کے ذریعے نجی ڈیٹا باہر نکالنا، غیر ہم آہنگ ایکشنز لینا، یا کسی اور طرح ماڈل کے برتاؤ کو غیر ارادی طور پر بدلنا شامل ہو سکتے ہیں۔

جب آپ کی فنکشن کالز ای میل بھیج سکتی ہیں، ڈیٹا بیس کوئریز کر سکتی ہیں، یا ویب ہُکس ٹرگر کر سکتی ہیں، تو ایک انجیکشن اٹیک صرف چیٹ بوٹ کے اسکرپٹ سے ہٹنے کی بات نہیں — یہ ممکنہ بریک ہے۔

جیسے جیسے AI سسٹمز چیٹ سے آگے بڑھ کر ٹولز کال کرنے اور ایکشن لینے لگتے ہیں، prompt injection کہیں زیادہ سنگین مسئلہ بن جاتا ہے۔ کسی ویب پیج، دستاویز، یا بیرونی ٹول میں چھپی بدنیتی ہدایت سسٹم کے برتاؤ کو اوور رائیڈ کرنے، حساس معلومات ظاہر کرنے، یا ایسے ایکشنز ٹرگر کرنے کی کوشش کر سکتی ہے جو ماڈل کو کبھی نہیں کرنے چاہئیں۔

تخفیف کی حکمتِ عملی چند ٹھوس تہوں پر مبنی ہے۔

ورک فلو ایسے ڈیزائن کریں کہ غیر معتبر ڈیٹا کبھی بھی براہِ راست ایجنٹ کے برتاؤ کو نہ چلائے۔ بیرونی ان پٹس سے صرف مخصوص ساختہ فیلڈز — جیسے enums یا validated JSON — اخذ کریں تاکہ نوڈز کے بیچ انجیکشن رسک کے بہاؤ کو محدود رکھا جائے۔

اس کے اوپر،

ہمیشہ ماڈل کے جنریٹ کردہ فنکشن کالز کی تصدیق کریں۔ اس میں پیرا میٹرز، کال کیے جانے والے فنکشن، اور اس بات کی جانچ شامل ہے کہ کال ارادے کے مطابق ایکشن سے ہم آہنگ ہے۔

ایک ناگوار حقیقت:

"Prompt injection، بالکل ویسے ہی جیسے ویب پر اسکیمرز اور سوشل انجینئرنگ، غالب امکان ہے کہ کبھی پوری طرح 'حل' نہیں ہو گا۔"

یہ OpenAI کا اپنا اندازہ ہے۔ عملی نتیجہ یہ ہے کہ آپ کو ایجنٹک function-calling سسٹمز اس مفروضے پر آرکیٹیکچر نہیں کرنے چاہئیں کہ ماڈل ہمیشہ ارادے کے مطابق برتاؤ کرے گا۔ دفاعی تہہ در تہہ — ویلیڈیشن، محدود اختیارات، اور تباہ کن آپریشنز کے لیے انسان شامل — ہی معقول طرزِ عمل ہے۔

Function Calling بمقابلہ Prompt Engineering — کب کون سا استعمال کریں

یہ تقابل بار بار سامنے آتا ہے۔ مختصر جواب: یہ مختلف مسائل حل کرتے ہیں، اور ان کا خلط ملط ہونا ایسے پرامپٹس کی اوور انجینئرنگ تک لے جاتا ہے جہاں function calling کافی ہوتا، یا ایسے ناپختہ فنکشن اسکیماز تک جہاں ایک عمدہ سسٹم پرامپٹ زیادہ سادہ ہوتا۔

Prompt engineering میں ایسے ٹیکسٹ ان پٹس بنانا شامل ہے جو LLM کی اندرونی سوچ سازی کی رہنمائی کریں — مثلاً اسے یہ کہنا کہ "مرحلہ وار سوچیں"۔

یہ اس بات کو ڈھالتا ہے کہ ماڈل کیسے سوچتا ہے۔ دوسری طرف function calling اس بات کو ڈھالتا ہے کہ ماڈل کیا آؤٹ پٹ پیدا کرتا ہے اور اسے براہِ راست آپ کے سسٹم میں رُوٹ کرتا ہے۔

Tool calling وہ صلاحیت ہے جو LLM کو بیرونی سسٹمز کے ساتھ تعامل کی اجازت دیتی ہے۔ آپ ماڈل کو یہ طے کرنے میں مدد دینے کے لیے prompt engineering استعمال کرتے ہیں کہ کون سا ٹول استعمال کرے، جبکہ tool calling وہ میکنزم ہے جو دراصل ایکشن ایکزیکیوٹ کرتا ہے۔ غالباً آپ کو دونوں کی ضرورت پڑے، مگر ان کے مقاصد مختلف ہیں۔

Function calling کی ایک اہم تکنیکی برتری prompt-based ساختہ آؤٹ پٹ پر:

tool calling ماڈل میں ہی بطور تصور ضم ہے۔ ماڈل کو یہ سمجھانے پر ٹوکنز اور محنت ضائع کرنے کی ضرورت نہیں کہ اسے مخصوص فارمیٹ میں جواب دینا ہے۔

جب آپ ایک پرامپٹ بناتے ہیں کہ "اپنا جواب JSON کی صورت میں فیلڈز X، Y، اور Z کے ساتھ واپس کریں"، تو آپ ہدایات پر ٹوکنز خرچ کر رہے ہوتے ہیں جن پر ماڈل مستقل مزاجی سے عمل نہ بھی کرے۔ Function calling کے ساتھ اسکیما کی پابندی API لیول پر نافذ ہوتی ہے۔

Function-calling APIs، جو اب بہت سے LLM پلیٹ فارمز میں نیٹو طور پر سپورٹڈ ہیں، ایک رسمی اسکیما ڈرِون انٹرفیس فراہم کرتی ہیں جو سخت ڈیٹا ویلیڈیشن اور پروگراماتی ورک فلو انٹیگریشن کو ممکن بناتی ہیں۔

یہی حقیقی دنیا کی وجہ ہے کہ اسے prompt engineering پر ترجیح دیں جب بھی ڈیٹا نے ڈاؤن اسٹریم سسٹمز میں بہنا ہو: پروڈکشن میں پہنچ کر قابلِ اعتماد ہونا اختیار نہیں رہتا۔

عملی اصول: اگر آؤٹ پٹ نے کسی ڈاؤن اسٹریم سسٹم — جیسے ڈیٹا بیس رائٹ، API کال، یا آپ کے کوڈ میں ڈسیژن برانچ — کو چلانا ہے، تو function calling استعمال کریں۔ اگر آؤٹ پٹ انسان کے پڑھنے کے لیے ہے، تو prompt engineering عموماً کافی اور سستی ہے۔

اہم نکات

اگر آپ مختلف ماڈلز — GPT-5.4, claude opus 4.7, gemini 3.1 pro — پر function calling آزمانا چاہتے ہیں، اور ہر ایک کے لیے علیحدہ API اسناد برقرار نہیں رکھنا چاہتے، تو CometAPI ایک واحد اینڈ پوائنٹ اور کی کے ذریعے ان سب تک رسائی دیتا ہے، جس سے کراس ماڈل ٹیسٹنگ کافی کم رکاوٹ والی ہو جاتی ہے۔

CometAPI انفراسٹرکچر کا بوجھ کم کرتا ہے:

✅ 15+ ماڈلز میں متحدہ function calling سنٹیکس

✅ واحد API کی — OpenAI/Anthropic/Google کے علیحدہ اکاؤنٹس کی ضرورت نہیں

✅ خودکار اسکیما ترجمہ — ایک بار لکھیں، ہر جگہ ٹیسٹ کریں

✅ بلٹ اِن لاگت ٹریکنگ — فی ماڈل ٹوکن استعمال ریئل ٹائم میں موازنہ کریں

مفت کریڈٹس کے ساتھ ٹیسٹنگ شروع کریں → رسائی حاصل کریں