Tripitaka MCP (hosted)
Server Details
Search and cite the full Pāli Canon (Tipiṭaka, ~444K segments) — Sutta, Vinaya, Abhidhamma at parity with SuttaCentral. Hybrid search, full-sutta fetch, translation comparison, Pāli word lookup. Free, non-commercial, offered as Dhamma Dāna.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 10 of 10 tools scored.
Most tools have clearly distinct purposes, but the three search tools (search_by_keyword, search_hybrid, search_semantic) could confuse an agent as they overlap in functionality, though descriptions help differentiate them.
All tool names follow a consistent snake_case verb_noun pattern (e.g., get_sutta, list_editions, search_by_keyword), with clear groups for retrieval, listing, and search operations.
With 10 tools covering retrieval, search, reference, dictionary, morphological analysis, and structure, the count is well-scoped for a Pali Canon server—neither too few nor excessive.
The tool surface covers key use cases like sutta retrieval, search, comparison, citations, and word analysis. Minor gaps exist (e.g., no dedicated segment-level retrieval, no commentary lookup), but it's largely complete for typical reading/citation workflows.
Available Tools
10 toolscompare_translationsCompare TranslationsARead-onlyIdempotentInspect
Compare every available translation for a single segment.
💡 Use this tool when:
The user asks about the meaning/translation of a single Pāli line and wants to see multiple translators side-by-side.
Checking how different translators interpret the same line — technical terms like
dukkha,anattā,nibbānacarry nuance that varies across translations.Academic work that needs to quote multiple translations.
🔍 vs get_sutta: this tool targets a single segment (line
level); get_sutta returns the whole sutta. To compare a whole
sutta you'd call compare_translations for each segment.
📋 segment_id format: <sutta_id>:<paragraph>.<line>, e.g.
mn1:171.4 (Mūlapariyāyasutta paragraph 171 line 4 — "Nandī
dukkhassa mūlaṁ"). Find segment_ids via get_sutta or search results.
⚠️ Current state: the translation table is mostly empty (the DB
only loads default Pāli + English from bilara). total_editions is
usually 0; text_pali and text_english are always populated. Thai
editions will be added later.
| Name | Required | Description | Default |
|---|---|---|---|
| segment_id | Yes | Segment ID, e.g. "mn26:8.2", "dn22:17.1", "mn62:5.3". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits: the current state (translation table empty, only default Pali+English loaded, total_editions often 0, text_pali and text_english always available). This goes beyond any missing annotations and helps set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with emojis and clear sections (when to use, vs get_sutta, format, current state). It is front-loaded with the core purpose. While slightly long, every sentence adds value and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (true), the description appropriately focuses on usage context and limitations. It explains the tool's scope, parameter format, and current data state, providing sufficient completeness for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes segment_id with an example. The description adds value by explaining the format (<sutta_id>:<paragraph>.<line>) and noting that segment_id can be obtained from get_sutta or search results. This enhances comprehension beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'เปรียบเทียบคำแปลทุกฉบับที่มีสำหรับ segment เดียวกัน' (compare all translations for a single segment). It specifies the resource (segment) and distinguishes itself from the sibling tool get_sutta by targeting line-level rather than whole sutta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use scenarios (e.g., user asks meaning of a single line, checking translator differences, academic work) and contrasts with get_sutta. It also explains the format of the segment_id parameter and where to find it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_referenceGet CitationARead-onlyIdempotentInspect
Build a proper citation string for a sutta.
💡 Use this tool when:
The user wants a citation for academic work, an article, or a reference.
You need to know the canonical location of a sutta (pitaka / nikāya).
You want a ready-to-use formatted citation string.
🔗 vs get_sutta: this tool returns metadata + citation only, no
segments. Pair it with get_sutta when you want both the content
and the citation.
| Name | Required | Description | Default |
|---|---|---|---|
| sutta_id | Yes | Sutta ID, e.g. "mn1", "dn22", "sn56.11". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses that the tool returns only metadata and citation, implying read-only behavior. Does not mention potential side effects, but for a citation generator this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, well-structured with bullet points and emojis, no redundant sentences. Front-loads the primary purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema and simple input (one parameter). Description covers purpose, usage, and sibling comparison. Lacks error handling or prerequisite info but is generally complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of sutta_id including examples. Description does not add extra parameter meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States clearly that the tool creates correct citations for suttas. Distinguishes from sibling get_sutta by specifying it returns only metadata and citation, not segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly lists when to use (citation requests, need position in Tripitaka, need formatted citation) and contrasts with get_sutta for combined content+citation needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_suttaGet SuttaARead-onlyIdempotentInspect
Fetch the full content of a sutta/section by ID — returns every segment.
Uses standard SuttaCentral IDs, e.g.:
mn1= Majjhima Nikāya sutta 1 (Mūlapariyāyasutta, 334 segments)dn22= Dīgha Nikāya sutta 22 (Mahāsatipaṭṭhānasutta, 454 segments)dn16= Dīgha Nikāya sutta 16 (Mahāparinibbānasutta — the longest sutta in the canon, 1,664 segments)sn56.11= Saṃyutta 56.11 (Dhammacakkappavattana)mn62= Majjhima Nikāya 62 (Mahārāhulovāda — advice to Rāhula)dhp1-20= Dhammapada verses 1-20 (KN uses range format)mil3.1.1= Milindapañha 3.1.1 (paracanonical, 3–4 level id)
💡 Hints for the AI client:
Quote
text_pali/text_englishdirectly from the returned segments — do not rely on training memory. The system is verifiable; AI recall is often wrong.Short segments ending in
:0.1or:0.2are usually headers (nikāya/sutta names), not the teaching itself — actual content starts around:1.1.Segments ending in "...niṭṭhitaṁ" (e.g.
mn1:194.10= "Mūlapariyāyasuttaṁ niṭṭhitaṁ paṭhamaṁ") are colophons marking the close of the sutta.Segments containing
…pe…(peyyāla) are abbreviated repetitions — not missing data. Pāli texts use this convention for repeated stock phrases.The response includes a
cross_referencefield — render the URLs as clickable markdown in your reply so users can verify the source.
✅ Coverage (v1.1+): all three pitakas at parity with SuttaCentral
bilara-data:
Sutta Piṭaka (DN/MN/SN/AN/KN): Pāli + Sujato EN (5,791 sections)
Vinaya Piṭaka: Pāli + Brahmali EN — SC codes e.g.
pli-tv-bu-vb-pj1(Bhikkhu Pārājika 1),pli-tv-bi-vb-pj1(Bhikkhunī),pli-tv-kd1(Mahāvagga),pli-tv-pvr10(Parivāra),pli-tv-bu-pm(Bhikkhu Pātimokkha)Abhidhamma Piṭaka: 7 books (ds, vb, dt, pp, kv, ya, patthana) — Pāli only (bilara has no English translator for any Abhidhamma book)
| Name | Required | Description | Default |
|---|---|---|---|
| edition | No | Thai translation edition — "dhiranandi", "jayasaro", "mbu", "royal", or None. If None, uses `text_thai` from bilara-data. ⚠️ The DB has no Thai editions loaded yet, so most values return null. | |
| language | No | Which language to return — "pali", "thai", "english", or "all" (default: "pali"). Thai is currently disabled on the server, so Thai fields return null. | pali |
| sutta_id | Yes | Sutta ID, e.g. "mn1", "dn22", "sn56.11", "dhp1-20". |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains that the tool returns full segment content, notes the presence of cross_reference fields for verification, and discloses limitations (e.g., Thai translation currently unavailable). It could be more explicit about idempotency and error handling, but overall provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy and includes a coverage section that may be redundant for a tool description. While well-structured with clear sections, it could be more concise by trimming examples and moving some contextual info to documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 params, output schema, diverse usage scenarios), the description covers most aspects: input format, output expectations, behavioral notes, and coverage. It lacks mention of error handling or behavior for invalid IDs, but is otherwise thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing extensive examples for sutta_id, clarifying the format and valid values, and noting current limitations for edition and language parameters (e.g., Thai translation not available). This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 full sutta content by standard ID. It provides numerous examples and distinguishes itself from search tools by focusing on direct ID-based retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'คำแนะนำสำหรับ AI client' section with practical tips on interpreting segments, quoting directly, and handling special cases like headers and colophons. However, it lacks explicit guidance on when to use this tool vs. sibling tools like search_by_keyword.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_word_definitionGet Word DefinitionARead-onlyIdempotentInspect
Look up the dictionary meaning of a Pāli word, with sutta context.
Serves as a Pāli Dictionary Bridge — pairs the "definition" with the "context where the Buddha actually used the word".
📖 About the dictionary sources: This tool draws from multiple primary dictionaries, including "พจนานุกรมพุทธศาสน์ ฉบับประมวลศัพท์" (Buddhist Dictionary — Concept-Glossary edition) by Somdet Phra Buddhaghosacariya (P. A. Payutto). The Thai-language entries are original scholarly works (not translations), so they are always available even when ENABLED_LANGUAGES has Thai disabled. The AI client should translate Thai entries into the user's language if needed.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | Word to look up (e.g. "dukkha", "กฐิน"). | |
| language | No | Dictionary language (e.g. "en", "thai", or "all" as default). | all |
| limit_context | No | Number of sutta-context examples to include (1-5). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It explains that the tool returns definitions and sutta context, and notes that the source is original academic work always accessible. It also alerts that results may be in Thai and need translation. No destructive behavior is mentioned, which is appropriate for a read tool. Minor omission: no mention of error handling or missing words.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description starts with a clear one-sentence purpose statement, followed by a usage line and an explanatory paragraph about the dictionary database. The extra paragraph is useful but slightly wordy. The use of emojis adds visual structure but is not essential. Overall it is well-structured and informative, though could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (not shown), the description does not need to detail return values. It covers the main purpose, data source, and behavior regarding Thai content. It lacks information about error handling or word availability, but for a dictionary lookup tool, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add significant value beyond the schema; for example, it doesn't enumerate available languages or clarify how limit_context affects output. The parameter descriptions in the schema are already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves dictionary definitions of Pali words along with contextual example sentences. It provides a specific verb ('ดึงความหมาย' – retrieve meaning) and resource ('พจนานุกรมของคำศัพท์บาลี'), and distinguishes it from sibling tools like search_by_keyword by focusing on definitions with context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly positions the tool as a 'Pali Dictionary Bridge' for understanding true meaning, implying it is for definitions rather than full-text search. It notes that the dictionary content is always available even if Thai is disabled, guiding multilingual use. However, it does not explicitly contrast with sibling tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_editionsList Translation EditionsARead-onlyIdempotentInspect
List the translation editions available, with coverage stats.
💡 Use this tool when:
Before calling
compare_translationsorget_sutta(edition=...), so you know which edition values are valid and worth comparing.The user asks which editions are loaded in the DB.
🔍 Filtering: Filtered by the server's TRIPITAKA_ENABLED_LANGUAGES
— when Thai is disabled the list is empty. Only enabled languages
are returned.
⚠️ Current state: the DB mostly holds Pāli (default from
SuttaCentral bilara) and English (Sujato). Thai editions
(dhiranandi, jayasaro, mbu, royal) aren't indexed yet — the
list returns empty until they're loaded.
Returns: List of edition objects, each containing: - edition: edition code, e.g. "sujato", "dhiranandi", "mbu" - translator: translator's name - language: ISO code ("pi", "en", "th") - segment_count: how many segments have a translation in this edition - sutta_count: how many suttas have a translation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: filtering by enabled languages, current indexing state for Thai editions, and the exact structure of returned objects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with emojis and sections, but slightly verbose. Front-loads key information, though could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete coverage for a no-parameter tool with described output schema. Includes filtering logic, state caveats, and return structure, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. Description adds meaning by explaining output fields and behavior, but no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists editions with coverage statistics, with specific verb 'แสดงรายการ' (list) and resource 'ฉบับแปล' (editions). It distinguishes itself by providing usage context relative to sibling tools like compare_translations and get_sutta.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before compare_translations or get_sutta, when user asks about editions) and provides filtering behavior based on server configuration. Also notes current state limitations, giving clear guidance on expected results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_structureList Tipiṭaka StructureARead-onlyIdempotentInspect
Show the structure of all three pitakas with coverage statistics.
💡 Use this tool when:
The user asks for an overview of the Tipiṭaka (what's in it / which collections).
You need to check coverage before promising a search will find something —
segment_count > 0is the active-loaded signal.Verifying scope when compiling an artifact.
📊 Current state (v1.1+, at parity with SuttaCentral bilara-data):
Sutta Piṭaka complete: DN 37, MN 155, SN 1,829, AN 1,419, KN 2,351 sections (~284,702 segments) — Pāli + Sujato EN
Vinaya Piṭaka complete: Bhikkhu Vibhaṅga 222, Bhikkhunī Vibhaṅga 127, Khandhaka 22, Parivāra 51 + Pātimokkha 2 (~71,557 segments) — Pāli + Brahmali EN
Abhidhamma Piṭaka complete: 7 books (ds, vb, dt, pp, kv, ya, patthana) ~88,414 segments — Pāli only (bilara has no English for any Abhidhamma book)
Total ~444,673 segments in the DB
⚠️ Known quirks:
The schema carries duplicate legacy + SC-modern codes side by side:
Vinaya:
vin-v/vin-m/vin-c/vin-p(legacy, segment_count = 0) alongsidepli-tv-bu-vb/pli-tv-bi-vb/pli-tv-kd/pli-tv-pvr(active, populated).Abhidhamma:
ym/pt(legacy = 0) alongsideya/patthana(active).
Always pick the code with
segment_count > 0— the others are metadata placeholders from an older migration.
🌐 Languages: Returns Pāli + Thai + English labels regardless of enabled set (these are metadata, not segment text). Text content follows ENABLED_LANGUAGES. Thai translations aren't loaded yet — Thai users can fall back to the cross_reference 84000.org link.
Returns: Hierarchical structure: - pitakas{vinaya/sutta/abhidhamma} → nikayas[] - Each nikaya: code, name (3 languages), sutta_count, segment_count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully bears the burden of behavioral disclosure. It details important quirks such as duplicate legacy and modern codes, instructs to use codes with segment_count > 0, notes language support (Pāli, Thai, English labels) and the absence of Thai translations. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured with bullet points, emoji markers, and clear sections. Every sentence adds value. Minor improvement could be trimming redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an explicit output schema described in the 'Returns' section, the description is complete. It explains the hierarchical structure, language handling, known quirks, and current data state, leaving no ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description cannot add parameter-specific meaning. With 0 parameters, the baseline is 4. The description focuses on output and behavior instead, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: showing the hierarchical structure of the Tripitaka with coverage statistics. It specifies the three pitakas and what each contains, making it distinct from sibling tools like get_sutta or search_by_keyword.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists three scenarios when to use this tool: for overview questions about the Tripitaka, checking coverage before promising search capabilities, and verifying scope for artifact compilation. This provides clear context and implicitly suggests when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_pali_wordParse Pāli WordARead-onlyIdempotentInspect
Strip Pāli inflectional suffixes to find the root form (basic stem).
💡 Use this tool when:
You find an inflected Pāli word (e.g.
dukkhassa,bhikkhūnaṁ) andget_word_definitiondoesn't find it directly — Pāli inflects nouns across 7 cases × 2 numbers, ~16 forms per root.You want to split a compound (
sammāsambuddhassa→sammā+sambuddha+-ssagenitive).You want to see possible stems before another
get_word_definitionlookup.
🔄 Recommended workflow:
parse_pali_word(inflected_form) → get possible_stems[] →
call get_word_definition(stem) per stem until you find a definition.
⚠️ Limitations:
Rule-based first-pass — strips common suffixes (case endings, vowel shortening). Not a full morphological analyzer.
Compound words (samāsa) are NOT split —
dukkhanirodhawon't be broken intodukkha+nirodha.Sandhi (sound junctions) like
tena ahaṁ → tenāhaṁaren't reversed.Returns possible stems — verify each via
get_word_definition.
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes | An inflected Pāli word (e.g. "dukkhassa", "bhikkhūnaṁ", "sīlavā"). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior. It explains the rule-based nature, limitations (no sandhi, no compound splitting), and that results are possible stems. Could mention idempotency or error handling, but adequate for a parse tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with emoji headings, bullet points, and workflow. Informative but not overly verbose. Every sentence adds value. Slightly long but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (Pali grammar), the description is thorough: covers purpose, when to use, workflow, limitations. Output schema exists, so return values need not be detailed. Contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description for the 'word' parameter. The description adds examples but doesn't provide additional semantic constraints or format details beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyzing Pali words for stemming/lemmatization. It provides examples (dukkhassa, bhikkhūnaṁ) and distinguishes from sibling tool get_word_definition by specifying when to use which.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance on when to use: when get_word_definition fails, for compound words, and to see possible stems. Recommends a workflow: parse then call get_word_definition. Also lists limitations, preventing misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_keywordKeyword SearchARead-onlyIdempotentInspect
Keyword search across the Pāli Tipiṭaka (trigram word-similarity).
Searches the configured enabled language(s) on the server. Filterable by pitaka and translation edition.
💡 Hints for the AI client: The system's canonical reference is Romanised Pāli (from SuttaCentral). If the user asks in a disabled or unsupported language, translate the keyword to Romanised Pāli (preferred) or English before calling this tool — e.g. "suffering" → "dukkha", "mindfulness of breathing" → "ānāpānassati". See the server instructions for the enabled language set.
🔍 Pick the right search tool for the question shape:
Term lookup (exact word appearances) — e.g. "occurrences of
ānāpānassati": this tool is best (trigram nails the exact word).Concept search ("discourses about X") — e.g. "discourses about mindfulness of breathing": use
search_hybridinstead. Canonical Pāli has two quirks that hurt keyword search for concepts: • Section headings (Ānāpānapabba) often use a different word than the teaching body, which uses verb forms (assasati,passasati,dīghaṁ,rassaṁ). E.g. DN22's Ānāpānapabba has 16 segments but the wordānāpānaappears in only 2 (header + footer) — the actual teaching segments won't match. • Stock phrases (e.g.So satova assasati, satova passasati) recur in 10+ suttas, so a keyword query ranks broadly and won't pinpoint the canonical reference.General keyword survey — set
limit≥30and filter client-side, or call multiple related forms (root verb + noun + compound).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default: 10, max: 50). | |
| pitaka | No | Filter by pitaka — "vinaya", "sutta", "abhidhamma" or None (all). ✅ v1.1+: all three pitakas at parity with SuttaCentral bilara — see list_structure for live counts. | |
| edition | No | Thai translation edition — "dhiranandi", "jayasaro", "mbu", "royal" or None. Only used when language="thai" and Thai is enabled on the server. | |
| keyword | Yes | The word/phrase to search for. | |
| language | No | Search language — must be in the server's ENABLED_LANGUAGES (default: "pali"). Disabled languages return an error. | pali |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It explains trigram matching, language dependency, filtering options, and error behavior for disabled languages. It does not cover pagination but mentions limit defaults and max.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with sections and bullet points. It front-loads purpose and then gives usage advice. Each sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and an output schema, the description covers all critical aspects: when to use, how to use, comparisons to siblings, behavioral traits, and parameter semantics. It is comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant meaning: keyword translation advice, pitaka scope with reference to list_structure, edition conditionality on language, and language default/error handling.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Tripitaka by keyword using trigram similarity. It distinguishes itself from sibling tools like search_hybrid, explicitly noting this is for term lookup, not concept search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use for term lookup, use search_hybrid for concept search. Also advises on language translation to Pali Roman or English if the user's language is not supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_hybridHybrid SearchARead-onlyIdempotentInspect
Hybrid search — combines keyword + semantic search via RRF.
Uses Reciprocal Rank Fusion (RRF) to merge exact-word results with
meaning-based results. This is the recommended tool for "discourses
about X" / concept queries, because the semantic side catches suttas
that discuss a concept using different vocabulary (e.g. some
mindfulness-of-breathing suttas use assasati/passasati/dīghaṁ
instead of ānāpānassati).
💡 Hints for the AI client:
English queries usually work best (e.g.
mindfulness of breathing) because the embedding model is multilingual but EN-primary.Thai stop-word handling is weak. If a Thai query underperforms, the AI client should translate to Pāli/English first (see server instructions).
The default
limit=5is often too small for a topic survey — uselimit=15-20(max 20) for good coverage.Ranking is by similarity, NOT canonical importance — locus classicus suttas (e.g. MN118, DN22) may rank below smaller suttas that happen to use the exact vocabulary. Treat results as a starting point, then call
get_suttafor the canonical references.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default: 5, max: 20). | |
| query | Yes | Query text (Thai, Pāli, or English — English works best). | |
| language | No | Output language — "pali", "thai", "english", or "all". | pali |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 explains the RRF fusion technique, ranking behavior, and limitations like language effectiveness. It does not explicitly state non-destructive nature, but as a search tool this is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, front-loading the purpose. It is somewhat verbose but each sentence adds value, though could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of hybrid search and existence of output schema, the description covers usage tips, limitations, and technical details thoroughly, enabling effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value: for query it explains language effectiveness, for limit it recommends higher values for surveys, and for language it clarifies options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a hybrid search combining keyword and semantic search using RRF. It identifies the use case ('recommended for finding content about topic X') but does not explicitly differentiate from sibling tools like search_by_keyword and search_semantic, though the combination is implied.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides specific recommendations for AI clients: using English queries, handling stop words, adjusting limit for coverage, and understanding ranking is similarity-based not canonical. It lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_semanticSemantic SearchARead-onlyIdempotentInspect
Semantic search — match by meaning, not exact words.
Uses vector similarity (cosine distance) over text_pali embedded with
a multilingual MiniLM model.
🤔 In most cases you should use search_hybrid instead — it
combines this semantic search with keyword search and ranks better.
Use this tool only when you need:
Pure semantic results (no keyword influence)
Fine-grained
thresholdtuning (hybrid uses RRF which is harder to tune)To debug what semantic alone picks up vs keyword
⚠️ Known limitations:
The index is Pāli only (English/Thai queries pass through the multilingual embedding but the model isn't tuned on Pāli)
English queries usually embed better than Thai (model is EN-primary)
For specific Pāli terms (
appamāda,dukkha), exact match is better — usesearch_by_keywordinsteadPāli stock phrases recur in many suttas → similarity scores cluster; read the top 10, don't trust rank 1 alone
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default: 5, max: 20). | |
| query | Yes | Query text (English works best, then Pāli, Thai is weakest). | |
| language | No | Output language — "pali", "thai", "english", or "all" (Thai disabled → null). | pali |
| threshold | No | Maximum cosine distance (smaller = stricter match). Default 0.7; lower to 0.5 for tighter matches, raise to 0.9 for broader. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. Discloses use of cosine distance, multilingual MiniLM model, language-specific performance (English best, Thai weakest), and known limitations like index being only Pāli and dispersion of scores. Lacks explicit mention of read-only nature, but context implies no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a concise first line, bullet points for usage and limitations. Every sentence adds value, though slightly verbose. Good front-loading of core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity, 100% schema coverage, and existence of output schema, the description comprehensively covers purpose, usage guidelines, parameter semantics, and limitations. No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaningful context: explains query language effectiveness, threshold meaning as cosine distance with tuning guidance, and default/max values. Exceeds baseline by providing practical usage tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs semantic vector similarity search on text_pali, distinguishing it from keyword search. It explicitly contrasts with sibling tools like search_hybrid and search_by_keyword.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using search_hybrid for most cases and provides specific scenarios for this tool: pure semantic search, fine-grained threshold tuning, and debugging. Also recommends search_by_keyword for exact Pāli terms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!