Tripitaka MCP (hosted)

Survey Corpus (exhaustive)

survey_corpus

Read-onlyIdempotent

Exhaustively survey the WHOLE Tipiṭaka for a term — guaranteed complete.

Use this (not search_by_keyword) when the question is about coverage or counting rather than "show me the best passages":

"How many times does Kusinārā appear in the canon?"
"Every place ānāpānassati is mentioned — don't miss any"
"Which pitakas/how many suttas mention this term?"

Unlike search_by_keyword (ranked, capped at 50, no total), this returns an exact count, a per-pitaka breakdown, the distinct surface forms that matched (so you can audit and discard over-matches), and a paginated enumeration. The lexical result carries complete: true — a hard guarantee that nothing was dropped for the chosen match_scope.

Two layers, two different promises:

lexical — the word and its forms. Deterministic + EXHAUSTIVE.
semantic (mode="thorough", hosted only) — passages teaching the same concept with DIFFERENT vocabulary (e.g. ānāpānassati via assasati/passasati). Approximate, NOT exhaustive — it never claims completeness, it only boosts recall.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	"fast" (default) = lexical only — quick, no server-side ML, works offline. "thorough" = also run the semantic layer (hosted only; this is the heavier part). The lexical guarantee holds in BOTH.	fast
`cursor`	No	Offset into the full lexical result set for pagination.
`pitaka`	No	Restrict to "vinaya" / "sutta" / "abhidhamma", or None for all.
`keyword`	Yes	Term to survey (Romanised Pāli preferred; diacritics optional — matching folds `ā→a`, `ṁ→m`, etc.).
`language`	No	"pali" (default) or "english". Thai is not indexed yet.	pali
`page_size`	No	Lexical results per page (default 20, max 100). Counts/forms cover the WHOLE corpus regardless of this.
`sem_limit`	No	Max semantic hits (default 50, max 200). `capped` flags when reached. Only used when mode="thorough".
`match_scope`	No	"word" (default) matches the exact word/phrase only. "stem" also matches inflections + compounds via prefix (kusinārā → kusinārāyaṁ, kusināravagga …) — higher recall, may over-match (audit via `matched_forms`).	word
`sem_threshold`	No	Max cosine distance for semantic hits (default 0.7; lower = stricter). Only used when mode="thorough".

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description goes further by disclosing the exhaustive guarantee, exact count, per-pitaka breakdown, matched surface forms, `complete: true` flag, and the crucial caveat that semantic mode is approximate and NOT exhaustive. No contradiction with annotations.

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 well-structured with a bolded lead guarantee, bulleted example questions, and clear separation of lexical vs semantic promises. It is concise enough for the complexity of a 9-parameter tool, and every sentence serves a distinct purpose.

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

Completeness5/5

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

This is a complex tool with rich annotations, a detailed input schema, and an output schema. The description fully covers when to use it, how it differs from alternatives, its safety profile, completeness guarantees, semantic limitations, pagination behavior, and offline/hosted constraints. Nothing critical is missing.

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

Parameters4/5

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

Schema coverage is 100% with detailed parameter descriptions, so the baseline is 3. The description adds strategic context beyond the schema: the lexical guarantee holds in both modes, semantic mode is hosted-only, and `match_scope` over-matching can be audited via `matched_forms`. This elevates the parameter understanding beyond bare 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 opens with 'Exhaustively survey the WHOLE Tipiṭaka for a term — guaranteed complete', which clearly identifies the verb, resource, and scope. It immediately distinguishes the tool from its sibling `search_by_keyword` by stating it is for coverage/counting questions rather than best-passage retrieval.

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

Usage Guidelines5/5

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

Explicitly states 'Use this (not `search_by_keyword`) when the question is about coverage or counting' and provides concrete example queries. It also explains the difference in behavior (ranked, capped at 50, no total) and differentiates the lexical vs semantic modes, giving clear selection criteria.

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

All Tripitaka MCP (hosted) tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose. Search tools are differentiated by strategy (keyword, hybrid, semantic, exhaustive). Reading tools separate content retrieval, comparison, and viewer rendering. Parsing and definition tools have complementary roles. No overlapping functionality.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case, e.g., compare_translations, get_sutta, list_editions, search_by_keyword. The only slight deviation is open_sutta_viewer using 'open' instead of 'view', but it still fits the pattern.

Tool Count5/5

12 tools is well within the ideal range for a domain-specific server. Each tool addresses a distinct need: retrieval, search, parsing, dictionary, citation, structure overview, and comparison. No bloat or thinness.

Completeness5/5

The tool surface covers the full lifecycle for a read-only Pāli canon server: fetching content, searching (multiple modes), viewing with translations, comparing translations, parsing words, looking up definitions, listing editions and structure, and generating citations. There are no obvious gaps for the intended use case.

Resources

Need Help?