---
title: "MCP یا CLI غلط سوال ہے۔ یہ پوچھیں کہ اسٹیٹ کہاں رہتی ہے۔"
description: "Tobi Lütke کہتے ہیں کہ MCP بمقابلہ CLI کی بحث غلط لیئر پر ہو رہی ہے: اگر اسٹیپس کے درمیان اسٹیٹ برقرار رہے تو دونوں کام کرتے ہیں۔ ہم متفق ہیں۔ کسی سنک کے لیے وہ اسٹیٹ کسی REPL کی ہیپ نہیں بلکہ انٹیگریشن کے اپنے ریکارڈ ہیں، اور اسی لیے Tajo کے MCP ٹولز سیشن میں کچھ بھی نہیں رکھتے۔"
url: https://tajo.io/ur/blog/mcp-or-cli-is-the-wrong-question/
markdown: https://tajo.io/ur/blog/mcp-or-cli-is-the-wrong-question.md
lang: ur-PK
author: "Set Noa"
author_url: https://tajo.io/ur/set-noa/
published: 2026-11-04
updated: 2026-11-05
alternates: {en-US: /blog/mcp-or-cli-is-the-wrong-question.md, bg-BG: /bg/blog/mcp-or-cli-is-the-wrong-question.md, cs-CZ: /cz/blog/mcp-or-cli-is-the-wrong-question.md, de-DE: /de/blog/mcp-or-cli-is-the-wrong-question.md, da-DK: /dk/blog/mcp-or-cli-is-the-wrong-question.md, es-ES: /es/blog/mcp-or-cli-is-the-wrong-question.md, fr-FR: /fr/blog/mcp-or-cli-is-the-wrong-question.md, el-GR: /gr/blog/mcp-or-cli-is-the-wrong-question.md, hi-IN: /hi/blog/mcp-or-cli-is-the-wrong-question.md, id-ID: /in/blog/mcp-or-cli-is-the-wrong-question.md, hr-HR: /hr/blog/mcp-or-cli-is-the-wrong-question.md, hu-HU: /hu/blog/mcp-or-cli-is-the-wrong-question.md, it-IT: /it/blog/mcp-or-cli-is-the-wrong-question.md, ja-JP: /jp/blog/mcp-or-cli-is-the-wrong-question.md, ko-KR: /kr/blog/mcp-or-cli-is-the-wrong-question.md, ar-SA: /ar/blog/mcp-or-cli-is-the-wrong-question.md, nl-NL: /nl/blog/mcp-or-cli-is-the-wrong-question.md, no-NO: /no/blog/mcp-or-cli-is-the-wrong-question.md, pl-PL: /pl/blog/mcp-or-cli-is-the-wrong-question.md, pt-BR: /pt/blog/mcp-or-cli-is-the-wrong-question.md, ro-RO: /ro/blog/mcp-or-cli-is-the-wrong-question.md, ru-RU: /ru/blog/mcp-or-cli-is-the-wrong-question.md, sv-SE: /se/blog/mcp-or-cli-is-the-wrong-question.md, zh-CN: /zh-cn/blog/mcp-or-cli-is-the-wrong-question.md, sl-SI: /sl/blog/mcp-or-cli-is-the-wrong-question.md, sr-Latn-RS: /sr/blog/mcp-or-cli-is-the-wrong-question.md, th-TH: /th/blog/mcp-or-cli-is-the-wrong-question.md, tr-TR: /tr/blog/mcp-or-cli-is-the-wrong-question.md, vi-VN: /vi/blog/mcp-or-cli-is-the-wrong-question.md, sk-SK: /sk/blog/mcp-or-cli-is-the-wrong-question.md}
---

[AI ایجنٹس](https://tajo.io/ur/blog/?category=ai-agents)

# MCP یا CLI غلط سوال ہے۔ یہ پوچھیں کہ اسٹیٹ کہاں رہتی ہے۔

Tobi Lütke کہتے ہیں کہ MCP بمقابلہ CLI کی بحث غلط لیئر پر ہو رہی ہے: اگر اسٹیپس کے درمیان اسٹیٹ برقرار رہے تو دونوں کام کرتے ہیں۔ ہم متفق ہیں۔ کسی سنک کے لیے وہ اسٹیٹ کسی REPL کی ہیپ نہیں بلکہ انٹیگریشن کے اپنے ریکارڈ ہیں، اور اسی لیے Tajo کے MCP ٹولز سیشن میں کچھ بھی نہیں رکھتے۔

mcp بمقابلہ cli

کیا AI ایجنٹ کو MCP استعمال کرنا چاہیے یا CLI?

Lütke درست ہیں کہ MCP بمقابلہ CLI غلط لیئر ہے: اگر اسٹیپس کے درمیان اسٹیٹ برقرار رہے تو دونوں کام کرتے ہیں، اور bash صرف اس لیے جیتتا ہے کہ فائل سسٹم ہی وہ اسٹیٹ ہے۔ لیکن کسی سنک کے لیے اسٹیٹ کسی REPL کی ہیپ نہیں ہے۔ یہ انٹیگریشن کے اپنے ریکارڈ ہیں: ایک کرسر، ایک زیر التوا تجویز، ایک لیز، ایک پلان۔ اسی لیے Tajo کے MCP ٹولز سیشن میں کچھ بھی نہیں رکھتے: کوئی بھی ایجنٹ، کسی بھی کلائنٹ سے، ریکارڈز سے آگے بڑھتا ہے۔ Tajo آج گاہکوں کا کوئی کوڈ نہیں چلاتا اور اس کے پاس کوئی REPL نہیں ہے، اور ہم نیچے یہ صاف صاف کہتے ہیں۔

[مزید جانیں](https://tajo.io/ur/blog/mcp-or-cli-is-the-wrong-question/#%D9%88%DB%81-%D9%84%DB%8C%D8%A6%D8%B1-%D8%AC%D8%B3-%DA%A9%DB%8C-%D9%88%DB%81-%D8%A8%D8%A7%D8%AA-%DA%A9%D8%B1-%D8%B1%DB%81%DB%92-%DB%81%DB%8C%DA%BA)

21 ستمبر 2026 کو، 00:33 UTC پر، Tobi Lütke نے یہ پوسٹ کیا: “LLMs کے لیے MCP بمقابلہ CLI غلط بحث ہے۔ لوگ غلط لیئر پر بحث کر رہے ہیں۔” پھر [23 اکتوبر کو](https://x.com/tobi/status/2113596638899974567) انہوں نے ایک نئی ریپوزیٹری کی طرف اشارہ کیا جس کا نام [dquickts](https://github.com/stencil-hq/dquickts) ہے۔ یہ QuickJS کا ایک فورک ہے جو کسی پروگرام کو `for` لوپ کے بیچ میں روک سکتا ہے، اس کی پوری ہیپ کو بائٹس میں لکھ سکتا ہے، اور اسے کسی دوسرے پروسیس میں وہیں سے دوبارہ شروع کر سکتا ہے۔ انہوں نے لکھا: “کوڈ موڈ کے لیے بہترین ماحول۔”

لیئر کے بارے میں وہ درست ہیں۔ میں پہلے ان سے انہی کے الفاظ میں اتفاق کرنا چاہتا ہوں، اور پھر اس دعوے کو اتنا محدود کرنا چاہتا ہوں کہ یہ کوئی ایسی بات کہے جو کسی سنک کے کام آ سکے۔

## وہ لیئر جس کی وہ بات کر رہے ہیں

یہ رہی ان کی دلیل، بالکل اسی طرح جیسے انہوں نے پیش کی، کیونکہ جس دلیل کو آپ موڑنے کا ارادہ رکھتے ہوں اسے نقل کرنے کا یہی واحد منصفانہ طریقہ ہے:

> دونوں اس وقت تک حیرت انگیز طور پر اچھا کام کرتے ہیں جب تک انہیں کسی ایسے REPL جیسے ماحول کے ذریعے چلایا جائے جو اسٹیٹ کو برقرار رکھ سکے۔ CLI کی دلچسپ بات یہ ہے کہ CLI ٹولز عام طور پر BASH کے ذریعے استعمال ہوتے ہیں، جو اتفاق سے مستقل اسٹیٹ (فائل سسٹم) والا ایک REPL ہے، اس لیے CLI، MCP سے کہیں بہتر کام کرتا ہے۔ لیکن یہ MCP کی کوئی بنیادی خصوصیت ہونے کے قریب بھی نہیں۔ اس کا مطلب بس یہ ہے کہ ہمیں بہتر ہارنیس کی ضرورت ہے۔

یہ درست ہے، اور یہ اس مشاہدے کی وضاحت کرتا ہے جو بہت سے لوگوں نے وضاحت کے بغیر کیا ہے۔ جس ایجنٹ کو CLI دیا جائے وہ ایک فائل لکھتا ہے، تین اسٹیپس بعد اسے واپس پڑھتا ہے، اس میں grep کرتا ہے، اسے پائپ کرتا ہے۔ جس ایجنٹ کو صرف ایک سادہ MCP سرور دیا جائے اسے ہر کال پر ایک نتیجہ ملتا ہے اور باقی سب کچھ اسے اپنی کانٹیکسٹ ونڈو میں اٹھائے پھرنا پڑتا ہے۔ CLI پروٹوکول کی وجہ سے نہیں جیتا۔ وہ اس لیے جیتا کہ bash کے ساتھ چیزیں رکھنے کی ایک جگہ آتی تھی۔

ان کی شرط اسی سے نکلتی ہے۔ کوئی ایک ایمبیڈ کیا جا سکنے والا، SQLite طرز کا انجن بنائے گا جو bash، TypeScript یا ٹول کالز کو ایک پلان میں بدل دے گا، جسے چلنے سے پہلے جانچا جائے گا اور جو پائیدار ایگزیکیوشن کے لیے بنا ہوگا۔ dquickts اسی سمت میں ایک قدم ہے۔ [اس کی README](https://github.com/stencil-hq/dquickts) ایک ایسے REPL کو بیان کرتی ہے “جس کے فنکشنز اور ویری ایبلز ری اسٹارٹ کے بعد بھی باقی رہتے ہیں”۔ یہ ایک پائیدار ہوسٹ کال کو بھی بیان کرتی ہے: “ایک اسکرپٹ کسی ہوسٹ فنکشن کو کال کرتی ہے جس کا جواب گھنٹوں بعد آتا ہے۔ پروسیس اسکرپٹ کو محفوظ کرتا ہے اور بند ہو جاتا ہے۔”

یہاں تک مکمل اتفاق ہے۔ اب اسے محدود کرتے ہیں۔

## کون سی اسٹیٹ، کس کام کے لیے

“اسٹیٹ برقرار رکھنا” ایک سوال کو چھپا لیتا ہے: کس کی اسٹیٹ، اور کس شکل میں؟ کسی کوڈنگ ایجنٹ کے لیے اسٹیٹ ریپوزیٹری اور شیل ہے، اور ری اسٹارٹ کے بعد بھی باقی رہنے والا REPL ایک اچھا جواب ہے۔ دو SaaS سسٹمز کے درمیان سنک بنانے والے ایجنٹ کے لیے، اسٹیپس کے درمیان اسے جو اسٹیٹ درکار ہے وہ کام نے پہلے سے طے کر رکھی ہے۔ چار ریکارڈ اسے سنبھالتے ہیں، اور ان میں سے کوئی بھی کسی اسکرپٹ کا ویری ایبل نہیں۔

**کرسر۔** ایک سنک سورس کو ونڈوز میں پڑھتا ہے اور اسے معلوم ہونا چاہیے کہ پچھلی ونڈو کہاں ختم ہوئی۔ Tajo کے سنک انجن میں یہ ہر سنک اور اسکوپ کے لیے [محفوظ کیا گیا ایک کرسر](https://tajo.io/ur/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#cursor) ہے، جو ہر اس بیچ کے بعد لکھا جاتا ہے جس میں کوئی ریکارڈ ناکام نہ ہو، اور اگلا رن وہیں سے آگے بڑھتا ہے۔ ایک شیڈولڈ رن کچھ بھی کرنے سے پہلے اپنا نقطۂ آغاز محفوظ کرتا ہے، تاکہ اگر پہلا رن ناکام ہو جائے تو اگلا رن اسی نقطے سے پڑھے۔ اس کے پیچھے کا اصول، یعنی صرف فرق بھیجیں اور کبھی پوری ٹیبل نہیں، [ریورس ETL کی وضاحت](https://tajo.io/ur/blog/what-is-reverse-etl/) میں ہے۔ کرسر کی بات میں وہیں چھوڑتا ہوں۔

**زیر التوا تجویز۔** Tajo کے کنیکٹر MCP ٹولز پر ایک رائٹ دو کالز پر مشتمل ہوتی ہے۔ `brevo_propose` ان پٹ کو اعلان شدہ ایکشن کے مقابلے میں جانچتا ہے اور ایک تجویز ریکارڈ کرتا ہے۔ کچھ بھی بھیجا نہیں جاتا۔ نتیجے میں تجویز کی ID ہوتی ہے اور، جب کسی شخص کو فیصلہ کرنا ہو، وہ صفحہ ہوتا ہے جہاں وہ اسے منظور کرتا ہے۔ `brevo_apply` اس کنکشن کی منظور شدہ رائٹس کو ترتیب سے چلاتا ہے اور اس پہلی رائٹ پر رک جاتا ہے جو ابھی تک کسی شخص کی منتظر ہو۔ درمیان کا ریکارڈ ہی اسٹیٹ ہے۔ اس میں ان پٹ اور اس کا ایک ڈائجسٹ رہتا ہے، تاکہ کسی منظور شدہ رائٹ کو فیصلے اور apply کے درمیان بدلا نہ جا سکے۔ اس میں پرووائیڈر کے رسپانس کی ویلیوز نہیں رہتیں، کیونکہ صرف اضافے والا منظوری ریکارڈ ذاتی ڈیٹا کا ذخیرہ نہیں بننا چاہیے۔

**لیز۔** کسی سنک کا ایک رن اپنی پوری مدت کے لیے ایک [خصوصی لیز](https://tajo.io/ur/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#lease) رکھتا ہے، جس میں ایک اونر ٹوکن، ڈیفالٹ طور پر پندرہ منٹ کی وقت کی حد، اور تجدید شامل ہے۔ ایک پرانا اونر نئی لیز کو ریلیز نہیں کر سکتا۔ اگر لیز اسٹور تک رسائی نہ ہو تو رن اندازہ لگانے کے بجائے شروع ہونے سے انکار کر دیتا ہے۔ رن کس ورکر کے پاس ہے، یہ لیز میں درج ایک حقیقت ہے، کسی پروسیس کی میموری میں نہیں۔

**پلان۔** `syncs.dryRun` کرسر سے اگلی ونڈو پڑھتا ہے، ہر ریکارڈ کے لیے طے کرتا ہے کہ انسرٹ، اپڈیٹ، ڈیلیٹ یا کوئی تبدیلی نہیں، اور ٹھیک ایک قطار لکھتا ہے: وہ پلان، جو ایک گھنٹے تک رکھا جاتا ہے۔ یہ کوئی کرسر آگے نہیں بڑھاتا اور کسی بھی سسٹم میں کچھ نہیں لکھتا۔ `syncs.apply` اس پلان کو ایک بار لکھتا ہے۔ اگر اس دوران کرسر آگے بڑھ گیا ہو، یا ریکارڈز کا قابل برداشت حصے سے زیادہ حصہ بدل گیا ہو، تو یہ انکار کر دیتا ہے۔ دہرانے پر یہ دوبارہ لکھنے کے بجائے پہلا نتیجہ واپس کرتا ہے۔

یہی اسٹیپس کے درمیان کی اسٹیٹ ہے: ID والے چار ریکارڈ، جنہیں دیکھنے کی اجازت رکھنے والا کوئی بھی ایجنٹ پڑھ سکتا ہے۔

## MCP کی طرف سیشن میں کچھ کیوں نہیں رکھا جاتا

ایک بار اسٹیٹ ریکارڈز میں آ جائے تو سیشن کے پاس رکھنے کو کچھ نہیں بچتا۔ اس لیے Tajo کے MCP اینڈ پوائنٹس کوئی سیشن نہیں رکھتے۔ ہر ریکویسٹ کو ایک نیا سرور اور بغیر سیشن ID کا ٹرانسپورٹ ملتا ہے۔ ریڈز ہر کال پر ایک ریکویسٹ ہوتی ہیں، اور نتائج کی حد مقرر ہے تاکہ ایک جواب پوری باری کو نہ بھر دے۔ رائٹس پہلے propose، پھر apply ہوتی ہیں، اور آپ تجویز کی ID ساتھ لے کر چلتے ہیں۔

پروٹوکول بھی اسی سمت میں بڑھا۔ [MCP اسپیسیفیکیشن کی 2026-07-28 نظرثانی](https://modelcontextprotocol.io/specification/2026-07-28/changelog) نے Streamable HTTP ٹرانسپورٹ سے پروٹوکول کی سطح کے سیشن اور `Mcp-Session-Id` ہیڈر ہٹا دیے۔ جس سرور کو تسلسل درکار ہو وہ اب اپنا ہینڈل خود بناتا ہے اور اسے ایک عام آرگیومنٹ کے طور پر واپس پاتا ہے۔ تجویز کی ID یہی ہے۔ [MCP سرور کیا ہے](https://tajo.io/ur/blog/what-is-an-mcp-server/) اس نظرثانی کو اور اس بات کو بیان کرتا ہے کہ ایک ٹول کال پائیدار سنک سے کیسے مختلف ہے؛ یہ تحریر صرف اس بارے میں ہے کہ اسٹیٹ کہاں جاتی ہے۔

انٹیگریشن کے کام کے لیے جو نتیجہ اہم ہے وہ یہ ہے۔ فرض کریں Claude Code میں ایک ایجنٹ ایک رائٹ تجویز کرتا ہے اور اس کا سیشن ختم ہو جاتا ہے۔ وہ شخص اسے ایک گھنٹے بعد منظور کرتا ہے۔ کسی دوسرے کلائنٹ کا ایجنٹ، یا اگلے دن وہی ایجنٹ، ID کے ساتھ apply کال کرتا ہے اور رائٹ ایک بار نافذ ہو جاتی ہے۔ کریش ہونے والا ایجنٹ اپنی کانٹیکسٹ ونڈو کھوتا ہے، اور کچھ نہیں۔ کچھ بھی معطل نہیں کیا گیا تھا، اس لیے کسی چیز کو دوبارہ شروع کرنے کی ضرورت نہیں پڑی۔

## ہمارے پاس کیا نہیں ہے، اور اس کی قیمت کیا ہے

دیانت دارانہ اعتراض REPL کی طرف سے آتا ہے اور کچھ یوں ہے: “ٹھیک ہے، آپ کے ریکارڈ باقی رہتے ہیں۔ لیکن ہر کال وہ دوبارہ پڑھتی ہے جو پچھلی کال کے پاس پہلے سے تھا۔ ایک اسکرپٹ کانٹیکٹس کو ایک بار لاتی، انہیں جوڑتی، فلٹر کرتی اور ایک عدد واپس کر دیتی۔ آپ کا ایجنٹ پانچ کالز کرتا ہے اور ہر ایک کی قیمت ادا کرتا ہے۔” یہ اعتراض میکانزم کے بارے میں درست ہے، اور ہم نے اس کی قیمت نہیں ناپی۔ جو جائزہ ساتھ لے جائی گئی اسٹیٹ کے ساتھ اور اس کے بغیر ہر ٹاسک میں کالز گنے گا، وہ ابھی بنا نہیں۔ جب تک وہ نہیں بنتا، یہ دعویٰ کہ کال موڈ زیادہ ٹوکن خرچ کرتا ہے، لاجواب رہتا ہے۔

تین مزید باتیں صاف صاف کہنا ضروری ہیں، کیونکہ یہ مضمون ختم کرنے والے قاری کو ان کا تصور نہیں کرنا چاہیے:

- **آج گاہکوں کا لکھا کوئی کوڈ نہیں چلتا۔** کنیکٹر ریڈز ہر کال پر ایک ریکویسٹ ہوتی ہیں، راستے میں کوئی سینڈ باکس نہیں۔ ہمارے اسٹیک میں ایک کوڈ رنر موجود ہے، اور وہ ایک اندرونی ٹول ہے۔ پروڈکشن میں وہ اس وقت تک بند رہتا ہے جب تک دو الگ الگ فلیگز سیٹ نہ ہوں، اور وہ صرف ایڈمنسٹریٹرز کو جواب دیتا ہے۔ ہر کال کو ایک نیا کانٹیکسٹ، صرف ریڈ کی اجازت دینے والی بائنڈنگز، اور سنکرونس کوڈ کے لیے دو سیکنڈ کا بجٹ ملتا ہے۔ اس کا اپنا ہیڈر بڑے حروف میں کہتا ہے کہ یہ درستی کی حد ہے، سیکیورٹی کی نہیں۔
- **کوئی REPL نہیں۔** ایک ایجنٹ ایک کال میں جو کچھ حساب کرتا ہے وہ اگلی کال کو تبھی دستیاب ہوتا ہے جب اسے ID والے ریکارڈ کے طور پر لکھا گیا ہو۔
- **کوئی مستقل ایجنٹ سیشن نہیں۔** کلائنٹ اپنی گفتگو رکھتا ہے۔ Tajo تجاویز، پلان، کرسر اور لیز رکھتا ہے۔ کوئی تیسری چیز نہیں ہے۔

## پائیدار انجن کس کام کا ہے

ان میں سے کچھ بھی dquickts کے خلاف دلیل نہیں۔ اس کی README بتاتی ہے کہ اسنیپ شاٹس کس کام کے ہیں، اور فہرست اچھی ہے۔ کسی غیر فعال اسکرپٹ کو ہائبرنیٹ کر کے اس کی میموری خالی کرنا۔ کسی طویل حساب کو ٹکڑوں میں اس ورکر پر چلانا جو فارغ ہو۔ سیٹ اپ دہرانے کے بجائے ہر انسٹینس کو ایک اسنیپ شاٹ سے وارم اسٹارٹ کرنا۔ کسی اسکرپٹ کو ایسی ہوسٹ کال پر روک کر رکھنا جس کا جواب بعد میں آتا ہے۔ کسی کوڈنگ ایجنٹ کے ورک اسپیس کے لیے، یا ایسی نوٹ بک کے لیے جسے ری اسٹارٹ کے بعد باقی رہنا چاہیے، یہی درست ٹول ہے۔

پھر بھی کسی سنک کو اس پر انحصار نہیں کرنا چاہیے، اور اس کی تین وجوہات خود README مجھے دیتی ہے۔ پہلی: “ایک سیشن فائل صرف اسی qjs بلڈ میں لوڈ ہوتی ہے جس نے اسے لکھا۔” ایک انجن ورژن کی لکھی ہیپ اپگریڈ کے بعد ایک مردہ فائل ہے؛ کرسر ایک اسٹرنگ ہے۔ دوسری: “اسنیپ شاٹس قابل اعتماد ان پٹ ہیں، بائٹ کوڈ کی طرح،” اور “بدنیتی پر مبنی اسنیپ شاٹس پکڑے نہیں جاتے۔” محفوظ کی گئی ہیپ ایسی چیز ہے جس کی آپ کو حفاظت کرنی ہوتی ہے، ایسی چیز نہیں جس کا آپ جائزہ لے سکیں؛ تجویز ایک قطار ہے جسے شخص منظوری دینے سے پہلے پڑھتا ہے۔ تیسری، اسنیپ شاٹ میں وہ سب رہتا ہے جو اسکرپٹ نے پڑھا تھا، گاہکوں کے ریکارڈ سمیت۔ اوپر کے ریکارڈ اس کے برعکس بنائے گئے ہیں: پلان ویلیوز نہیں بلکہ ڈائجسٹ رکھتا ہے، اور تجویز کا ریکارڈ پرووائیڈر کا رسپانس کبھی نہیں رکھتا۔

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

Lütke نے درست سوال پوچھا۔ اسٹیٹ کہاں رہتی ہے؟ کسی سنک کے لیے جواب کبھی پروسیس میں نہیں ہونا تھا۔ وہ ہمیشہ ریکارڈز میں ہونا تھا، کیونکہ رائٹ کو منظور کرنے والے شخص کو اسے وہیں پڑھ پانا چاہیے۔

## اکثر پوچھے گئے سوالات

**AI ایجنٹس کے لیے MCP بہتر ہے یا CLI?**

اپنے طور پر کوئی بھی نہیں۔ 21 ستمبر 2026 کو Tobi Lütke کی بات درست ہے: جب کالز کسی ایسی چیز سے ہو کر چلتی ہیں جو اسٹیپس کے درمیان اسٹیٹ محفوظ رکھتی ہے تو دونوں کام کرتے ہیں۔ آج CLI بہتر محسوس ہوتا ہے کیونکہ bash فائل سسٹم میں اسٹیٹ رکھتا ہے۔ فرق پروٹوکول کا نہیں، ہارنیس کا ہے۔

**سنک کے اسٹیپس کے درمیان ایجنٹ کو کون سی اسٹیٹ درکار ہوتی ہے?**

انٹیگریشن کے اپنے ریکارڈ: ایک کرسر جو بتاتا ہے کہ پچھلا رن کہاں رکا، ایک تجویز جو کسی شخص کی منظوری کی منتظر ہے، ایک لیز جو بتاتی ہے کہ رن کس ورکر کے پاس ہے، اور ایک ڈرائی رن پلان جس سے apply کا مطابقت رکھنا ضروری ہے۔ ان میں سے کچھ بھی کسی اسکرپٹ کا ویری ایبل نہیں۔ یہ سب ID والی قطاریں ہیں۔

**Tajo کا MCP سرور سیشن میں کچھ بھی کیوں نہیں رکھتا?**

ہر ریکویسٹ کو ایک نیا سرور اور بغیر سیشن ID کا ٹرانسپورٹ ملتا ہے۔ اگلی کال کو جو کچھ بھی چاہیے وہ ایک ریکارڈ ہے: تجویز کی ID، پلان کی ID، ایک کرسر۔ اس لیے کسی دوسرے کلائنٹ میں دوسرا ایجنٹ وہیں سے آگے بڑھ سکتا ہے جہاں پہلا رکا تھا، اور کریش ہونے والا ایجنٹ اپنی کانٹیکسٹ ونڈو کے سوا کچھ نہیں کھوتا۔

**کیا Tajo ایجنٹس کا لکھا ہوا کوڈ چلاتا ہے?**

گاہکوں کے لیے نہیں۔ کنیکٹر ٹولز پر ریڈز ہر کال پر ایک ریکویسٹ ہوتی ہیں، بغیر کسی سینڈ باکس کے۔ جو کوڈ رنر موجود ہے وہ دو فلیگز کے پیچھے ایک اندرونی ٹول ہے، جس تک صرف ایڈمنسٹریٹرز پہنچ سکتے ہیں، جس کی بائنڈنگز صرف پڑھنے کے لیے ہیں اور جو ہر کال پر نیا کانٹیکسٹ لیتا ہے۔ وہ اپنے بارے میں کہتا ہے کہ وہ سیکیورٹی کی حد نہیں ہے۔ نہ کوئی REPL ہے اور نہ کوئی مستقل سیشن۔

**dquickts جیسا پائیدار JavaScript انجن کس کام کا ہے?**

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

## متعلقہ مضامین

### [جواب درست ہے، مگر راستہ غلط ہے](https://tajo.io/ur/blog/the-answer-is-right-the-path-is-wrong/)

8 اکتوبر، 2026 · 4 منٹ پڑھیں

3 حصے

### [ہر MCP ٹول کال پر کیا لاگ کریں](https://tajo.io/ur/blog/what-to-log-for-every-mcp-tool-call/)

6 نومبر، 2026 · 10 منٹ پڑھیں

6 حصے

### [MCP سرور کیا ہے? 2026 میں MCP اور MCP UI کیسے کام کرتے ہیں](https://tajo.io/ur/blog/what-is-an-mcp-server/)

3 اکتوبر، 2026 · 18 منٹ پڑھیں

قدم 1 → قدم 6