Search and read the Pāli Canon: Pāli root texts with Russian and English translations.
Scored across 5 tools
Each tool has a recognizably different job: discovery (list_structure, search), retrieval (get_text), and comparison (compare_editions vs compare_translations). The closest pair is get_text (which can return translations via langs) and compare_translations, plus the two compare_* tools, but the descriptions clearly separate editions-of-Pali from root-vs-translation work.
Four tools follow a clean verb_noun snake_case pattern (compare_editions, compare_translations, get_text, list_structure). The lone bare verb 'search' is a minor deviation but still readable and conventional.
Five tools is well-scoped for a canon reading/search server: two discovery, one retrieval, two comparison. Each earns its place with no redundant surface.
The lifecycle of navigate → search → fetch → compare editions/translations is fully covered. Minor gaps exist (no term/dictionary lookup, no per-sutta metadata like parallels or UIDs beyond segment ids), but agents can work around them with search and get_text.
Compare the Pali Canon's editions line by line: the Mahāsaṅgīti beside Buddha Jayanti (Sri Lanka), Chaṭṭha Saṅgāyana (Myanmar), Siam Rath (Thailand), the printed Mahāsaṅgīti of 2005 and the PTS editions (DN, MN, SN, AN). Give a sutta ("sn56.11"), a line ("dn22:18.1") or a range ("sn56.11:5.1-5.4"). The answer starts with a summary per edition (name, license, lines present, missing, differing), then the lines where some edition reads differently, each with the differing words. Case, punctuation and ṁ/ṃ are not counted as differences.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A sutta (sn56.11), a line (dn22:18.1) or a range of lines (sn56.11:5.1-5.4). | |
| all | No | Every line, not only the lines where an edition differs. Default false. | |
| from | No | Continue from this line (the next_from of a previous answer). | |
| limit | No | Lines per answer (default 60); the answer gives next_from to continue. | |
| editions | No | Editions to compare with the Mahāsaṅgīti. Default: all of bjt, my, th, mso, pts. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does well: it discloses the response structure (per-edition summary with name, license, lines present, missing, differing, then differing lines with differing words) and normalization rules (case, punctuation, ṁ/ṃ ignored). It does not mention pagination behavior or error conditions, which are only in the schema, so it falls short of a perfect score.
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?
Front-loads the purpose and edition list, then specifies accepted input forms, then explains the answer shape and normalization rules. Every sentence earns its place with no repetition or filler.
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?
For a complex, five-parameter comparison tool with no output schema, the description supplies the critical missing pieces: what the returned summary contains, what constitutes a difference, and what normalization is applied. Pagination parameters are documented in the schema, so the description need not repeat them.
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 the baseline is 3. The description adds value beyond the schema by mapping enum codes like bjt and my to human-readable edition names (Buddha Jayanti, Chaṭṭha Saṅgāyana, etc.), which the schema does not do, and by clarifying the acceptable id formats in prose.
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 a specific verb (compare) and resource (Pali Canon editions), names the exact editions involved, and distinguishes this from translating by focusing on line-by-line edition differences. An agent can immediately tell this apart from compare_translations.
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?
Explains that the tool accepts a sutta, a line, or a range, with concrete examples, which gives clear usage context. It does not explicitly name when to prefer compare_translations instead, but the distinction is strongly implied by the edition-vs-translation framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One segment of the canon in the Pali root and every available translation side by side. Use a segment id from search/get_text, e.g. "mn129:21.3". Sujato (en_sujato) is excluded unless named in translators.
| Name | Required | Description | Default |
|---|---|---|---|
| langs | No | Limit to these languages, e.g. ["ru","en"]. Default: all. | |
| segmentId | Yes | Segment id as returned by search, e.g. mn129:21.3 or dn22:1.1. | |
| translators | No | Explicit translator keys, e.g. ["en_sujato"] to include Sujato. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses the non-obvious default that Sujato (en_sujato) is excluded unless named, but says nothing about response shape, ordering, or limits.
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?
Two sentences, zero waste, purpose front-loaded ahead of the id-source instruction and the Sujato exclusion caveat. Every clause 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?
A read-only lookup with full schema coverage; the description covers purpose, id provenance, and the key default filter. Missing only return-shape detail, which matters slightly more here since there is no output schema.
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 all three parameters are already documented with examples. The description restates the segment-id format and the Sujato inclusion rule, which the schema also covers, adding little syntax or meaning beyond it. Baseline 3 applies.
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 a specific verb and resource: retrieve one canon segment with the Pali root and all available translations 'side by side.' The comparison framing is concrete, though it doesn't explicitly contrast its purpose against siblings get_text/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?
Tells the agent where the required id comes from ('Use a segment id from search/get_text') and flags the Sujato default caveat so the agent knows when to name translators. It gives clear context but no explicit when-not or alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a sutta by id (e.g. "dn22", "mn1", "sn56.11") — the Pali text (Mahāsaṅgīti) of every segment. Pali only by default; pass langs for translations, translators to name a translator (e.g. ["en_sujato"]), editions for the whole text of other Pali editions line by line (DN, MN, SN, AN). Same data as dhamma.gift/api/text.
| Name | Required | Description | Default |
|---|---|---|---|
| langs | No | Translation languages to include, e.g. ["ru","en"]. Default: none (Pali only). | |
| suttaId | Yes | Sutta id, e.g. dn22, mn1, sn56.11. | |
| editions | No | Other Pali editions to add, each segment beside the Mahāsaṅgīti: bjt (Buddha Jayanti, Sri Lanka), my (Chaṭṭha Saṅgāyana, Myanmar), th (Siam Rath, Thailand), mso (Mahāsaṅgīti as printed, 2005), pts (Pali Text Society), or ["all"]. DN, MN, SN and AN only. | |
| translators | No | Explicit translator keys, e.g. ["en_sujato"] to include Sujato. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It does well by stating the default is Pali only, that passages can include translations or other editions, and that editions are limited to DN, MN, SN, and AN. It still leaves minor gaps around error behavior and response structure.
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 a single, front-loaded paragraph that starts with the core action and then summarizes defaults and optional behavior. It is dense but has little wasted text.
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?
For a read tool with no annotations and no output schema, the description provides enough context to invoke it correctly: required suttaId, default Pali-only behavior, and optional translations and editions. It could say more about response shape or invalid-id handling, but the core invocation context is 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%, so the schema already documents all four parameters. The description adds useful framing about defaults and how langs, translators, and editions affect the result, though most parameter details are already present in 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 states a specific verb and resource: fetch a sutta by id. It explains that the result is the Mahāsaṅgīti Pali text of every segment, which is clear. It does not explicitly differentiate itself from siblings such as compare_editions or compare_translations, so it falls short of a 5.
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 implies usage by saying to pass langs for translations, translators to name a translator, and editions for other Pali editions. However, it does not explicitly say when to use this tool versus compare_editions, compare_translations, list_structure, or search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What texts exist. Without arguments: collections (sutta/vinaya/abhidhamma/khuddaka), books by id prefix with sutta counts, and translation languages with translators. With prefix (e.g. "mn", "sn56", "an4"): the suttas under it with titles.
| Name | Required | Description | Default |
|---|---|---|---|
| prefix | No | Sutta id prefix such as mn, sn56, an4, dhp. Max 200 suttas are listed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose what is returned in each mode (collections, books with sutta counts, languages with translators, or sutta titles). However, it never states that this is a read-only operation, nor mentions the 200-sutta cap behavior beyond the schema, pagination, or any other operational constraint.
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?
Two dense sentences, front-loaded with the core purpose, then a clean no-argument/with-prefix structure. Every clause carries information; slightly telegraphic phrasing but no wasted sentences.
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?
There is no output schema, so the description must describe return values, and it does so for both modes (collections/books/languages vs. titled suttas). For a single optional-parameter listing tool this is close to complete, with only minor gaps around read-only status and result size limits.
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 the baseline is 3, but the description adds real meaning by explaining what happens when prefix is omitted versus supplied ("the suttas under it with titles"), effectively documenting the parameter's conditional effect. This goes beyond the schema's own example-based prefix description.
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 opens with a specific scope statement ("What texts exist") and precisely delineates two modes of operation: no-argument collection/books/languages listing and prefix-based sutta listing. It clearly reads as a structural navigation tool, distinguishable from get_text, search, and compare_translations by its catalog-oriented output, though it never names those siblings.
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?
It explains when to use each argument mode (no args vs. with prefix), which is genuine usage guidance, but never states when to prefer this tool over siblings like get_text or search, nor any exclusions. Usage is implied by the output description rather than stated as routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Pali Canon on dhamma.gift by keyword/substring or REGEX (min 3 letters, no semantic search). Patterns like "kata.*dukkha", "vucc.*dukkha", "katha.*dukkha" find the canon's own definitions and expositions of a term. Returns a CENSUS of every matching sutta — id, title, match count, metaphor count, reader link — Pali only, ordered so that suttas that DEFINE the term come first, then ones NAMED after it, then by how often it occurs. Set include_segments for the matched Pali lines, include_translations (+ langs) for translations. 40 suttas by default (25 by occurrence count, plus 15 for suttas named after the term and ones defining it); metadata.totalFiles reports the true count, and limit takes a number or "all".
| Name | Required | Description | Default |
|---|---|---|---|
| exact | No | Whole-word match only. Default: false. | |
| langs | No | Translation languages to include with include_translations, e.g. ["ru","en"]. Default: none (Pali only). | |
| limit | No | How many suttas to list: a number, or "all" for every match. Default: 40, composed of 25 by occurrence count plus 15 for suttas named after the term and defining it. Strict — the cap means the cap. metadata.totalFiles always carries the true match count, so a truncated answer still tells you how much more there is. Suttas whose TITLE matches the query rank first within their collection. | |
| query | Yes | Keyword, phrase, or REGEX pattern to search for (Pali or a translation word). Patterns work and are the way to find definitions: "kata.*dukkha" (Katamañca … dukkhaṁ?), "vucc.*dukkha" (idaṁ vuccati dukkhaṁ), "katha.*dukkha" (Kathañca … hoti?). | |
| scope | No | default|all|dhamma|vinaya|abhi|khudakka|or comma-separated nikaya codes (dn,mn,...). Default: default (4 nikayas + 6 KN books). | |
| translators | No | Explicit translator keys, e.g. ["en_sujato"] to include Sujato, or ["ru_sv"]. Needed only to override the default translator choice. | |
| include_segments | No | Also return the matched Pali segments (segment id, text, reader link). Default: false — the census alone. | |
| include_translations | No | Also return translations of the matched segments (implies include_segments). Default: false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does it well: it discloses the census return shape (id, title, match count, metaphor count, reader link), the Pali-only default, the ranking order (definers first, then named-after, then by frequency), the 40-sutta default split, and that metadata.totalFiles reports the true count when truncated. It omits auth/permission needs and pagination, but is otherwise unusually transparent about behavior.
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 purpose and mode constraints are front-loaded in the first sentence, followed by worked regex examples and then return/routing details. It is dense and slightly run-on, but nearly every clause conveys non-obvious information rather than filler.
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?
With 8 parameters and no output schema, the description does the work of explaining the return payload, ordering, default limit composition, and truncation signaling. That is sufficient to call the tool correctly; only auth and deeper pagination semantics are unaddressed.
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 the baseline is 3, but the description adds real meaning: it explains that include_segments returns matched Pali lines, include_translations implies segments, and that limit accepts a number or 'all' with strict capping backstopped by metadata.totalFiles. This goes beyond restating the schema fields.
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 a specific verb (search), resource (the Pali Canon on dhamma.gift), and the exact matching modes accepted (keyword/substring or REGEX, min 3 letters, no semantic search). The purpose is unambiguous and an agent can immediately tell this is a regex/text search over a defined corpus.
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?
Gives clear context: 'no semantic search' excludes the obvious alternative approach, and example patterns ('kata.*dukkha') show the intended usage for finding term definitions. However, it never compares itself to the sibling tools (get_text, compare_translations, list_structure) or states when one of those should be preferred instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
compare_editionsget_text1 field changedInput schema / properties / editionsAdded value: +{
+ "description": "Other Pali editions to add, each segment beside the Mahāsaṅgīti: bjt (Buddha Jayanti, Sri Lanka), my (Chaṭṭha Saṅgāyana, Myanmar), th (Siam Rath, Thailand), mso (Mahāsaṅgīti as printed, 2005), pts (Pali Text Society), or [\"all\"]. DN, MN, SN and AN only.",
+ "items": {
+ "enum": [
+ "bjt",
+ "my",
+ "th",
+ "mso",
+ "pts",
+ "all"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}get_text1 field changedInput schema / properties / suttaId / descriptionPrevious value: -"SuttaCentral-style id, e.g. dn22, mn1, sn56.11."New value: +"Sutta id, e.g. dn22, mn1, sn56.11."compare_translationsget_textlist_structuresearchBuddhist canon tools: search, passages, cross-canon parallels, dictionaries — all URN-cited.
Search and read ~250k pages of Chinese Buddhist texts from Xianmi Library (xianmi.co).
Read-only Buddhist scripture search, verified explanations, situation matching, and practice.
Full Bhagavad Gita (Sanskrit + English) and Ganguli's Mahabharata: search verses and passages.
Add one secure layer between your agents and this server.
