# MCP कनेक्टर

## Claude डिरेक्टरीमधून जोडा

[Claude डिरेक्टरीमधील Nibomo](https://claude.ai/directory/nibomo) उघडा, ते जोडा, तुमच्या Nibomo खात्यात साइन इन करा आणि प्रवेशाला परवानगी द्या. Nibomo हे Community कनेक्टर म्हणून सूचीबद्ध आहे.

Claude Code साठी तेच Claude सबस्क्रिप्शन खाते वापरा आणि जोडल्यानंतर `/mcp` तपासा. API की किंवा तृतीय पक्ष प्रोव्हायडरद्वारे केलेल्या लॉगिनमध्ये तुमचे claude.ai कनेक्टर आपोआप लोड होत नाहीत.

तुम्ही Claude Code थेट कॉन्फिगरही करू शकता. खालील कमांड चालवा, मग Claude Code मध्ये `/mcp` उघडा आणि ब्राउझरमधील परवानगीची प्रक्रिया पूर्ण करा:

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

[Claude Code MCP दस्तऐवजीकरण](https://code.claude.com/docs/en/mcp#use-mcp-servers-from-claudeai).

## आढावा

Nibomo एक रिमोट MCP (Model Context Protocol) सर्व्हर चालवते, ज्यामुळे MCP क्लायंट आणि AI एजंट तुमची बाकी असलेली कार्डे वाचू शकतात, तुमच्यासोबत एका वेळी एक प्रश्न विचारून त्यांची उजळणी करू शकतात आणि तुमच्यासाठी कार्डे व डेक तयार किंवा संपादित करू शकतात.

एजंट दोन प्रकारे जोडता येतात: या MCP सर्व्हरद्वारे (Claude किंवा Cursor सारख्या MCP क्लायंटसाठी सर्वोत्तम), किंवा CLI एजंटसाठी [Agents API डिस्कव्हरी URL](/mr/docs/api/) द्वारे. दोन्ही मार्ग प्रत्येक वापरकर्त्याच्या त्याच डेटा इंटरफेसपर्यंत पोहोचतात; हे पान MCP सर्व्हरविषयी आहे.

या पत्त्यावर जोडा:

```text
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 संदर्भ](/mr/docs/api/) मध्ये सांगितलेल्या ईमेल OTP लॉगिन प्रक्रियेद्वारे दीर्घकाळ वैध राहणारी `fca_` एजंट API की मिळवा, मग ती Bearer टोकन म्हणून पाठवा:

```text
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` उजळणी नोंदवते आणि तिच्या कार्डाचे वेळापत्रक पुढे सरकवते.

संपूर्ण स्टॅक, म्हणजे ॲप, बॅकएंड आणि पायाभूत सुविधा, ओपन सोर्स आहे आणि [स्वतः होस्ट](/mr/docs/self-hosting/) करता येतो, त्यामुळे तुम्ही हाच कनेक्टर तुमच्या स्वतःच्या डिप्लॉयमेंटवर चालवू शकता.

---
*[या पानाची शैलीबद्ध HTML आवृत्ती पाहा](<https://nibomo.com/mr/docs/mcp-connector/>)*

*AI एजंट `GET https://api.nibomo.com/v1/` ने सुरुवात करून या सेवेत वापरकर्त्याचे खाते तयार करू शकतात. सेटअपनंतर ते `https://mcp.nibomo.com/mcp` वर MCP द्वारेही जोडू शकतात.*

*टीप: https://nibomo.com वरील कोणत्याही URL च्या शेवटी `.md` जोडा, म्हणजे त्या पानाची स्वच्छ Markdown आवृत्ती मिळेल.*