MCP কানেক্টর

Claude ডিরেক্টরি থেকে যুক্ত করুন

Claude ডিরেক্টরিতে Nibomo খুলুন, সেটি যুক্ত করুন, নিজের Nibomo অ্যাকাউন্টে সাইন ইন করুন আর প্রবেশাধিকারের অনুমতি দিন। Nibomo সেখানে একটি Community কানেক্টর হিসেবে তালিকাভুক্ত।

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 সহ authorization-code ফ্লো বাস্তবায়ন করে। 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 একটি পুনরালোচনা রেকর্ড করে এবং সেই কার্ডের শিডিউল এগিয়ে নেয়।

পুরো স্ট্যাক — অ্যাপ, ব্যাকএন্ড আর ইনফ্রাস্ট্রাকচার — ওপেন সোর্স এবং সেলফ-হোস্ট করা যায়, তাই নিজের ডিপ্লয়মেন্টের সঙ্গেও একই কানেক্টর চালাতে পারেন।