Skip to main content
Glama
Sign In
Sutta MCP

Sutta MCP

by nbkhoi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Sutta MCP

Node.js TypeScript MCP SDK

MCP server kết nối Claude với SuttaCentral — giúp trả lời câu hỏi Phật pháp có trích dẫn nguồn kinh điển.

Tools

Tool

Mô tả

search_instant

Wrapper mỏng của search SuttaCentral (GET /api/search/instant): tham số API query, language, limit, offset, selectedLanguages, restrict, matchpartial được gửi nguyên, tham số không truyền thì không gửi; format chọn text (mặc định: mọi kết quả theo thứ tự SC, kèm link) hoặc json (body response nguyên văn)

get_bilarasuttas

Văn bản segmented của một sutta (GET /api/bilarasuttas/{uid}/{author_uid}?lang=): tham số API uid, author_uid (bỏ trống thì chỉ có văn bản gốc), lang (bản dịch không phải tiếng Anh cần lang của bản dịch); mọi map (root_text, translation_text, comment_text, …) và keys_order, key là segment ID, không cắt; format text (mặc định) hoặc json

get_suttaplex

Metadata (GET /api/suttaplex/{uid}?language=): tham số API uid, language; nguyên mảng suttaplex, gồm mọi bản dịch trong translations; format text (mặc định) hoặc json

get_parallels

Parallels giữa các truyền thống (GET /api/parallels/{uid}?language=): tham số API uid, language; parallels theo anchor của sutta nguồn; format text (mặc định) hoặc json

get_menu

Cây duyệt của SuttaCentral (GET /api/menu, GET /api/menu/{submenu_id}, ?language=): tham số API submenu_id, language; mỗi lời gọi trả một cấp con; format text (mặc định) hoặc json

Related MCP server: Strava MCP Server

Cài đặt

git clone https://github.com/nbkhoi/sutta-mcp.git
cd sutta-mcp
npm install
npm run build
# Chạy unit test offline (không cần mạng):
npm test

Chạy thử (dev mode)

npm run dev

Tích hợp vào Claude.ai (Claude Desktop)

Thêm vào file config của Claude Desktop:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "suttacentral": {
      "command": "node",
      "args": ["/đường/dẫn/tuyệt/đối/sutta-mcp/dist/index.js"]
    }
  }
}

Sau đó restart Claude Desktop. MCP sẽ xuất hiện trong danh sách tools.

Ví dụ sử dụng

Khi đã kết nối, bạn có thể hỏi Claude:

"Đức Phật dạy gì về vô ngã? Hãy trích dẫn kinh điển."

"Tìm cho tôi các sutta về chánh niệm và giải thích tóm tắt."

"MN 10 có parallels trong Hán tạng không?"

Claude sẽ tự động gọi MCP tools, tra cứu SuttaCentral, rồi trả lời có nguồn cụ thể.

Tìm bằng tiếng Việt

search_instant gửi truy vấn nguyên văn tới search của SuttaCentral, không ánh xạ hay dịch. Để khớp tiêu đề tiếng Việt, truyền language = vi, ví dụ {"query": "vô ngã", "language": "vi"}. Để có cả bản dịch tiếng Việt trong phần khớp nội dung (hits), thêm selectedLanguages có vi, ví dụ {"query": "vô ngã", "language": "vi", "selectedLanguages": ["vi", "pli"]}. Khi bỏ trống selectedLanguages, SuttaCentral dùng mặc định ["en", "pli"]. Để lấy toàn văn bản dịch tiếng Việt, dùng get_bilarasuttas với author_uid của bản dịch và lang = vi, ví dụ {"uid": "dhp1-20", "author_uid": "phantuananh", "lang": "vi"}.

Lưu ý

SuttaCentral yêu cầu content của họ không được dùng để train AI. MCP này chỉ fetch dữ liệu theo thời gian thực để trả lời người dùng và không train. Hiện chưa có cache; nếu thêm (roadmap mục 6), cache chỉ là bản sao tạm thời, có giới hạn, không tích lũy thành bộ dữ liệu.

Tài liệu thiết kế

Giấy phép

Sutta MCP phát hành theo PolyForm Noncommercial 1.0.0. Bạn được dùng, sửa và chia sẻ tự do cho mọi mục đích phi thương mại — tu học cá nhân, thực hành tôn giáo, nghiên cứu, chùa và tổ chức từ thiện, trường học, cơ quan nhà nước. Không được bán hoặc dùng cho mục đích thương mại. Đây là giấy phép source-available, không phải open source theo định nghĩa của OSI.

Tác giả không bán dự án này. Theo tinh thần SuttaCentral cho đi kinh điển miễn phí, Sutta MCP cũng được cho đi như một pháp thí.

Giấy phép chỉ áp dụng cho code của Sutta MCP. Nội dung kinh do SuttaCentral cung cấp theo điều khoản riêng của SuttaCentral.

Available Tools

5 tools
get_parallelsA

Lấy danh sách parallels của một sutta — các kinh tương đương trong các truyền thống khác (Hán tạng, Sanskrit...).

NameRequiredDescriptionDefault
uidYesUID của sutta gốc, ví dụ: 'mn10'

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It implies a read-only operation ('get list') and adds helpful context about what parallels are, but it does not disclose any other behavioral traits such as return format, pagination, or potential variations in data sources.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence that explains both the action and the domain concept. No filler words; every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter, no output schema), and the description sufficiently explains its purpose and the meaning of parallels. It lacks explicit notes on behavior or edge cases, but given the low complexity, the description is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage for the single parameter 'uid' with a clear description and example. The description does not add parameter-specific details, but since schema coverage is high, the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: retrieving a list of parallels for a sutta, and further explains what parallels are (equivalent texts in other traditions). This specific verb+resource combination distinguishes it from siblings like get_sutta or get_sutta_meta.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use this tool (when you need parallel texts for a sutta), but it does not explicitly mention alternatives or exclusions. It would be stronger if it contrasted with get_sutta for the original text or get_sutta_meta for metadata.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_suttaA

Lấy toàn văn một sutta theo UID. Dùng sau khi đã tìm được UID từ search_topic hoặc biết trước.

NameRequiredDescriptionDefault
uidYesUID của sutta, ví dụ: 'mn10', 'sn56.11', 'dn22'
translatorNoID dịch giả: 'sujato' (mặc định, tiếng Anh), 'brahmali' (Vinaya)sujato
max_segmentsNoGiới hạn số đoạn văn trả về, tránh quá dài. Mặc định 50.

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action (get full text) and does not reveal side effects, return format, or any caveats like segment limits or read-only nature beyond what the schema already indicates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences, front-loaded with the main action, with no unnecessary words. It is exemplary in conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Though the tool is simple and the schema is rich, the absence of annotations and output schema means the description should have elaborated on the response structure or limiting behavior. It is adequate but minimal.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond reiterating that UID is the key; all useful parameter details (e.g., examples, defaults) are already present in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves the full text of a sutta by UID, using a specific verb and resource ('Lấy toàn văn một sutta theo UID'). It distinguishes from siblings by emphasizing it operates on a known UID and pairs with search_topic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this tool after finding the UID via search_topic or when it is already known, providing clear contextual guidance. It does not enumerate when-not scenarios, but the primary usage context is well-established.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_sutta_metaA

Lấy metadata của một sutta: tên, blurb, độ khó, số parallels, danh sách bản dịch có sẵn, link.

NameRequiredDescriptionDefault
uidYesUID của sutta, ví dụ: 'mn10', 'dn1'
languageNoNgôn ngữ cho blurb và tiêu đề dịchen

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It lists the return fields (metadata contents), which is some behavioral disclosure, but it does not explicitly mention read-only nature, error behavior, or limitations. The verb 'get' implies non-mutating but lacks explicit detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence with a colon and comma-separated list of fields, front-loaded with the verb. No filler, every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given only 2 simple parameters, no output schema, and no annotations, the description adequately lists the primary return fields. However, it omits details like field formats, default language behavior, or how this relates to sibling tools, leaving minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%: both parameters have descriptions (uid example, language for blurb/title). The description does not add semantic value beyond what the schema already provides, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Lấy' (get) with a resource 'metadata của một sutta' and enumerates the exact metadata fields returned (name, blurb, difficulty, parallels count, translations, link). This clearly distinguishes it from sibling tools like get_sutta (full text) and get_parallels (parallels only).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when metadata is needed) but provides no explicit alternatives or conditions like 'use get_sutta for full text'. Guidance is intuitive from the name and list, but not directly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_divisionsA

Liệt kê các divisions (bộ kinh) trên SuttaCentral, có thể lọc theo pitaka (tạng). Dữ liệu hardcode, không gọi API.

NameRequiredDescriptionDefault
pitakaNoLọc theo tạng. Bỏ trống → trả về tất cả.

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It does disclose a key behavioral trait: 'Dữ liệu hardcode, không gọi API' (hardcoded data, no API call), indicating static results and no network dependency. It also mentions the optional filter. However, it does not describe the output format, error handling, or any limitations beyond the hardcoded nature, leaving some gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exactly two sentences, front-loaded with the main action and a useful behavioral note. It contains no redundant phrases, filler, or unnecessary details, making it highly concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional enum parameter, no output schema, and good schema coverage, the description covers the core aspects: purpose, filtering, and data source. It does not explicitly describe the return format, but the tool's name and purpose strongly suggest a list of division names. This is adequate for the tool's low complexity, though a brief note on the response shape would make it fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage of the sole parameter 'pitaka', including enum values and the default behavior when omitted ('Bỏ trống → trả về tất cả'). The description's mention of filtering by pitaka adds little beyond the schema. The high schema coverage sets a baseline of 3, and no significant additional meaning is added by the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Liệt kê các divisions' (list the divisions), using a specific verb and resource. It specifies the domain 'trên SuttaCentral' (on SuttaCentral), which distinguishes it from other listing tools. Though it doesn't explicitly contrast with siblings, the purpose is unambiguous and accurate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage: use this tool to list divisions, optionally filtered by pitaka. It does not explicitly mention when not to use it or compare with siblings like search_topic or get_sutta. There are no exclusions or alternative recommendations, so guidance is implied but not fully developed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_topicA

Tìm kiếm các sutta liên quan đến một chủ đề Phật pháp. Trả về danh sách UID kèm metadata.

NameRequiredDescriptionDefault
topicYesChủ đề cần tìm, ví dụ: 'mindfulness', 'vô ngã', 'four noble truths', 'từ bi'
languageNoNgôn ngữ cho blurb: 'en' hoặc 'vi'en

TDQS

A3.5/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden for behavioral disclosure. It only says 'returns list of UIDs with metadata' and gives no information on search scope, pagination, sorting, permissions, or side effects. This is a significant gap for a tool that likely is read-only but is not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence that is direct and front-loaded with the key action ('Tìm kiếm') and outcome. Every word contributes to the meaning, and no unnecessary detail is included.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the basic purpose and output, and the schema fully documents parameters, so it is minimally complete. However, there is no output schema and the description leaves 'metadata' undefined, plus no mention of search behavior or limits, making it incomplete for a full understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description does not add meaningful detail beyond the schema. Both 'topic' and 'language' are already described in the input schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches for suttas related to a Buddhist topic and returns UID list with metadata. This specific verb-resource-output combination distinguishes it from sibling tools like get_sutta or get_parallels.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing to find suttas by topic, but it does not explicitly state when to prefer this over siblings or any exclusions. No alternatives are mentioned, so guidance is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedget_parallels
    • First observedget_sutta
    • First observedget_sutta_meta
    • First observedlist_divisions
    • First observedsearch_topic
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool serves a distinct function: searching by topic, retrieving full text, fetching metadata, getting parallels, and listing divisions. There is no overlap in purpose, and descriptions make it easy to select the right tool.

Naming Consistency5/5

All tools follow a clear verb_noun pattern: search_topic, get_sutta, get_sutta_meta, get_parallels, list_divisions. The convention is consistent across the set.

Tool Count5/5

With 5 tools covering search, retrieval, metadata, parallels, and divisions, the set is well-scoped for a SuttaCentral access server. Each tool serves a clear need within the domain.

Completeness4/5

The core workflows (search, read, metadata, parallels, divisions) are covered. A minor gap is the lack of a direct way to list suttas within a division, but search_topic can compensate, so no major dead ends.

Maintenance

ActivityMaintained
ResponsivenessSlow

Resources

Related MCP Connectors

Related MCP Servers

  • kjv-bible-mcp-server

    saficky98
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables Claude.ai to access and retrieve Bible verses, passages, chapters, and lists of books or translations from public domain versions like KJV, using the free bible-api.com.
    MIT

  • jw-mcp

    teenfo
    A
    license
    A
    quality
    D
    maintenance
    Enables Claude to access JW.org public materials including Bible verses, Watchtower articles, meeting workbooks, video captions, and lesson books through natural language conversation.
    11
    53 npm
    MIT