Free classics as interlinears: search the books, read any passage word by word, look up any word.
Scored across 4 tools
Each tool serves a distinct purpose: list_books for catalog browsing, get_passage for retrieving specific passages, lookup_word for lexical entries and occurrences, and search for finding passages by text. Descriptions clarify boundaries (e.g., search returns references to then use get_passage), so there is no meaningful overlap.
Three tools follow a clear verb_noun pattern (get_passage, list_books, lookup_word), but search is a bare verb without a noun. This is a minor deviation from an otherwise consistent convention.
Four tools is well-scoped for a digital library: discovery, retrieval, search, and lexical aid. Each tool earns its place with no redundancy, and the count aligns with the core operations of the domain.
The set covers the essential lifecycle—browse books, search text, read passages, and look up words. However, there is no direct way to enumerate all passages within a book or retrieve whole chapters (explicitly by design), which could hinder sequential reading or bulk study; agents must work around this via repeated get_passage calls or search.
Returns ONE passage of a book as an interlinear: the original text, a word-by-word table (each word, its transliteration, its everyday meaning, its literal sense where that differs, and its dictionary form), the flowing English, the editors' note, a citation string, and links to read it in the reader. Optionally adds the immediately following or preceding passage (never more than two passages per call; whole chapters or books are not available, by design). Refs look like "1.1" (Odyssey book 1 line 1), "17a" (Plato, Apology, Stephanus page), "1.1" (John 1:1), "77" (Gospel of Thomas, saying 77). When quoting, include the citation and the reader link.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Passage reference within the book, e.g. "1.1", "17a", "77". | |
| book | Yes | Book title or slug, e.g. "Odyssey", "Apology", "John", "Gospel of Thomas". See list_books. | |
| neighbor | No | Also return the passage right after or right before this one. Default none. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description goes well beyond that by disclosing the exact return structure (interlinear table, flowing English, editors' note, citation, reader links) and the hard cardinality cap of two passages per call. No contradiction with the read-only, non-open-world annotations.
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?
Purpose and payload are front-loaded in the first clause, and the ref-format examples are genuinely useful rather than filler. The middle runs a bit long as a single dense sentence, but nearly every clause carries routing or format 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?
With no output schema, the description must describe returns itself, and it does so comprehensively (interlinear fields, translation, note, citation, links). The cardinality limit and ref syntax examples close the remaining gaps an agent would need before calling it.
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 value by disambiguating what 'ref' means per book ('1.1' as Odyssey book/line vs. Platonic Stephanus page vs. John 1:1 vs. Thomas saying 77), which the schema does not. The neighbor enum and book lookup hint are already in the schema, so this is additive rather than exhaustive.
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 ('Returns ONE passage of a book as an interlinear') and enumerates exactly what the payload contains, from the word-by-word table to the reader links. This clearly distinguishes it from siblings list_books, lookup_word, and search, which return lists, single words, or query results rather than a full annotated passage.
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 for use (fetching/quoteready passage content, citing via the citation string and reader link) and an explicit exclusion ('never more than two passages per call; whole chapters or books are not available, by design'), which steers large-scope needs elsewhere. It stops short of naming an alternative tool for those broader needs, so the routing guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists the books in the Great Library Project, a free library of classic and ancient texts (Homer, Plato, the Gospels, Gnostic texts, Ugaritic myths, Dante and more) presented as interlinears: the original-language text with every word glossed in English beneath it, plus a flowing English translation. Returns each book's title, author, original language, how complete it is, why it matters, and links to its landing page and its word-by-word reader. Use this first to find the right book name for get_passage or search.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Optional filter on the original language, e.g. "Greek", "Coptic", "Latin", "Hebrew", "Portuguese". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered. The description adds real behavioral context beyond that by enumerating what each result contains (title, author, language, completeness, significance, landing-page and reader links), which matters because no output schema exists.
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-loaded with the core action and scope, and the long parenthetical author list is justifiable as corpus scoping rather than filler. Slightly verbose but no sentence is wasted.
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, the description compensates by describing the returned fields in detail, and it also covers the corpus definition and the tool's role in the workflow. An agent has everything needed to call and interpret this 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?
Schema description coverage is 100% for the single optional 'language' parameter, so the schema fully documents filtering. The description adds no filter syntax or examples of its own, making the baseline 3 appropriate here.
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 (Lists) and resource (the books), then concretely defines the corpus and the interlinear format. It is clearly distinguishable from siblings like get_passage, lookup_word, and search, which operate on individual passages or words.
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?
Ends with an explicit routing instruction: 'Use this first to find the right book name for get_passage or search.' This tells the agent both the sequencing (call before the others) and the alternatives, exactly what usage guidance should do.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Looks up an original-language word (mostly Ancient and Koine Greek; any accents are fine, a dictionary form works best, an inflected form usually works too). Returns the dictionary entry the library uses (headword, transliteration, part of speech, senses, etymology, and the named source lexicon such as LSJ or Autenrieth), and up to 10 places the word occurs across the library, each with a short line of context, the gloss at that spot, a citation and a link that opens the reader at that line.
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | Optional: prefer this book's dictionary entry and its occurrences first. | |
| word | Yes | The word, e.g. "πολύτροπος", "λόγος", "ἀρετή". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply readOnlyHint/openWorldHint, so the description carries the real burden — and it does, disclosing the entry fields returned (headword, transliteration, POS, senses, etymology, source lexicon like LSJ/Autenrieth) and the occurrence cap of 10 with context/gloss/citation/link. It stops short of describing error behavior for unsupported languages or the lexicon-selection logic.
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, front-loaded with the core action and the acceptable input forms before the return description. The second sentence is dense with parenthetical lists and runs long, but nearly every clause carries information an agent needs given there is no output schema.
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, the description compensates by enumerating the entry structure and the per-occurrence payload (context line, gloss, citation, reader link) plus the 10-occurrence cap. Combined with the input-form guidance and the named source lexicons, an agent has enough to call this correctly and interpret the result.
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 beyond the schema's bare example list: it specifies that `word` may be accented or inflected and that results are original-language lexical entries. It says nothing about the `book` parameter's precedence behavior, leaving that entirely to 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 ('Looks up an original-language word') and narrows the domain to Ancient/Koine Greek lexicon lookup, which separates it in spirit from the generic `search` sibling. It never explicitly contrasts itself with `search` or `get_passage`, so the differentiation is implicit rather than stated.
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 gives concrete input-shaping guidance: accents are tolerated, dictionary forms work best, inflected forms usually work. It does not say when to reach for this tool instead of `search` or `get_passage`, nor what happens with non-Greek input, so no exclusions or alternatives are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finds passages across the library (or in one book) whose English translation or original text contains the query. Returns up to 10 matches as references with one line of English and links; call get_passage to read a match word by word. Greek can be typed with or without accents.
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | Optional book title or slug to search within. | |
| limit | No | How many matches, 1 to 10. Default 5. | |
| query | Yes | Words to find, e.g. "unexamined life", "the Word", "Circe", "λόγος". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds real behavior beyond readOnlyHint/openWorldHint: it caps matches, defines the return shape (references with one line of English and links), and advises Greek input may be accented or not. Does not state pagination or whether limit above 10 is rejected, but is informative for a read-only search.
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, front-loaded with what is searched and what is returned, then the next-step routing and Greek note. No 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?
Covers purpose, result shape, and next step well enough for a simple 3-parameter search with no output schema. Could state the default limit or book-scope precedence, but nothing critical is missing.
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 explains query, book, and limit. The description adds only the Greek accent tolerance, which is modest extra meaning. Baseline 3 is appropriate.
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 (finds passages) plus the resource scope (library or one book) and match condition (English translation or original text contains query). A reader can distinguish it from get_passage, lookup_word, and list_books 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent onward: 'call get_passage to read a match word by word,' which distinguishes this discovery tool from the passage-reading sibling. No explicit statement of when not to use it versus lookup_word, but the context is clear.
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.
get_passagelist_bookslookup_wordsearchComplete classical & world literature — search + cite exact passages, facing sources, 50+ languages.
Bible study: many editions, Strong's Hebrew and Greek, cross-references, Matthew Henry, the Fathers
Read-only scripture-study engine: complete-or-fail concordance over Greek NT, Hebrew OT, LXX.
Search 15K rare pre-modern texts translated to English: philosophy, religion, science, literature.
Add one secure layer between your agents and this server.
