What can you do with this server?

This Sutta MCP server connects to SuttaCentral to enable AI-assisted exploration of Buddhist scriptures with cited canonical sources. It provides tools to: * search_topic: find suttas by topic (e.g., "mindfulness", "vô ngã", "four noble truths") in English or Vietnamese, returning sutta UIDs with metadata. * get_sutta: retrieve full sutta text by UID (e.g., mn10, sn56.11), with translator and segment limit options. * get_sutta_meta: get metadata for a sutta, including name, blurb, difficulty, number of parallels, available translations, and links. * get_parallels: list parallel texts across traditions (Pali, Chinese, Sanskrit) for comparative study. * list_divisions: list canonical divisions/collections, optionally filtered by pitaka (Sutta, Vinaya, or Abhidhamma).

How do I use Sutta MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Sutta MCP What does the Buddha teach about not-self? Cite suttas." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Sutta MCP

by nbkhoi

Overview Schema Related Servers Score Discussions

JavaScript

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_topic`	Tìm sutta theo chủ đề (vô ngã, chánh niệm, tứ diệu đế...)
`get_sutta`	Lấy toàn văn sutta theo UID
`get_sutta_meta`	Metadata: tên, blurb, độ khó, danh sách bản dịch
`get_parallels`	Parallels giữa các truyền thống (Pali, Hán tạng, Sanskrit)
`list_divisions`	Liệt kê các bộ kinh, lọc theo tạng (sutta/vinaya/abhidhamma)

Related MCP server: Strava MCP Server

Cài đặt

git clone <repo>
cd suttacentral-mcp
npm install
npm run build

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/suttacentral-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ể.

Chủ đề có sẵn

Tiếng Anh: mindfulness, four noble truths, eightfold path, not-self, impermanence, loving-kindness, dependent origination, aggregates, nibbana, kamma, jhana, triple gem

Tiếng Việt: chánh niệm, tứ diệu đế, bát chánh đạo, vô ngã, vô thường, từ bi, duyên khởi, ngũ uẩn, niết bàn, nghiệp, thiền, quy y

Mở rộng

Để thêm chủ đề mới, chỉnh TOPIC_INDEX trong src/index.ts. Đây là prototype — bước tiếp theo là tích hợp Elasticsearch của SuttaCentral để search thực sự.

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, không cache hay train.

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...).

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	UID 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.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	UID của sutta, ví dụ: 'mn10', 'sn56.11', 'dn22'
`translator`	No	ID dịch giả: 'sujato' (mặc định, tiếng Anh), 'brahmali' (Vinaya)	sujato
`max_segments`	No	Giớ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.

ParametersJSON Schema

Name	Required	Description	Default
`uid`	Yes	UID của sutta, ví dụ: 'mn10', 'dn1'
`language`	No	Ngôn ngữ cho blurb và tiêu đề dịch	en

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.

ParametersJSON Schema

Name	Required	Description	Default
`pitaka`	No	Lọ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.

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes	Chủ đề cần tìm, ví dụ: 'mindfulness', 'vô ngã', 'four noble truths', 'từ bi'
`language`	No	Ngô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. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jul 31, 2026
- First observedget_parallels
- First observedget_sutta
- First observedget_sutta_meta
- First observedlist_divisions
- First observedsearch_topic

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

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

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

fojin — Buddhist Canon Tools A
app.fojin
Buddhist canon tools: search, passages, cross-canon parallels, dictionaries — all URN-cited.
Art & Culture Search Research & Data
81327
torah-mcp A
io.github.JonathanB555
Source discipline for Torah study in Claude: read the real texts, quote exactly, never fabricate
Education & Learning Tools Search
1611
Fathom MCP ServerOAuth
io.github.agencyenterprise
Connect Claude to Fathom meeting recordings, transcripts, and summaries
Communication App Automation Search
216
STAS Running Coach for Claude A
run.stas
Connect Claude to your Intervals.icu watch data for fitness, workout review, and plan writing.
Fitness Tracking Health & Wellness Education & Learning Tools
212

Related MCP Servers

Anki MCP Server
Education & Learning Tools Developer Tools
captain-blue210
A
license
B
quality
D
maintenance
Connects Claude Desktop to Anki, allowing retrieval and analysis of leech-tagged cards and adding review tags through natural language requests.
Updated a year ago (2025-04-13 14:20 UTC)
2
153
MIT
Strava MCP Server
Fitness Tracking Sports
dtrain473
A
license
Not graded
quality
C
maintenance
Connects Claude to Strava data for natural language queries about rides, stats, and activities.
Updated 4 months ago (2026-05-17 04:02 UTC)
25
MIT
OmniContext
Note Taking Search Entertainment & Media
h4sht
A
license
A
quality
B
maintenance
Connects Claude Desktop to Notion and YouTube transcripts with one-click installation, enabling natural language queries about your pages and video content.
Updated 2 months ago (2026-07-12 19:44 UTC)
5
2
MIT
kjv-bible-mcp-server
Art & Culture Open Data
saficky98
F
license
Not graded
quality
C
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.
Updated 2 months ago (2026-07-20 21:46 UTC)
-

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/nbkhoi/sutta-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server