MCP کنیکٹر

Claude ڈائریکٹری کے ذریعے جوڑیں

Claude ڈائریکٹری میں Nibomo کھولیں، اسے جوڑیں، اپنے Nibomo اکاؤنٹ میں سائن اِن کریں اور رسائی کی اجازت دیں۔ Nibomo ایک کمیونٹی کنیکٹر کے طور پر درج ہے۔

Claude Code کے لیے وہی Claude سبسکرپشن اکاؤنٹ استعمال کریں اور جوڑنے کے بعد /mcp چیک کریں۔ API کلید اور فریق ثالث فراہم کنندہ کے ذریعے لاگ اِن آپ کے claude.ai کنیکٹرز خود بخود لوڈ نہیں کرتے۔

آپ Claude Code کو براہ راست بھی کنفیگر کر سکتے ہیں۔ نیچے دی گئی کمانڈ چلائیں، پھر Claude Code میں /mcp کھولیں اور براؤزر میں اجازت کا عمل مکمل کریں:

claude mcp add --transport http nibomo https://mcp.nibomo.com/mcp

Claude Code MCP کی دستاویزات۔

جائزہ

Nibomo ایک ریموٹ MCP (Model Context Protocol) سرور چلاتا ہے تاکہ MCP کلائنٹس اور AI ایجنٹس آپ کے وہ کارڈز پڑھ سکیں جن کی دہرائی باقی ہے، ایک ایک سوال کر کے آپ کے ساتھ ان کی دہرائی کر سکیں، اور آپ کے لیے کارڈز اور ڈیکس بنا یا ان میں ترمیم کر سکیں۔

ایجنٹس دو طریقوں سے جڑ سکتے ہیں: اس MCP سرور کے ذریعے (Claude یا Cursor جیسے MCP کلائنٹس کے لیے بہترین)، یا CLI ایجنٹس کے لیے Agents API ڈسکوری URL کے ذریعے۔ دونوں ایک ہی فی صارف ڈیٹا سطح تک پہنچتے ہیں؛ یہ صفحہ MCP سرور کے بارے میں ہے۔

اس سے اس پتے پر جڑیں:

https://mcp.nibomo.com/mcp

ٹرانسپورٹ Streamable HTTP ہے۔ سرور ورک اسپیس کی دریافت، کارڈز اور ڈیکس کو پڑھنے اور لکھنے، حوالہ جاتی رہنماؤں، دہرائیوں اور اکاؤنٹ کے استعمال کے لیے آٹھ ٹولز فراہم کرتا ہے۔

اسے اپنے کلائنٹ میں کیسے شامل کریں

زیادہ تر کلائنٹس ریموٹ MCP سرور کو کسٹم کنیکٹر کے طور پر شامل کرتے ہیں:

1. اپنے کلائنٹ کی کنیکٹر یا MCP سرور کی ترتیبات کھولیں۔
2. کسٹم کنیکٹر شامل کریں اور سرور URL https://mcp.nibomo.com/mcp پیسٹ کریں۔
3. انٹرایکٹو کلائنٹس میں، پوچھے جانے پر براؤزر میں اجازت دیں۔ سرور Dynamic Client Registration کے ساتھ OAuth 2.1 استعمال کرتا ہے، اس لیے نہ کوئی کلائنٹ سیکرٹ پیسٹ کرنا ہوتا ہے اور نہ پہلے کوئی ایپ رجسٹر کرنی ہوتی ہے۔
4. ہیڈلیس یا CLI استعمال کے لیے براؤزر فلو کے بجائے اپنی ایجنٹ API کلید کے ساتھ Authorization: Bearer fca_… ہیڈر سیٹ کریں۔

اجازت دینے کے بعد ورک اسپیس منتخب کرنے کے لیے ایک بار list_workspaces کال کریں، پھر پڑھنے کے لیے sql_query اور کارڈز اور ڈیکس میں لکھنے کے لیے sql_execute استعمال کریں۔ دہرائی کے لیے پہلے next_review_card، پھر reveal_answer، پھر submit_review کال کریں۔

ٹولز

سرور آٹھ ٹولز فراہم کرتا ہے۔ پڑھنے اور لکھنے کو جان بوجھ کر الگ رکھا گیا ہے تاکہ کوئی ایک ٹول محفوظ اور تباہ کن آپریشنز کو کبھی نہ ملائے۔

• get_usage_limits — اکاؤنٹ کا پلان، حدود اور موجودہ ماہانہ AI استعمال، سختی سے صرف پڑھنے کے لیے؛ یہ کارڈز کو نہ پڑھتا ہے نہ بدلتا ہے۔
• sql_query — آپ کے کارڈز اور ڈیکس تک سختی سے صرف پڑھنے کی رسائی (SHOW TABLES، DESCRIBE، SHOW COLUMNS، SELECT)۔
• sql_execute — آپ کے کارڈز اور ڈیکس تک لکھنے کی رسائی (INSERT، UPDATE، DELETE) ایک ایٹامک بیچ کے طور پر۔
• list_workspaces — ان ورک اسپیسز کی سختی سے صرف پڑھنے والی فہرست جن تک آپ کی رسائی ہے، ہر ایک کے ساتھ اس کا workspaceId، نام، فعال کارڈز کی تعداد، آخری سرگرمی، اور یہ کہ آیا وہ اس وقت آپ کا منتخب طے شدہ ورک اسپیس ہے۔ SQL اور دہرائی کے ٹولز کے اختیاری workspaceId آرگیومنٹ کے لیے لوٹایا گیا workspaceId استعمال کریں۔
• get_guide — ایک موضوع کے لیے سختی سے صرف پڑھنے والا حوالہ جاتی رہنما: sql_dialect، card_authoring، bulk_authoring یا review_flow۔ یہ ورک اسپیس کا کوئی ڈیٹا نہیں پڑھتا۔
• next_review_card — سختی سے صرف پڑھنے کے لیے: دہرائی کے لیے اگلا کارڈ لوٹاتا ہے، صرف سامنے والا رخ، اسی قطار کی ترتیب میں جو ایپس میں ہے۔ اختیاری tags یا deckId قطار کو محدود کرتا ہے۔
• reveal_answer — سختی سے صرف پڑھنے کے لیے: سیکھنے والے کے سامنے والے رخ کا جواب دینے کی کوشش کے بعد ایک کارڈ کا پچھلا رخ لوٹاتا ہے۔
• submit_review — ایک Again، Hard، Good یا Easy درجہ بندی درج کرتا ہے اور کارڈ کے FSRS شیڈیول کو آگے بڑھاتا ہے۔

SQL سطح جان بوجھ کر محدود ڈائلیکٹ ہے اور مکمل PostgreSQL نہیں ہے۔ یہ دستاویزات صرف تعاون یافتہ ڈائلیکٹ کا احاطہ کرتی ہیں، PostgreSQL مطابقت کا حوالہ نہیں ہیں۔ بیانات صرف workspace، cards، decks اور review_events وسائل تک پہنچ سکتے ہیں، ہر بیان آپ کے اپنے ورک اسپیس تک محدود ہوتا ہے، اور پڑھنے اور لکھنے دونوں کی حد فی بیان 100 قطاریں ہے۔

دہرائیاں

دہرائی کے ٹولز ایجنٹ کو سیکھنے والے سے ایک وقت میں ایک کارڈ پوچھنے اور ہر درجہ بندی کو کارڈ کے FSRS شیڈیول میں محفوظ کرنے دیتے ہیں:

1. next_review_card ایک cardId اور frontText لوٹاتا ہے، یا جب کسی کارڈ کی دہرائی باقی نہ ہو تو card: null۔
2. سیکھنے والے کے جواب دینے کے بعد reveal_answer اس کارڈ کا backText لوٹاتا ہے۔
3. submit_review میں cardId، کلائنٹ کا بنایا ہوا reviewId UUID، ایک rating اور سیکھنے والے کا IANA reviewedTimeZone دیا جاتا ہے۔ سرور دہرائی کا وقت درج کرتا ہے اور کارڈ کا نیا شیڈیول لوٹاتا ہے۔

اگر جمع ہونے کے بارے میں یقین نہ ہو تو اسی reviewId کے ساتھ دوبارہ بھیجیں؛ اس سے کبھی دوسری دہرائی درج نہیں ہوتی۔ جمع کرانے پر یہ جوابات بھی مل سکتے ہیں:

• 409 REVIEW_EVENT_CONFLICT — دہرائی پہلے ہی درج ہو چکی ہے، اور غلطی کی تفصیلات میں کارڈ کا موجودہ شیڈیول ہوتا ہے۔
• 409 REVIEW_ID_CARD_MISMATCH — یہ reviewId پہلے ہی کسی دوسرے کارڈ کی دہرائی کی شناخت ہے، اس لیے کچھ محفوظ نہیں ہوا؛ نئے reviewId کے ساتھ دوبارہ جمع کریں۔
• 409 REVIEW_STALE — کارڈ کا محفوظ شدہ دہرائی کا وقت سرور کے موجودہ وقت کے برابر یا اس کے بعد کا ہے؛ کسی اور کارڈ کی دہرائی کریں۔

دہرائیاں صرف submit_review کے ذریعے درج ہوتی ہیں: SQL نہ review_events لکھ سکتا ہے اور نہ FSRS شیڈیولنگ کی حالت۔ دہرائی اور درجہ بندی کے مکمل قواعد کے لیے موضوع review_flow کے ساتھ get_guide کال کریں۔

کارڈ کا معاہدہ

ہر کارڈ ایک ہی معاہدے کی پیروی کرتا ہے، اور ٹولز اسی پر انحصار کرتے ہیں:

• front_text صرف سوال یا دہرائی کا اشارہ ہوتا ہے اور اس میں جواب کبھی نہیں ہوتا۔
• back_text میں جواب ہوتا ہے، اختیاری طور پر کسی ٹھوس مثال کے ساتھ۔

جو ایجنٹس sql_execute کے ذریعے کارڈز بناتے ہیں وہ اسی معاہدے کی پیروی کرتے ہیں، اس لیے ان کے بنائے ہوئے کارڈز کی وقفہ وار دہرائی فوراً کی جا سکتی ہے۔

تصدیق

اجازت کے دو راستے ایک ہی فی صارف ڈیٹا سطح تک پہنچتے ہیں۔

OAuth 2.1 (انٹرایکٹو کنیکٹر کلائنٹس)

سرور PKCE اور Dynamic Client Registration کے ساتھ اجازتی کوڈ والا فلو نافذ کرتا ہے۔ MCP URL کو کسٹم کنیکٹر کے طور پر شامل کریں اور براؤزر میں اجازت دیں؛ کوئی کلائنٹ سیکرٹ پہلے سے شیئر نہیں کیا جاتا۔ دریافت معیاری ہے:

• تحفظ یافتہ وسیلے کا میٹا ڈیٹا: https://mcp.nibomo.com/.well-known/oauth-protected-resource
• اجازت دینے والے سرور کا میٹا ڈیٹا: https://auth.flashcards-open-source-app.com/.well-known/oauth-authorization-server

API کلید (ہیڈلیس اور CLI)

API حوالہ میں درج ای میل OTP لاگ اِن فلو کے ذریعے طویل مدتی fca_ ایجنٹ API کلید حاصل کریں، پھر اسے Bearer ٹوکن کے طور پر بھیجیں:

Authorization: Bearer fca_ABCDEFGH_0123456789ABCDEFGHJKMNPQRS

یہ وہی کلید ہے جو REST ایجنٹ سطح قبول کرتی ہے، اور اسے براؤزر یا OAuth کے کسی مرحلے کی ضرورت نہیں۔

دونوں راستوں کی باضابطہ، مشین کے پڑھنے کے قابل وضاحت https://api.nibomo.com/v1/ پر ڈسکوری پے لوڈ ہے (جس کی نقل /v1/agent پر بھی ہے)۔

حفاظت اور دائرہ کار

SQL ٹولز کو منظوری دینا محفوظ ہے کیونکہ یہ سطح ڈیٹا بیس تک من مانی رسائی نہیں بلکہ ایک محدود ڈائلیکٹ ہے جس کی پابندی پارسر کرواتا ہے:

• بیانات کی بند اجازت فہرست: sql_query صرف SHOW TABLES، DESCRIBE، SHOW COLUMNS اور SELECT قبول کرتا ہے؛ sql_execute صرف INSERT، UPDATE اور DELETE قبول کرتا ہے۔ اس کے علاوہ ہر چیز پارس کرتے وقت ہی مسترد ہو جاتی ہے۔
• محدود وسائل: بیانات صرف workspace، cards، decks اور review_events تک پہنچ سکتے ہیں۔
• فی ورک اسپیس دائرہ: ہر SQL بیان اور دہرائی ایک ایسے ورک اسپیس تک محدود ہوتی ہے جس تک آپ کی رسائی ہو، یعنی آپ کا دیا ہوا workspaceId یا آپ کا منتخب طے شدہ ورک اسپیس، اور کسی دوسرے ٹیننٹ تک کوئی رسائی نہیں ہوتی۔
• سخت آرگیومنٹس: ہر ٹول کسی نامعلوم آرگیومنٹ کو مسترد کر دیتا ہے، اس لیے غلط ہجے والا workspaceId آپ کے طے شدہ ورک اسپیس پر چلنے کے بجائے ناکام ہو جاتا ہے۔
• حدود: فی بیان زیادہ سے زیادہ 100 قطاریں، فی بیچ زیادہ سے زیادہ 50 بیانات، اور نتیجے کی حد تقریباً 12k ٹوکنز۔ تبدیلی کے بیچ ایٹامک طور پر لاگو ہوتے ہیں۔
• پڑھنے اور لکھنے کی تقسیم: get_usage_limits، sql_query، list_workspaces، get_guide، next_review_card اور reveal_answer سختی سے صرف پڑھنے کے لیے ہیں (readOnlyHint) اور کبھی ڈیٹا کی مرمت نہیں کرتے، شیڈیولنگ کا دوبارہ حساب نہیں لگاتے اور کارڈ کی حالت نہیں بدلتے۔ sql_execute اور submit_review واحد لکھنے والے ٹولز ہیں (destructiveHint): sql_execute کارڈز اور ڈیکس لکھتا ہے، اور submit_review دہرائی درج کرتا ہے اور اس کے کارڈ کا شیڈیول آگے بڑھاتا ہے۔

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