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
आढावा
Nibomo एक रिमोट MCP (Model Context Protocol) सर्व्हर चालवते, ज्यामुळे MCP क्लायंट आणि AI एजंट तुमची बाकी असलेली कार्डे वाचू शकतात, तुमच्यासोबत एका वेळी एक प्रश्न विचारून त्यांची उजळणी करू शकतात आणि तुमच्यासाठी कार्डे व डेक तयार किंवा संपादित करू शकतात.
एजंट दोन प्रकारे जोडता येतात: या MCP सर्व्हरद्वारे (Claude किंवा Cursor सारख्या MCP क्लायंटसाठी सर्वोत्तम), किंवा CLI एजंटसाठी Agents API डिस्कव्हरी URL द्वारे. दोन्ही मार्ग प्रत्येक वापरकर्त्याच्या त्याच डेटा इंटरफेसपर्यंत पोहोचतात; हे पान MCP सर्व्हरविषयी आहे.
या पत्त्यावर जोडा:
https://mcp.nibomo.com/mcp
ट्रान्सपोर्ट Streamable HTTP आहे. सर्व्हर कार्यक्षेत्र शोधणे, कार्डे व डेक वाचणे आणि लिहिणे, संदर्भ मार्गदर्शक, उजळण्या आणि खात्याचा वापर यांसाठी आठ साधने देतो.
तुमच्या क्लायंटमध्ये कसे जोडावे
बहुतेक क्लायंट रिमोट MCP सर्व्हर कस्टम कनेक्टर म्हणून जोडतात:
- तुमच्या क्लायंटच्या कनेक्टर किंवा MCP सर्व्हर सेटिंग्ज उघडा.
- कस्टम कनेक्टर जोडा आणि सर्व्हर URL
https://mcp.nibomo.com/mcpपेस्ट करा. - इंटरॅक्टिव्ह क्लायंटमध्ये विचारले जाईल तेव्हा ब्राउझरमध्ये परवानगी द्या. सर्व्हर Dynamic Client Registration सह OAuth 2.1 वापरतो, त्यामुळे पेस्ट करण्यासाठी कोणतेही क्लायंट सीक्रेट नसते आणि आधी कोणतेही ॲप नोंदवावे लागत नाही.
- हेडलेस किंवा 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 वेळापत्रकात जतन करू शकतो:
next_review_cardहेcardIdआणिfrontTextपरत करते, किंवा काहीही बाकी नसेल तेव्हाcard: null.- शिकणाऱ्याने उत्तर दिल्यानंतर
reveal_answerत्या कार्डाचाbackTextपरत करते. submit_reviewहेcardId, क्लायंटने तयार केलेलाreviewIdUUID,ratingआणि शिकणाऱ्याचा IANAreviewedTimeZoneघेते. सर्व्हर उजळणीची वेळ नोंदवतो आणि कार्डाचे नवे वेळापत्रक परत करतो.
सबमिशन झाले की नाही याची खात्री नसेल, तर त्याच 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उजळणी नोंदवते आणि तिच्या कार्डाचे वेळापत्रक पुढे सरकवते.
संपूर्ण स्टॅक, म्हणजे ॲप, बॅकएंड आणि पायाभूत सुविधा, ओपन सोर्स आहे आणि स्वतः होस्ट करता येतो, त्यामुळे तुम्ही हाच कनेक्टर तुमच्या स्वतःच्या डिप्लॉयमेंटवर चालवू शकता.