953 classic works in the original beside English: Greek, Latin, philosophy, literature, scripture
Scored across 6 tools
Each tool targets a clearly distinct task: reading Bible passages, listing editions, reading/searching a work, searching library metadata, visiting thematic rooms, and finding verse quotations. The only potential overlap between read_work's internal find and search_shelf is explicitly clarified in the descriptions.
Four tools follow a verb_noun pattern (get_passage, list_editions, read_work, search_shelf), but 'room' is a bare noun and 'who_read_verse' is an interrogative phrase rather than action-first. The set remains readable, but the naming convention is not fully predictable.
Six tools is well-scoped for a Bible and classical-library research server, with each tool mapping to a distinct operation. There are no filler tools, and the count is comfortably within a typical useful range.
The surface covers passage reading, edition discovery, work TOC/text/search, library metadata search, thematic passages, and verse quotation lookup. Minor gaps like browsing all works or keyword-searching Bible text are workable via search_shelf and read_work.
Read a Bible passage in one or more editions side by side (Hebrew WLC, Greek Septuagint, SBL Greek NT, English WEB/ASV/Douay-Rheims/Brenton, Russian Synodal, Luther 1912, Louis Segond). Verses are aligned to English numbering even where the Septuagint or Hebrew count differently.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | e.g. "JHN.1.1-5", "Genesis 14:18-20", "PSA.110" | |
| editions | No | Edition ids from list_editions, e.g. ["hebrew","lxx","en"]. Default ["en"]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that verses are aligned to English numbering despite differing Hebrew/Septuagint counts, but it does not describe output structure, error behavior, or limits for invalid edition ids.
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, front-loaded with the core purpose and followed by the important alignment caveat. The edition list is dense but earns its place because it tells the agent what kind of editions are available.
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 read-only passage retrieval tool with no output schema and no annotations, the description covers the essential purpose, supported editions, side-by-side behavior, and verse-alignment caveat. It stops short of explaining the return structure or error handling, but is largely complete for correct invocation.
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%, so the schema already documents both parameters well. The description adds value by listing supported edition names, but it does not map those names to the exact edition ids expected by the schema, so it only modestly exceeds the baseline.
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: 'Read a Bible passage.' It further narrows scope with 'one or more editions side by side' and enumerates supported edition families, making it clearly distinguishable from siblings like list_editions or search_shelf.
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 provides clear usage context: reading a Bible passage, optionally comparing multiple editions side by side. It does not explicitly name when to use this tool instead of siblings such as read_work or list_editions, and it gives no exclusions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Bible editions available, with ids, languages and book coverage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 indicates a read-only listing and names the fields returned, which is useful, but it does not mention permissions, rate limits, ordering, or that it is safe/non-destructive. For a zero-parameter listing tool this is adequate but thin.
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?
A single front-loaded sentence with zero waste. It states the action, resource, and key output fields without extraneous text.
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 zero-parameter listing tool with no output schema, the description is nearly complete: it says what is listed and which fields are returned. Minor gaps like ordering or pagination are unlikely to matter for this operation.
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 tool has zero parameters, so there is no parameter syntax to explain; the baseline is 4. The description adds no parameter-related detail, which is appropriate given the empty input 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 gives a specific verb and resource ('List the Bible editions available') and specifies the returned fields (ids, languages, book coverage). It does not explicitly differentiate from siblings like get_passage or read_work, but those tools operate on content rather than enumerating editions, so the resource is sufficiently clear.
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 explicit guidance on when to use this tool versus alternatives, nor any prerequisites or sequencing advice. The description implies a discovery/list operation, but an agent must infer that it may be useful before calling get_passage or read_work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a work from the shelf. Without a section: its table of contents (with paragraph counts). With a section: that section's text, original and translation row by row, up to ~24k characters; if truncated, call again with paragraph = next_paragraph to read on. With find: every row in the work (or in one section) containing that text, accent- and breathing-insensitive (e.g. find "αλοω κατα ποντον" or "worse than a brother"), with section and paragraph to read it.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| find | No | Text to find inside the work, in any of its languages. | |
| section | No | ||
| paragraph | No | Start reading the section at this paragraph (1-based). Default 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full burden and does it well: it discloses the ~24k character truncation limit, the exact resumption mechanism (paragraph = next_paragraph), the accent- and breathing-insensitive matching semantics with examples, and the shape of each return (TOC with paragraph counts; original/translation row by row with section and paragraph locators). There is no contradiction and no significant undisclosed 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 mode structure is front-loaded ('Without a section... With a section... With find...') and each clause maps to a parameter-driven behavior, so little is wasted. The sentences are dense and long, and the pagination detail is buried mid-sentence rather than given its own line, which slightly hurts scannability.
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 4-parameter, no-annotation, no-output-schema read tool, an agent has everything needed to invoke it: what each mode returns, the size cap, the continuation path, and match semantics. Only the id format remains unspecified, which is minor.
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 only 50% (id and section are undocumented in the schema), and the description compensates well: it explains what section does with and without, what paragraph means (start/next read point), and richly characterizes find (any language, accent/breathing-insensitive) with sample queries. The id parameter's expected format is still never stated in either place.
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 ('Read a work from the shelf') and then enumerates the three distinct behaviors keyed off section/find, so the agent knows exactly what comes back in each mode. It never differentiates itself from siblings like get_passage or search_shelf, which have obvious overlap, so it falls short of a 5.
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 explicit mode-selection guidance: no section → table of contents, section → text, find → search. It even handles the continuation case ('if truncated, call again with paragraph = next_paragraph'), which is real when-to-use instruction. However it gives no guidance on when to prefer this over search_shelf or get_passage, so cross-tool routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Enoch and Melchizedek rooms: every passage on the shelf that names Enoch or Melchizedek, with links.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose the scope ('every passage on the shelf', implying an exhaustive read) and that results include links, but says nothing about whether the call is read-only, how results are ordered, or roughly how many passages come back for a name as common as Enoch.
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?
A single front-loaded sentence with no filler, and the key scoping fact ('every passage on the shelf') arrives before the result format. The 'rooms' framing is a small indirection but costs almost nothing in length.
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 one-parameter lookup with no output schema, the description covers what is selected and that links are returned. What remains unclear is the relationship to search_shelf and the rough result shape/volume, which matters for an agent deciding between the two.
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?
Coverage is 0% but the single parameter is an enum whose two values, 'enoch' and 'melchizedek', are exactly the names the description enumerates. The mapping between the parameter and the returned passage set is unambiguous from the prose alone.
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 concretely what the tool returns: every shelf passage naming Enoch or Melchizedek, with links. The verb is implicit and the tool name 'room' is opaque on its own, but the body compensates. It does not distinguish this curated listing from the sibling search_shelf, which could plausibly do the same thing.
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 when-to-use guidance and no mention of alternatives. An agent must infer on its own whether to call this or search_shelf for topical passage retrieval, and nothing says whether the two overlap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the library of nearly a thousand works by title, author, translator, blurb or group: Homer, Plato, Thucydides, Plutarch, Virgil, Livy and the rest of the Greek and Latin classics in the original beside English; the Pali Canon; Dostoevsky, Tolstoy, Pushkin in Russian; Camus, Kafka, Goethe; Philo, Josephus, the Mishnah in Hebrew and English, 1-3 Enoch, Jubilees, the Church Fathers, Aquinas, Calvin, Kierkegaard, Nietzsche... To find a passage inside a work, use read_work with find.
| Name | Required | Description | Default |
|---|---|---|---|
| group | No | Optional group filter, e.g. "Hidden books", "Rabbinic", "Church Fathers", "Commentaries" | |
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does convey that the corpus is a fixed, curated catalogue (implying a read-only lookup), but is silent on result ordering, result limits/pagination, and what happens when query is omitted — notable since both parameters are optional and the tool would have to define a default.
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 actionable content is front-loaded in the first clause and the routing rule sits at the end, which is good. But the middle is a long author-by-author catalogue (Homer, Plato, Thucydides, Plutarch...) that could be compressed to a short statement of coverage; it aids relevance judgement but is padded well past what is needed.
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 two-optional-parameter search tool with no output schema and no annotations, the description covers scope, searchable fields and the sibling handoff, which is enough to invoke it correctly. Gaps are the return shape and the empty-query/no-results behaviour.
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 only 50% — 'query' has no schema description at all — and the description compensates by explaining that the free-text query matches across title, author, translator, blurb and group. That materially tells an agent how to phrase a query. It does not clarify how the free-text query interacts with the separate 'group' filter, which is the remaining 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?
States a specific verb and resource — search the library of ~1000 works — and enumerates the searchable fields (title, author, translator, blurb, group). The named handoff to read_work for in-text passage lookup makes it unambiguous versus the sibling that could be confused with it.
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?
Explicit routing rule: 'To find a passage inside a work, use read_work with find.' That is a concrete when-to-use-something-else condition. It doesn't address the other siblings (list_editions, get_passage, room) or say when a shelf search is unnecessary, so it stops short of full alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find who on the shelf (Church Fathers, rabbis, mystics, reformers, commentators, philosophers) quotes a given Bible verse, with the quotation and a link.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | A single verse, e.g. "MAT.5.39" or "John 1:1" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the load: 'Find' implies a read-only operation, and it usefully discloses the return shape (quotation plus link). However, it says nothing about result volume, pagination, ordering, or empty-result behavior for a lookup that could return many authors.
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?
One dense sentence with the verb and scope front-loaded and no filler. The parenthetical author list earns its place by scoping what 'shelf' means, though 'shelf' remains jargon not defined elsewhere in the description.
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 lookup with no output schema, the description covers what it does and what comes back (quotation plus link). The main gap is behavioral detail on result sets and coverage, but the essential call information is present.
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?
Single required parameter with 100% schema description coverage, so the schema already carries format guidance with examples. The description adds only the domain framing that 'ref' is a Bible verse, which is baseline for a one-param tool.
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?
Names a specific verb and resource (find who quotes a given Bible verse) and clarifies the scope of the 'shelf' with a parenthetical list of author categories. It implicitly distinguishes itself from get_passage/read_work, but never names those siblings to route the agent explicitly.
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?
Usage is only implied: pass a verse reference and get back quoters. There is no guidance on when to prefer this over get_passage (reading the verse) or search_shelf, and no note about coverage limits or what happens when no one quotes the verse.
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.
verify_quoteverify_quoteget_passagelist_editionsread_workroomsearch_shelfwho_read_verseComplete classical & world literature — search + cite exact passages, facing sources, 50+ languages.
Search 15K rare pre-modern texts translated to English: philosophy, religion, science, literature.
Free classics as interlinears: search the books, read any passage word by word, look up any word.
Classic books in 25 languages: search, print editions, the free shelf. Read-only, no sign-in.
Add one secure layer between your agents and this server.
