Buddhist canon tools: search, passages, cross-canon parallels, dictionaries — all URN-cited.
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.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 3.1/5.
Each tool targets a distinct operation: searching the corpus, reading a passage, verifying a quote, resolving a URN, looking up dictionary terms versus knowledge graph entities, and fetching parallels. The descriptions clearly separate these purposes, leaving no ambiguity about which tool to use.
All tool names follow a consistent verb_noun pattern with verbs like get, lookup, read, resolve, search, and verify. The naming is uniformly snake_case and clearly indicates the action performed, making the API predictable.
Seven tools is well within the ideal range and each tool earns its place by covering a distinct aspect of Buddhist canon research: search, read, verify, resolve, lookup (terms and entities), and parallels. The count feels neither sparse nor bloated.
The server covers the full research workflow: discovering content (search_corpus, lookup_dictionary, lookup_entity), accessing primary texts (read_passage, resolve_urn), validating citations (verify_quote), and comparing translations (get_parallels). No critical gaps are apparent for a read-only canon tool.
get_parallelsAInspectCross-canon parallel passages aligned to a fascicle.
fojin's alignment moat: given a Chinese fascicle, returns the aligned
Pali/Tibetan/Sanskrit parallels (each with its own `urn`) so you can compare
how a passage is rendered across traditions.
| Name | Required | Description | Default |
|---|---|---|---|
| text_id | Yes | ||
| juan_num | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It states the operation is a read-like retrieval ('returns') and describes the output (parallels with their own `urn`), which is helpful. It does not discuss limitations, errors, or access requirements, but for a simple retrieval tool this is reasonably transparent.
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 concise, front-loaded, and contains two short paragraphs. The 'fojin's alignment moat' phrasing is somewhat unnecessary branding but does not detract much from 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?
Despite having no output schema, the description adequately conveys what the tool returns (aligned parallels with URNs) and the context of use. It does not cover edge cases or failure behavior, but for a tool with only two integer parameters and a clear retrieval purpose, it is largely 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?
The schema has 0% description coverage and only bare integer parameters. The description adds domain meaning by mentioning 'Chinese fascicle' and implying text_id identifies the Chinese text while juan_num is the fascicle number. However, it never explicitly maps text_id and juan_num to their roles or explains how to resolve these IDs, so it only partially compensates for the lack of schema documentation.
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 uses a specific verb ('returns') and resource ('Chinese fascicle') to state what the tool does, and clarifies the output as aligned Pali/Tibetan/Sanskrit parallels. This clearly distinguishes it from sibling tools like lookup_dictionary, read_passage, or search_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?
The description gives clear context: use this when you have a Chinese fascicle and want to compare its rendering across Buddhist traditions. It does not explicitly name alternatives or exclusions, but the intended use case is readily understandable and distinct from the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_dictionaryBInspectLook up a Buddhist term across fojin's dictionaries (748K+ entries).
| Name | Required | Description | Default |
|---|---|---|---|
| term | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure burden. Beyond the basic purpose, it does not state whether the operation is read-only, how results are returned, whether the term is matched exactly or partially, or any behavior about the limit parameter. The only additional detail is the entry count, which is more about scale than 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 description is a single front-loaded sentence that states the action, object, and scope in 11 words. Every word contributes meaning, with no filler or redundancy. It is appropriately concise for a simple lookup tool.
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 no output schema and no annotations, the description should provide more context about expected results, usage context, or limitations. It only states the function, leaving the agent without enough information to predict return format, default behavior, or edge cases. This is insufficient for a tool with two parameters and no structured safety hints.
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 0%, so the description must compensate. It clarifies that 'term' is a Buddhist term, but it does not explain the 'limit' parameter or any semantics beyond the schema's default value. No parameter details are given for limit, and the description only partially covers the term's meaning.
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 uses a specific verb ('look up') and identifies the resource clearly: Buddhist terms across fojin's dictionaries, with a scale indicator (748K+ entries). This distinguishes it from sibling tools like search_corpus or lookup_entity by scoping it to dictionary lookup.
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?
There is no guidance on when to use this tool versus alternatives. The description does not mention any exclusions or scenarios where a sibling tool would be more appropriate, leaving the agent to infer usage from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lookup_entityAInspectSearch fojin's knowledge graph for entities — people, places, works,
doctrinal terms — matching query.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states the basic search action and does not mention result format, relevance ranking, limitations, pagination, or handling of no results. This leaves the agent without critical behavioral information.
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, simple sentence that is concise and front-loaded. It wastes no words and immediately conveys the core functionality. This is an example of effective conciseness, even though more details could be added elsewhere.
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?
The tool is relatively simple, but the description lacks essential context such as what the output will look like, how the limit parameter influences results, and any expected formats or variations. Given the absence of annotations and output schema, the description does not fully inform the agent about the tool's behavior.
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 0%, so the description must compensate. It explains the 'query' parameter by stating that entities match the query, but it fails to explain the 'limit' parameter, its purpose, or its effect. The schema only provides a type and default, which is insufficient context for correct usage.
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 a specific verb ('Search'), a specific resource ('fojin's knowledge graph'), and the types of items being sought ('people, places, works, doctrinal terms'). This distinguishes it from sibling tools like lookup_dictionary or search_corpus, making the purpose unambiguous.
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 establishes clear context: use this tool to search for entities in a knowledge graph by query. It does not explicitly state when not to use it or mention alternatives (e.g., 'for exact dictionary definitions, use lookup_dictionary'), but the scope is specific enough to imply when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_passageAInspectRead the full content of one fascicle (卷) of a text, with its urn.
Use the `text_id`/`juan_num` from a search_corpus hit. Returns the actual
canonical text — quote from this, not from memory.
| Name | Required | Description | Default |
|---|---|---|---|
| text_id | Yes | ||
| juan_num | Yes |
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 states it returns the actual canonical text, implying authoritative content, and 'full content' suggests no truncation, but it does not mention authentication, rate limits, errors, or output size, leaving notable gaps.
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 only two sentences, front-loading the purpose and immediately providing usage instructions. It is free of redundant words and does not repeat schema information.
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 simple read operation with two parameters and no output schema, the description covers what it does, how to use it, and what it returns. It omits edge-case behavior, but given the tool's simplicity, this is acceptable and the description feels 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?
The schema has no parameter descriptions, so the description compensates by explaining that text_id and juan_num come from search_corpus hits and that juan_num corresponds to a fascicle. This is essential context for correctly supplying values, though it does not give formal definitions.
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 reads the full content of one fascicle of a text, with the verb 'read' and resource 'fascicle' specifying the exact action. It also distinguishes itself from siblings like search_corpus by noting it returns actual canonical text rather than hits.
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 explicitly instructs to use text_id and juan_num from a search_corpus hit, establishing a clear workflow and when to use the tool. It also advises to quote from the returned text rather than memory, providing practical usage guidance, though it does not compare with other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_urnAInspectResolve a fojin URN (e.g. fojin:cbeta/T0001.1) to a reader URL and confirm it exists in the corpus. Use to verify or dereference a citation.
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral transparency. It discloses the primary behaviors (resolving to a URL and confirming existence), but does not explain failure behavior (e.g., what happens if the URN doesn't exist), return format details, or any side effects. This adds some value beyond the name but lacks depth.
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 two sentences with no redundancy. It front-loads the core action and example, then adds a usage hint. Every word contributes, making it highly efficient and well-structured.
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 simple one-parameter tool, the description covers the essential purpose and provides an example. However, the lack of an output schema and no mention of return format or error handling leaves the agent uncertain about the response structure. While not overly complex, the description could be more 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?
The schema description coverage is 0%, so the description must compensate. It provides a concrete example (fojin:cbeta/T0001.1) that illustrates the expected URN format, adding meaning beyond the schema's bare type definition. However, it does not fully explain variations or constraints, leaving room for ambiguity.
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: resolving a fojin URN to a reader URL and confirming existence. It uses a specific verb ('resolve') and resource ('fojin URN'), provides a concrete example, and distinguishes itself from sibling tools by focusing on URN resolution rather than searching, reading, or verifying quotes.
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 says 'Use to verify or dereference a citation,' giving clear context for when to use it. It does not explicitly list exclusions or alternatives, but the guidance is sufficient to indicate appropriate use cases without confusing it with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_corpusAInspectSemantic search across fojin's Buddhist corpus (10K+ texts, 30+ langs).
Returns the most relevant passages, each with a `urn`, title, snippet and
similarity score. `lang` optionally filters by language code
(lzh=Classical Chinese, pi=Pali, sa=Sanskrit, bo=Tibetan, en=English).
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | ||
| limit | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does state what the tool returns and how `lang` filters results, but it does not explicitly say whether the operation is read-only, whether it has side effects, or whether authentication/rate limits apply. 'Semantic search' and 'Returns...' imply a safe read operation, but the lack of overt safety statements keeps this at a mid 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?
The description is compact and front-loaded. The first sentence states the tool's core purpose and corpus scope. The second sentence explains return values and language filtering in a tight, useful manner. No filler or repetition; every sentence adds value.
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 moderate complexity (3 params, no output schema, no annotations), the description covers the main essentials: purpose, scope, result format, and a key parameter. It omits result limiting behavior and does not discuss when not to use it, but it is still reasonably complete for a search tool.
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 schema has zero description coverage, so the description must compensate. It does explain `lang` with concrete language codes, and `query` is obvious from the 'search' wording. However, the `limit` parameter is not mentioned at all, leaving its behavior (control result count) undocumented. Partial compensation for the missing 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 opens with a specific verb and resource: 'Semantic search across fojin's Buddhist corpus'. It clearly distinguishes itself from sibling lookup tools by emphasizing corpus-wide semantic retrieval. The expected return (passages with urn, title, snippet, score) further clarifies its purpose.
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 when this tool is appropriate: when you need semantic, content-based search across the whole corpus rather than exact lookups. It does not explicitly mention alternatives or exclusion criteria, but the context is clear enough for an agent to choose it over exact-match or entity-lookup tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_quoteAInspectVerify that a Buddhist-canon quote exists VERBATIM in the corpus.
Call this before presenting any quoted scripture to a reader: LLMs
routinely invent plausible-looking quotes. Returns `verbatim` (bool),
where it was found (`matches`, each with a resolvable `urn`), or the
closest near-miss window when it wasn't. `cite` optionally narrows the
search — a CBETA id ("T0374") or fojin URN ("fojin:cbeta/T0374.13") —
and `cite_matched` reports honestly whether the quote is where you
claimed (a hit in a different fascicle does NOT confirm your citation).
Quote must be ≥4 CJK chars after normalisation; Classical Chinese only.
Short quotes are answered but say less: a four-character phrase recurs
across the canon, so read `cite_matched` rather than `verbatim`, and check
`matches_capped` before treating the list as complete. Each match carries
an absolute `reader_url` — cite that, not a reconstructed third-party link.
| Name | Required | Description | Default |
|---|---|---|---|
| cite | No | ||
| juan | No | ||
| quote | Yes |
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 richly discloses return values (verbatim, matches with urn, near-miss window), the honesty of cite_matched, the caveat about short quotes, the matches_capped limitation, and the advice to use reader_url. This goes far beyond a basic tool description.
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 front-loaded with a clear one-line purpose, and every subsequent sentence adds critical operational detail. It is dense yet efficient, covering return semantics, input constraints, and usage warnings without repetition or fluff.
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 no output schema, the description effectively covers all essential return fields (verbatim, matches, urn, cite_matched, matches_capped, reader_url) and usage limitations. It is slightly incomplete in not explaining the `juan` parameter or the exact output structure, but overall it provides enough context for an agent to use the tool 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?
Schema coverage is 0%, so the description must compensate. It thoroughly explains `quote` and `cite`, including format examples (CBETA id, fojin URN). However, the `juan` parameter is not explicitly described, though 'fascicle' appears in the text. Most parameters are well-addressed, but one remains undocumented.
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 first sentence clearly states a specific verb and resource: 'Verify that a Buddhist-canon quote exists VERBATIM in the corpus.' This distinguishes it from sibling tools like search_corpus by emphasizing exact verbatim verification and near-miss reporting, making its purpose unmistakable.
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 instructs when to use it: 'Call this before presenting any quoted scripture to a reader' and explains the problem of LLM-invented quotes. It also provides context by mentioning the requirement of ≥4 CJK characters and Classical Chinese only. It does not name alternative tools, but the situational guidance is strong.
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.
No comments yet. Be the first to start the discussion!