લૉગ ઇનમફત નોંધણી

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 પુનરાવર્તન નોંધે છે અને તેના કાર્ડનું શેડ્યૂલ આગળ વધારે છે.

આખું સ્ટૅક — ઍપ, બૅકએન્ડ અને ઇન્ફ્રાસ્ટ્રક્ચર — ઓપન સોર્સ છે અને જાતે હોસ્ટ કરી શકાય છે, તેથી તમે આ જ કનેક્ટર તમારા પોતાના ડિપ્લોયમેન્ટ સાથે વાપરી શકો છો.