Skip to main content
Glama

Search Translations

search_translations
Read-onlyIdempotent

RETURNS QUOTABLE PASSAGES (page-level snippets + citation URLs), matched by KEYWORD/term. PICK THIS to find a quote or textual evidence on a topic across the whole library. → If the modern word won't literally appear in historical texts, use search_concept (matches by meaning); to list which BOOKS cover a topic use search_library; to dig inside one known book use search_within_book; if the user named an author/work, get_book first (its AI summary is usually the right first read). Query tips: single distinctive terms ("memory palace", "wax tablet") work best; multi-word natural-English queries ("unity of the intellect") may return fewer results because matching is term-based, not phrase-based. Each snippet has a snippet_type — "translation"/"ocr" means it is a verbatim extract from the source text; "summary" means it is AI-generated description (do not quote those as the author's words). Response includes total_matches, returned, and offset for pagination. Cross-cultural tip: for pre-modern or non-Western topics, search source-tradition vocabulary rather than modern English terms — e.g. for seminal economy search "jing" or "bindu" or "istimnāʾ", not "semen retention"; for female homoeroticism search "tribade" or "sahq", not "lesbian". The corpus is indexed via period translations that use tradition-internal terminology.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
langNoISO code of the EDITION to read, e.g. "es". Default "en". Most books have only English — call get_book and read `editions`, or list_books with has_edition, to find the ones that do not. The response always states which edition it served.
limitNoMax results per page (default 20, max 50)
queryYesSearch term — prefer single distinctive concepts ("harmony of the spheres", "active intellect") over long natural-language phrases. Multi-word queries match all terms (not phrase); wrap in "double quotes" for exact phrase.
offsetNoPagination offset (use with limit to page through total_matches; default 0)
book_idNoSearch within a specific book
year_toNo
languageNoFilter by a single original language
diversityNoRe-order the passages for spread. "author": at most one passage per author and per work in each ten, for a cross-author survey. "tradition": at most 2 per tradition family and per work. Default "off": keyword results come in match order. Nothing is dropped; later pages hold the rest.
languagesNoFilter to any of these languages, e.g. ["Sanskrit", "Arabic", "Chinese"]. Use instead of language when targeting multiple traditions.
year_fromNo
exclude_languagesNoExclude these languages, e.g. ["Latin", "French", "German", "English"] to surface non-Western sources.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / diversity
      Added value: +{
      +  "description": "Re-order the passages for spread. \"author\": at most one passage per author and per work in each ten, for a cross-author survey. \"tradition\": at most 2 per tradition family and per work. Default \"off\": keyword results come in match order. Nothing is dropped; later pages hold the rest.",
      +  "enum": [
      +    "tradition",
      +    "author",
      +    "off"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / lang
      Added value: +{
      +  "description": "ISO code of the EDITION to read, e.g. \"es\". Default \"en\". Most books have only English — call get_book and read `editions`, or list_books with has_edition, to find the ones that do not. The response always states which edition it served.",
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive), and the description layers on genuinely new behavior: snippet_type semantics identifying which snippets are verbatim vs AI-generated (and a caution not to quote 'summary' as the author's words), the pagination fields in the response (total_matches, returned, offset), and the fact that the response states which edition it served.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Strongly front-loaded: purpose and routing come first, caveats and tips after. It is long, and the multi-word/term-based query tip partly repeats the query parameter's own schema description, which is mild redundancy rather than waste given the concrete examples.

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?

For an 11-parameter, output-schema-less tool, it is unusually complete: return structure, snippet provenance, pagination mechanics, the edition echoed in the response, query strategy and sibling routing are all covered. Nothing an agent needs to invoke it correctly 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 82%, so the baseline is 3, and the description meaningfully exceeds it: it explains term-based vs phrase matching (quoting for exact phrase), why long natural-language queries underperform, and gives source-tradition vocabulary substitutions ('jing', 'bindu', 'tribade') rather than modern English. It covers query well but says little extra about book_id, year_from/year_to, or diversity beyond what the schema already documents.

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+resource and the exact output shape: 'RETURNS QUOTABLE PASSAGES (page-level snippets + citation URLs), matched by KEYWORD/term.' The 'PICK THIS to find a quote or textual evidence on a topic across the whole library' line draws a hard boundary against search_concept, search_library and search_within_book, so an agent can route without opening any 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?

Explicit when-to-use plus named alternatives with the condition that selects each: search_concept for meaning-based matching, search_library to list books, search_within_book to dig into one known book, get_book first when the user names an author/work. It also gives a when-not in practice (term-based matching fails for modern-vocabulary queries). This is about as complete as routing guidance gets.

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.