Skip to main content
Glama

Search the scriptures

search_texts
Read-only

Search the Vedaword library of Sanskrit scripture by meaning as well as by wording, so a paraphrased question works and a Sanskrit term reaches passages written in another script. This is the first thing to call for any factual question about what the scriptures say.

Start here when you have words: a question, a phrase, a term. When you already have a verse and want its parallels, use find_similar_verses instead; to read a known verse whole, use get_verse; to read a chapter or a book in order, use browse_work.

Returns passages with an exact citation, a URL and the version hash of the text quoted.

Read confidence before using the results. "none" means the library has no answer and the result list is empty — report that to the user instead of reaching for something related. "low" means the passages are leads, not answers. matched_by says how each was found: a passage found only by "vector" shares no words with the query.

Input Schema

NameRequiredDescriptionDefault
limitNoPassages to return. Default 8.
partsNoWhich part of a verse to search: `verse` is the Sanskrit source text, `translation` the literary translation, `word_by_word` the gloss table, `commentary` Vedaword's own exposition, `bhashya` an ācārya's original commentary. Omit to search all.
queryYesA question, a phrase, a Sanskrit term, or a citation such as "BG 2.47". Any language, and Sanskrit in Devanāgarī or IAST. Quote the string to require the exact wording.
worksNoRestrict to these works by slug — see list_works. Omit to search all.
languageNoPreferred language of the translations returned. Not a filter: works that exist only in Russian are returned in Russian, and each result says which language it is actually in. Default: en.
full_textNoReturn each passage whole instead of an excerpt. Use when you intend to quote; excerpts are for deciding what to quote.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover read-only and closed-world safety, yet the description adds substantial behavior beyond them: what a result contains (exact citation, URL, version hash), the confidence contract including the critical 'none' = no answer / empty list instruction, and how matched_by='vector' implies zero lexical overlap. This is exactly the guidance an agent needs to interpret results honestly.

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?

Front-loaded with what the tool is and why it works, then a usage section, then return-value semantics. Each paragraph carries distinct, non-redundant information; nothing is padding.

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?

There is no output schema, and the description compensates by naming the returned fields, the confidence levels, and the interpretation rule for matched_by. Combined with the sibling routing, an agent has everything needed to call it and to use the results correctly.

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%, so baseline is 3; the description still adds value by explaining the hybrid meaning+wording search behind `query` and cross-script term matching, which the schema does not say. It does not elaborate on limit or full_text beyond the schema, so it stays a notch above baseline rather than fully additive.

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?

States a specific verb and resource ('Search the Vedaword library of Sanskrit scripture') and immediately names the two retrieval modes (meaning and wording). It explicitly differentiates itself from find_similar_verses, get_verse, and browse_work, so an agent can pick it without opening a schema.

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?

Gives an explicit trigger ('Start here when you have words: a question, a phrase, a term') plus a complete routing table of alternatives and the condition each covers (known verse to read whole → get_verse, chapter in order → browse_work). Also states the excluded case explicitly.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources