This server is a stdio bridge to the hosted VineVerse MCP server, exposing the Bible as a knowledge graph with 15 read-only tools for searching, retrieving, and exploring scripture, people, places, themes, lexemes, commandments, events, and graph relationships.
Search Scripture and concepts – search finds documents by metadata; search_scripture does full-text verse search over 31,102 verses.
Get passages and originals – get_passage fetches verses/ranges/chapters by OSIS reference; get_interlinear returns Hebrew/Aramaic/Greek word-by-word data.
Explore cross references – find_cross_references returns crowd-ranked references for a verse or chapter; get_connections analyzes the shape of the cross-reference corpus.
Retrieve entities – get_entity fetches any document (people, places, themes, lexemes, commandments, events, epochs, books, chapters, sources, datasets, schema) by path.
Genealogy and family – get_family returns parents, children, siblings, spouses, and generation-by-generation ancestors/descendants.
Geographic lookup – find_places_near finds biblical places within a radius of a known place or coordinates.
Graph exploration – get_graph_neighborhood returns everything within N hops of a document with typed/edge predicates.
Browse and discover – list_documents pages through collections; get_stats gives collection counts and categories; get_vocabulary explains relation predicates; get_tags lists document tags; get_changelog shows data version/ingestion time.
A stdio bridge to the hosted VineVerse MCP server — the Bible as a knowledge graph.
If your client speaks streamable HTTP, you do not need this package. Point it straight at the endpoint:
https://vineverse.bible/api/mcpNo API key, no account. This package exists for clients that can only launch a local process, and it does nothing except carry JSON-RPC messages between that process and the hosted server.
// claude_desktop_config.json, or any client's equivalent
{
"mcpServers": {
"vineverse": {
"command": "npx",
"args": ["-y", "github:DataCraftsmanAU/vineverse-mcp"]
}
}
}Or with Docker:
docker build -t vineverse-mcp .
docker run -i --rm vineverse-mcpNode 20 or newer. There are no dependencies.
Related MCP server: KARP Word Graph
One immutable corpus in Open Knowledge Format, built from
public-domain Scripture and openly licensed scholarship. get_stats returns the exact
document count and every collection; the figures below are the ones that do not drift:
Scripture | 31,102 verses of the Berean Standard Bible, 1,189 chapters, 66 books |
People | ~3,000, with recorded kinship |
Places | ~1,300, with coordinates |
Themes | ~3,000, from Nave's Topical Bible |
Lexemes | ~2,900 Strong's Hebrew entries, with interlinear alignment |
Law | the 613 commandments |
Narrative | ~450 events across ~165 dated epochs on Ussher's chronology |
Graph | 90,564 connections between documents — 147,002 directed edges |
Sources and their licences are listed at vineverse.bible/attribution. The MIT licence on this repository covers the bridge, not the corpus.
17, unchanged from the hosted server — this package neither adds nor filters any.
Tool | What it does |
| Search every document by name, description, tag, path and type |
| Full-text search across all 31,102 verses |
| A verse, verse range or whole chapter by OSIS reference |
| The Hebrew, Aramaic or Greek behind the English, word by word |
| Cross references for a verse or chapter, ordered by crowd support |
| Any document by path — |
| Parents, children, siblings and spouses, to any depth |
| Biblical places within a radius, nearest first, in km |
| The shape of the cross-reference corpus — hubs, clusters, bridges |
| Everything within N hops of a document, with the predicate on each edge |
| Browse or page through any collection |
| Every collection with its document count, folder and an example path |
| The closed predicate set every typed edge is drawn from |
| Every tag with the number of documents carrying it |
| The knowledge base's own log, and when the data was ingested |
| Availability over the last 24/30/90 days, and which optional datasets are built |
| Who runs the site, what it costs to run, and the donation link |
The server advertises one resource, vineverse://support — who runs it, what it costs, and
where the surplus goes. It is annotated audience: ["user"], which is the spec's way of
saying it is addressed to the human rather than the model. Like the tools, it is forwarded
untouched, so a stdio client that reads resources will see it too.
VineVerse is free, keyless and ad-free, and it runs on donations. MCP traffic reaches the
endpoint but rarely the site itself, so someone who only ever talks to a client may never see
a link to it. get_support and vineverse://support close that gap: the server states that
the site is donation-funded, and the model hands the link at
vineverse.bible/support to the person who can actually
give.
| Endpoint to bridge to. Defaults to |
Useful for running against a local checkout of the site:
VINEVERSE_MCP_URL=http://localhost:3100/api/mcp node index.jsnpm run build # syntax check — there is nothing to compile
npm testThe test spawns the bridge as a real child process rather than importing the module, because
two of the four things being checked — that a notification draws no reply, and that the
process exits 0 without truncating a response — are properties of the process, not of any
function in it. It drives initialize, notifications/initialized and tools/list over
real stdio, then a get_passage call for John 3:16. It talks to the live endpoint, so a
failure means either the bridge or the hosted server.
CI runs both on every push and weekly on a schedule, against Node 20 and 24. The scheduled run is deliberate: because the test talks to the live endpoint, a green badge on a repository that has not changed in months still means the server answers today.
build exists because hosted builders (Glama among them) run install then build
unconditionally. Rather than a no-op, it runs node --check, which is the only meaningful
build step a dependency-free single file has.
Cross references for a verse or chapter, ordered by crowd support. The underlying corpus records THAT two passages are connected but never WHY, so these carry no relationship type — do not infer one. Chapter documents materialise only references at or above 20 votes, so a lower minVotes does not widen the result; the complete 341,289-row corpus ships as a dataset at references/cross-references.
| Name | Required | Description | Default |
|---|---|---|---|
| osis | Yes | OSIS reference, e.g. "John.3.16" | |
| limit | No | How many references to return, highest-voted first. Defaults to 100, capped at 500. | |
| offset | No | For paging; compare with `total` in the response. | |
| minVotes | No | Minimum crowd support. 20 is the bundle floor. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| osis | Yes | |
| count | Yes | |
| total | Yes | |
| offset | Yes | |
| licence | No | |
| minVotes | Yes | |
| threshold | Yes | |
| references | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite having readOnlyHint, idempotentHint, and destructiveHint annotations, the description adds substantial non-obvious behavior: the corpus records only that passages are connected, never why, so no relationship type should be inferred. It also discloses the 20-vote materialization floor and the result limitation, which materially changes how an agent should reason about minVotes. This goes well beyond what annotations alone provide.
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?
Three sentences carry the main purpose, a critical inferential caveat, and a data-materialization warning with no filler or repetition. The most important information is front-loaded, and every clause earns its place. It is dense but immediately scannable.
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 tool with a full input schema and an output schema, the description covers all the unusual aspects an agent needs to know: ordering, absence of relationship types, minVotes floor behavior, and where to get the full corpus. Nothing important that is not already in the structured metadata 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?
The input schema already documents all four parameters with 100% coverage, so the baseline is 3. The description adds meaningful semantics beyond the schema: minVotes has a hard materialization floor, osis is scoped to verses or chapters, and results are ordered by crowd support rather than arbitrary relevance. It does not add much detail about offset/limit or output, but the schema already covers those.
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: it returns cross references for a verse or chapter, ordered by crowd support. This makes the tool distinct from sibling tools by pinpointing exactly what is returned, rather than restating the title. The nuance that entries carry no relationship type further sharpens what the tool is and is not able to provide.
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 a clear usage context: use this for verse/chapter cross references and explains that lowering minVotes will not produce more results below the materialized floor. It also directs agents wanting the full corpus to the bundled dataset, which is an explicit exclusion. It does not explicitly compare against get_connections or other sibling tools, so a perfect score is not warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Biblical places within a radius, nearest first, with the distance in kilometres. Anchor it on a place already in the knowledge base, or on a bare latitude and longitude when you are asking about a modern location that has no document here.
~1,300 places carry coordinates. Many sites are identified only tentatively — check contested and identifications on the place document before treating a position as settled.
total counts everything inside the radius, which a wide one puts well beyond a single page — walk the rest with offset, not by raising the radius.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Anchor latitude, if no place is given. | |
| lon | No | Longitude in decimal degrees. Must be given together with `lat`, and instead of `place`. | |
| limit | No | How many places to return, nearest first. Defaults to 25, capped at 200. | |
| place | No | Anchor place path, e.g. "places/jerusalem" | |
| offset | No | For paging; compare with `total` in the response. A wide radius holds far more than one page. | |
| radius | No | Kilometres. 50 by default. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | Yes | |
| total | Yes | |
| centre | Yes | |
| offset | Yes | |
| origin | No | |
| licence | No | |
| results | Yes | |
| radiusKm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only annotations already cover safety, but the description adds important non-obvious behavior: many place coordinates are tentative, so agents should inspect `contested` and `identifications` before trusting positions. It also transparently explains that `total` may exceed one page and that `offset`, not an enlarged radius, is the correct way to page.
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, front-loaded, and free of filler. Each paragraph serves a distinct purpose: core behavior, data-quality caveats, and pagination guidance. Every sentence contributes to safe and effective use.
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 a rich input schema, an output schema, and read-only annotations, the only missing pieces are behavioral context and procedural cautions. The description supplies those thoroughly: result ordering, distance units, tentative-identification caution, and offset-based paging. The tool is fully actionable as written.
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 already documents all six parameters at 100% coverage, so the baseline is high. The description adds contextual value beyond the schema by explaining that lat/lon is for modern locations lacking a place document and that a wide radius makes pagination behavior important.
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 opening sentence states the exact action: return biblical places within a radius, sorted nearest first, with distance in kilometres. This is a specific verb+resource+scope and clearly separates it from the sibling tools, none of which do geospatial radius queries.
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 tells when to use a known place anchor versus a bare lat/lon, i.e., for modern locations not present in the knowledge base. It does not name alternative sibling tools, but no sibling appears to cover the same capability, so the guidance is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The knowledge base's own log file, plus when the data was actually ingested. Use bundleGenerated to answer "how current is this" or to cite a version — the generated field on get_stats is when this server built its in-memory index and changes on every restart, which is a fact about the process rather than the data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| log | Yes | |
| url | Yes | |
| note | No | |
| licence | No | |
| indexBuilt | Yes | |
| okfVersion | No | |
| bundleGenerated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the operation read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining that `generated` in get_stats changes on every restart and reflects the process rather than the data, which helps the agent avoid misinterpreting the values. It could go further by describing the exact shape of the returned log, but the output schema already covers that.
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 entire description is one tight, information-dense sentence. It front-loads the resource, then provides a concrete use case, then a precise contrast with get_stats. Every clause earns its place: no filler, no repetition, and the crucial disambiguation appears before the sentence ends.
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 parameters, full schema coverage, robust annotations, and an output schema, the description has a narrow job: telling the agent what the result means and when to use it. It explains the purpose, the key field `bundleGenerated`, and the distinction from get_stats' `generated` field. There is no critical missing guidance for someone deciding whether to call this tool or how to interpret its output.
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 baseline 4 applies. The input schema covers 100% of parameter documentation and there is nothing for the description to add. The description focuses instead on output semantics, which is the appropriate place to provide value.
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 that this tool returns the knowledge base's own log file plus the actual data ingest time, and introduces the `bundleGenerated` field by name. It explicitly differentiates from get_stats' `generated` field, which describes a process fact rather than data freshness.
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 when to use this tool: when the agent needs to answer how current the data is or cite a version, use `bundleGenerated`. It also directly contrasts get_stats' `generated` field, providing a clear decision rule between this tool and a sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Questions about the SHAPE of the cross-reference corpus rather than about one verse: which chapters are the hubs, which books lean on which, how much referencing crosses between the testaments.
With no argument, returns the totals plus the most-connected chapters and the strongest book-to-book pairs. Pass book for one book’s own incoming and outgoing rows, or osis for a single chapter’s rank and vote weight. Use find_cross_references instead when you want the actual references for a passage.
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | One book, by OSIS id or slug, e.g. "John". | |
| osis | No | One chapter, e.g. "Ps.119". | |
| limit | No | How many rows per ranked list. Defaults to 20, capped at 200. | |
| offset | No | For paging, applied to every ranked list in the response. Each list carries its own total — topChaptersTotal, topBookPairsTotal, referencesOutTotal, referencesInTotal. |
| Name | Required | Description |
|---|---|---|
| book | No | |
| note | No | |
| error | No | |
| offset | No | |
| totals | No | |
| chapter | No | |
| licence | No | |
| topChapters | No | |
| referencesIn | No | |
| topBookPairs | No | |
| referencesOut | No | |
| topChaptersCount | No | |
| topChaptersTotal | No | |
| referencesInCount | No | |
| referencesInTotal | No | |
| topBookPairsCount | No | |
| topBookPairsTotal | No | |
| referencesOutCount | No | |
| referencesOutTotal | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context: no argument returns totals and leading hubs/pairs, book returns incoming and outgoing rows, and osis returns a single chapter’s rank and vote weight. It is honest and consistent with the annotations, though it does not mention any rate limits or query-specific caveats.
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 efficient: two short paragraphs, each sentence earns its place, and the differentiating clause comes first. It front-loads the core concepts and immediately points to the sibling tool for alternative use.
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 presence of an output schema, four non-required parameters, and comprehensive annotations, the description is sufficient for an agent to select and invoke the tool correctly. It covers all invocation modes, tells the read-only nature through annotations, and provides the routing rule to find_cross_references. Nothing essential 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?
The schema already documents all four parameters with descriptions, list, and default, so the schema is doing heavy lifting. The description adds value by mapping book and osis to the kind of aggregate vs. table vs. single-chapter response. It does not repeat parameter syntax and leaves limit/offset details 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: it answers questions about the SHAPE of the cross-reference corpus, not individual verse references. It enumerates concrete examples like hub chapters, book-to-book leanings, and cross-testament referencing. It also distinguishes itself from find_cross_references, which is for actual passage references.
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 says precisely when to use this tool: for aggregate corpus questions rather than one passage. It also names the alternative, find_cross_references, and gives the exact condition for choosing it. It clarifies the three call modes: no argument, book, or osis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch any document in the knowledge base by path: People — people/moses Places — places/bethel-1 Themes — themes/faith Lexemes — lexemes/h430 Commandments — commandments/001-know-there-is-a-g-d Events — sa/events/exodus-from-egypt Epochs — epochs/david-reigns-in-jerusalem Books — bible/john Chapters — bible/john/3 Sources — sources/bibledata Datasets — references/cross-references Schema — schema/relations
Returns the document's structured fields, its typed relations in BOTH directions, what links to it, and optionally its full text. The inbound direction matters: the corpus stores each relation once, on one side only, so a person's parents live on their parents' documents and only relations.inbound recovers them.
Set body=true for the prose — a lexeme's Strong's definition, a commandment's Hebrew, a theme's outline of verses all live in the body and nowhere else.
Where several people or places share a name the path is disambiguated with a number (people/zechariah-14, places/bethel-1) — search_concepts first if unsure. A collection path like "themes" or "sources" returns what that collection holds.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Include the full markdown body. Default false. | |
| path | Yes | Document path, e.g. "people/moses", "themes/faith", "lexemes/h430", "epochs/the-exile" | |
| backlinks | No | How many backlinks to return, 100 by default. `backlinkCount` always reports the true total and `backlinksTruncated` says whether you are seeing all of it. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| lat | No | |
| lon | No | |
| body | No | |
| note | No | |
| osis | No | |
| tags | No | |
| type | Yes | |
| count | No | |
| links | No | |
| stale | No | |
| title | Yes | |
| words | No | |
| degree | No | |
| sample | No | |
| status | No | |
| licence | No | |
| sources | No | |
| strongs | No | |
| backlinks | No | |
| extension | No | |
| generated | No | |
| linkCount | No | |
| relations | No | |
| trustTier | No | |
| collection | No | |
| shareAlike | No | |
| description | No | |
| backlinkCount | No | |
| backlinksTruncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond already-strong annotations (readOnly, idempotent), the description reveals genuinely non-obvious behavior: relations are stored only on one side, so inbound relations must be requested explicitly; body content exists only when body=true; collection paths return collection contents. It even explains the path layout for the ambiguous corpus. This is real behavioral value above and beyond the structured fields.
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?
Despite covering many path types and edge cases, the description remains well-structured and purposeful. The path examples are front-loaded, the behaviors are clearly separated, and no sentence is filler. The length is justified by the breadth of document types the tool must address.
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?
This description is remarkably complete for a path-based fetch tool. Together with full parameter schema coverage, strong readOnly/idempotent annotations, and an output schema, the description already handles path disambiguation, collection behavior, body requirements, relation-direction semantics, and alternative routes when the path is uncertain. Little is left for the agent to guess.
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 already strong. The description adds additional semantic meaning for path: an extensive set of valid path prefixes, the fact that a collection path returns whatever that collection holds, and meaningful examples of when body=true is required for prose that is not available elsewhere. It does not deepen the meaning of backlinks much, but the schema description already handles that well.
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 clear, specific verb and resource: 'Fetch any document in the knowledge base by path.' It then enumerates the exact path categories it covers and states exactly what is returned (structured fields, relations in both directions, links, optional body). It also distinguishes itself from one sibling by routing ambiguous lookups to search_concepts.
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 on when this tool fits — fetching path-based documents, collections, and documents with prose — and explicitly recommends search_concepts first when paths are ambiguous. It lacks explicit exclusions or direct comparisons with other sibling tools like get_graph_neighborhood or get_family, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parents, children, siblings and spouses for any person, and with generations above 1 the line of descent — ancestors and descendants gathered one generation at a time. This is the tool for a genealogy, lineage or ancestry question: "who were Boaz's ancestors", "trace David's line", "who did Ruth marry".
Use this rather than reading relations off get_entity. The corpus contains no child-of edge at all — parentage is recorded only on the parent's document — so a person's own parent-of relations are their CHILDREN, and reading them as parents inverts the family tree. This tool does the inversion.
Called family rather than genealogy because it returns kinship as well as descent, and because two other things here own that word. The 680 ancestor-of edges assert descent across an unknown number of generations, so they cannot be composed into a generation-by-generation tree and are excluded from this one — read them off get_entity if you want them. And the genealogy PASSAGES — Genesis 5 and 10, Ruth 4, Matthew 1, Luke 3 — are indexed as a theme at themes/genealogy.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Person path, e.g. "people/moses" | |
| generations | No | Above 1, also returns ancestors and descendants generation by generation. |
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| person | No | |
| licence | No | |
| parents | No | |
| spouses | No | |
| children | No | |
| siblings | No | |
| ancestors | No | |
| descendants | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior, so no contradiction. The description adds crucial behavioral context not visible in the schema: the corpus stores parentage only on the parent's document, so get_family performs a needed inversion. It also discloses the limitation that ancestor-of edges are excluded because they cannot be composed into a generation-by-generation tree. This is exactly the hidden-behavior disclosure an agent needs.
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 the core purpose and then gives only behaviorally important details: the inversion gotcha, the excluded edge type, and where to find alternative data. It is a bit long for a tool description, but every sentence adds decision-relevant value for an agent, so the length is earned rather than padded.
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 tool has a rich output schema, full parameter coverage, and safety annotations, the description completes the picture by clarifying scope, distinguishing from sibling tools, exposing a critical data-model quirk, and offering fallback slices for excluded data. An agent has enough context to select and invoke this tool correctly without further investigation.
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 input schema covers 100% of parameters, so the baseline is 3. The description adds meaningful semantics for the `generations` parameter by explaining it gathers ancestors and descendants one generation at a time, which clarifies the traversal ordering. The `path` usage is reinforced with example like do people/moses and the genealogy question examples map naturally onto parameters.
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 names a clear verb and resource (get a person's family and line of descent) and enumerates the specific relationship types returned: parents, children, siblings, spouses, and optionally ancestors/descendants. It explicitly distinguishes itself from get_entity and from genealogy-related indexes, so an agent can accurately differentiate it among siblings.
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 explicit when-to-use guidance: use it for genealogy, lineage, or ancestry questions, with concrete example queries. It also states when not to rely on it, directing the agent to get_entity for the 680 ancestor-of edges and to themes/genealogy for genealogical passages. This is strong alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything within N hops of a document, WITH the edges that connect them and the predicate on each. Useful for asking what a passage, person or theme is connected to without fetching each document.
Filter with type to ask a shaped question — the places near an event, the people in an epoch — and with predicate to keep only one kind of edge. Depth 1 is direct links; depth 3 gets large quickly and is capped. See get_vocabulary for what each predicate means.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Document path, e.g. "people/david" or "themes/faith" | |
| type | No | Keep only neighbours of this type: Person, Place, Theme, Lexeme, Commandment, Event, Epoch, Book, Chapter, Source, Dataset, Relation Vocabulary. | |
| depth | No | How many hops out from the starting document. Defaults to 1. Capped at 3 — the graph fans out fast. | |
| limit | No | Cap on nodes returned. Defaults to 200, capped at 600. The response sets `truncated` when it bites. | |
| offset | No | For paging the node list, in the walk order the response returns. Edges are those internal to the page, so one that spans a page boundary appears on neither — fetch the neighbourhood in a single call if you need the edges whole. | |
| predicate | No | Keep only edges with this predicate, e.g. "develops". |
| Name | Required | Description |
|---|---|---|
| note | No | |
| root | Yes | |
| count | Yes | |
| depth | Yes | |
| edges | Yes | |
| nodes | Yes | |
| total | Yes | |
| offset | Yes | |
| licence | No | |
| edgeCount | Yes | |
| truncated | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior, so the description correctly focuses on extra behavioral specifics: depth cap at 3 with quick fan-out, limit default/cap of 200/600, the `truncated` response signal, and the offset edge/page-boundary caveat that edges crossing pages are omitted. These are non-obvious runtime behaviors the agent needs to know.
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?
Three sentences pack a lot of information without redundancy: the first establishes the core capability, the second gives parameter-level usage, and the third explains depth scaling and vocabulary reference. Everything earns its place.
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 has an output schema and detailed param descriptions, so the description doesn't need to explain return values. It covers scope filtering, predicate filtering, depth scaling, pagination behavior, edge truncation, and cross-references to vocabulary, fully enough for the parameters and complexity.
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 baseline is 3. The description adds extra semantics above that baseline: the `type` filter is illustrated with concrete use cases ('the places near an event, the people in an epoch') and `predicate` is linked to get_vocabulary for meaning. These examples give the agent a better mental model than the schema 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 opens with a precise definition: 'Everything within N hops of a document, WITH the edges that connect them and the predicate on each.' This clearly identifies the verb, resource (graph neighborhood), and what makes it unique (edges plus predicates), distinguishing it from generic fetch/query tools like get_entity or find_cross_references.
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 use-case context: 'useful for asking what a passage, person or theme is connected to without fetching each document,' and explains filtering with `type` and `predicate`. It also points to get_vocabulary as a related reference. It stops short of explicitly stating when *not* to use this tool vs. very close siblings like get_connections or find_places_near, so it does not fully satisfy the when-not/alternatives bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Hebrew, Aramaic or Greek behind the English, word by word, for one verse or a whole chapter. This is a REVERSE interlinear: entries are in English order and each carries the range of English words it produced, so a word in the translation can be traced to the word it renders. Each entry gives the original, its transliteration, its morphology spelled out, and its Strong’s number; lexeme is present only where the bundle carries a document for that number — the lexicon holds the words that spell a biblical name plus their roots, not all 8,674 Strong’s entries, and there is no Greek lexicon at all. Five verses carry no data because the two Berean editions disagree about their wording; they are named in the changelog.
| Name | Required | Description | Default |
|---|---|---|---|
| osis | Yes | OSIS reference — a verse ("John.3.16") or a whole chapter ("John.3") |
| Name | Required | Description |
|---|---|---|
| verses | Yes | |
| licence | No | |
| reference | Yes | |
| translation | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations by disclosing meaningful behavior: entries are in English order, lexeme presence is conditional, the Greek lexicon is absent, and some verses are skipped due to Berean edition disagreement. This is exactly the kind of behavioral context an AI agent needs.
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 dense but front-loaded and every clause earns its place: the main purpose, the reverse-interlinear ordering, entry fields, and data availability limitations. It is long because the domain is complex, not because it repeats information already in quick access.
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 output schema, annotations, and the one documented parameter, the description covers all important edge cases and expectations: what each entry contains, when lexeme is omitted, the lexicon scope, and the five verses with no data. It points to the changelog for those verse names, which is the right mechanism.
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 already fully documents the single required parameter, osis, with explicit verse/chapter examples. The description restates 'one verse or whole chapter' but does not add materially new parameter guidance, so it meets the baseline for high schema coverage.
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 exactly what the tool does: it returns the Hebrew/Aramaic/Greek original-language words behind an English passage, word by word, as a REVERSE interlinear. This distinguishes it clearly from sibling text access tools like get_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?
The description gives clear context for when to call the tool — for a single verse or whole chapter when the original-language form and grammatical details are wanted. It does not explicitly name alternatives or exclusions, but the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a verse, a verse range or a whole chapter by OSIS reference. One verse: "John.3.16". A range: "John.3.16-18". A chapter: "John.3".
A verse or range comes back with its context: who is speaking, which people and places each verse names, which THEMES it develops, its cross references, and what points at it — the commandments stated there, the events and epochs narrated there. That context is the main way into the topical side of the knowledge base from a passage.
Text is the Berean Standard Bible. Sixteen verses are intentionally empty where the Berean edition omits them on manuscript grounds; the verse number is still present so numbering matches other translations.
| Name | Required | Description | Default |
|---|---|---|---|
| osis | Yes | OSIS reference: "John.3.16", "John.3.16-18", "Ps.23" or "1Sam.17.45" |
| Name | Required | Description |
|---|---|---|
| id | No | |
| url | No | |
| book | Yes | |
| next | No | |
| note | No | |
| osis | Yes | |
| text | No | |
| verses | Yes | |
| chapter | No | |
| context | No | |
| licence | No | |
| omitted | No | |
| previous | No | |
| speakers | No | |
| backlinks | No | |
| reference | No | |
| relations | No | |
| verseCount | No | |
| translation | No | |
| backlinkCount | No | |
| omittedVerses | No | |
| versification | No | |
| backlinksTruncated | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only and idempotent, and the description adds meaningful behavioral context: the exact text source (Berean Standard Bible), the intentional presence of empty verses for manuscript reasons, and the rich contextual payload returned with verses/ranges. This goes beyond what annotations alone convey.
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 well-organized in three short paragraphs: what is fetched, what comes back with it, and important translation-specific behavior. Every sentence contributes useful information, with examples front-loaded for immediate comprehension.
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 single-parameter read-only tool with an output schema, this description is complete: it defines accepted reference forms, explains the enrichment context returned, notes the Bible translation used, and discloses the empty-verse edge case. No important call-correctness fact omitted.
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% and already provides representative OSIS refs for verse, range, and chapter. The description mostly restates the same examples in prose, so it adds limited new meaning beyond 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 names a specific verb ('Fetch') with a specific resource ('a verse, a verse range or a whole chapter by OSIS reference') and gives concrete reference syntax. This clearly differentiates the tool from search-oriented siblings and makes its function immediately obvious.
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 describes when to use the tool for exact OSIS-based passage retrieval and explains that the returned context is 'the main way into the topical side of the knowledge base from a passage.' It does not explicitly contrast with sibling tools like search_scripture, but the intended use is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The catalogue: every collection with its document count, its folder, an example path and what it contains, plus graph totals, the most common tags and the licences the data is available under. Call this first if you do not know what the knowledge base holds — it is the map to every other tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| books | Yes | |
| edges | Yes | |
| notes | Yes | |
| types | Yes | |
| words | Yes | |
| verses | Yes | |
| licence | No | |
| orphans | Yes | |
| topTags | Yes | |
| chapters | Yes | |
| edgesNote | No | |
| generated | Yes | |
| okfVersion | No | |
| brokenLinks | Yes | |
| collections | Yes | |
| connections | Yes | |
| conceptEdges | Yes | |
| uncatalogued | No | |
| generatedNote | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish this as read-only, idempotent, and non-destructive. The description adds useful context about the tool's role as an orientation map and enumerates the kind of content returned, which is relevant behavioral context for an agent deciding whether to call this before other tools.
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, front-loaded with the main identity, and every phrase earns its place. Ending with the 'map to every other tool' framing is both useful and memorable without adding unnecessary 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 no-parameter, read-only overview tool with annotations and an output schema already available, the description is complete. It tells the agent what the tool surfaces, why it matters, and when to call it first.
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 surface for the description to clarify. The schema confirms this with an empty properties object, and the description does not need to compensate; the baseline of 4 applies.
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 identifies the tool as a catalogue/overview of the entire knowledge base, including document counts, folders, example paths, tags, and licences. It distinguishes itself from content-specific siblings by framing itself as 'the map to every other tool.' The title reinforces the purpose, and the description goes beyond a mere label.
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 to call this tool first when the agent does not know what the knowledge base holds. It gives clear contextual guidance for the main use case, though it does not name specific alternatives or state when it should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Whether this service is up, what its availability has been over the last 24 hours, 30 and 90 days, and the target it is measured against. Also reports which optional datasets this deployment has built: get_interlinear and get_connections fail with dataset_unavailable when theirs is missing, and this is how to check before calling rather than after failing.
The target is best-effort and carries no service credits, this being a free site, which the response states rather than implies.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| sla | Yes | |
| status | Yes | |
| uptime | Yes | |
| datasets | Yes | |
| checkedAt | Yes | |
| components | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description add meaningful behavior beyond annotations: the availability target is best-effort and has no service credits, and the response explicitly states this rather than implying it. It also reveals a critical behavioral truth about how dataset availability affects sibling tools.
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 dense but every sentence earns its place: hitting scope, time windows, target expectations, dataset availability behavior, and an important caveat. It wastes no words on redundant restating of the title.
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 zero-parameter, read-only status tool with an output schema, nothing important is missing. The description is sufficient for an agent to invoke the tool and correctly interpret what the dataset check enables.
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?
With zero parameters, there are no parameter semantics the description must clarify. The description still helps by stating what the tool reports, giving the agent a complete idea of the response's meaning without relying on the output schema 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 a specific verb and resource: it reports service uptime, historical availability over 24 hours/30/90 days, target expectations, and which optional datasets are built. It distinguishes itself by positioning get_status as the pre-check for get_interlinear and get_connections, whose failure mode is explicitly named.
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 tells the agent when to use this tool: check get_status before calling get_interlinear or get_connections, since those tools fail with `dataset_unavailable` when the dataset is absent. That is concrete, actionable guidance for an otherwise simple status tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The site behind this server is free, keyless, carries no advertising, and is funded by donations. Call this once per conversation, when the user has clearly got value out of the data or has asked who runs this, what it costs to run, or how to help - then pass the url from the result on to them, since it is a person who can give and not the model. Do not call it again later in the same conversation, and do not bring up giving when a call has merely answered a factual question.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| free | Yes | |
| note | Yes | |
| costs | Yes | |
| ledger | Yes | |
| charity | Yes | |
| kofiUrl | Yes | |
| licence | No | |
| metered | Yes | |
| currency | Yes | |
| attribution | Yes | |
| agentPayable | Yes | |
| donationFunded | Yes | |
| creditCardRequired | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive, but the description adds important conversational behavior: call once, pass the URL, and avoid unsolicited donation prompts. This contextual transparency goes well beyond the structured hints.
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 somewhat long but every clause carries operational value: background model, trigger condition, required action, and two restictions. The key 'call once' instruction is front-loaded.
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 zero-parameter tool with an output schema already present, the description covers the missing context: when to call, what to pass back, and how to avoid overuse. It is complete enough 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?
The input schema has zero properties, so there is no parameter meaning that the description must clarify. Baseline 4 applies because there is nothing to document.
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?
Opens by establishing the support/donation context and explicitly tells the agent to call the tool and pass the `url` from the result. The title and description together clearly identify this as the support-info tool, distinct from the mostly data-retrieval sibling tools.
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?
Provides exact trigger conditions: after the user has clearly got value, or when they ask who runs it, what it costs, or how to help. Also gives clear negative guidance: not to call again and not to raise giving after a factual query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tag in the bundle with the number of documents carrying it, most common first. Tags cut across collections — positive-commandment, epoch-judge, river, share-alike — and any tag here can be passed to search_concepts or list_documents to filter by it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many tags to return. Defaults to 200, capped at 1000. | |
| offset | No | Skip this many before returning. Tags come back most-used first. |
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| count | Yes | |
| total | Yes | |
| offset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare read-only, idempotent, and non-destructive behavior. The description adds value by disclosing the output scope, ordering, and cross-collection nature of tags, which is beyond what the annotations alone tell the agent.
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 focused sentences convey purpose, output shape, ordering, cross-collection scope, and downstream usage. There is no filler or redundant restatement of the tool name.
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 simple, has no required parameters, has fully documented parameters, is backed by read-only annotations, and has an output schema. The description and structured metadata together are sufficient for an agent to select and invoke it appropriately.
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 already documents both parameters fully, including limits, defaults, and ordering implications, so the description need not repeat them. The description reinforces ordering but adds little semantic detail beyond 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: it lists every tag in the bundle with document counts, ordered by frequency. It also gives concrete examples and explains how the tags connect to other tools, which clearly distinguishes it from general vocabulary or search tools.
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 explains that tags returned here can be passed to search_concepts or list_documents for filtering, giving clear downstream usage context. It does not explicitly contrast get_tags with sibling tools like get_vocabulary or get_stats, but the intended use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The closed set of predicates every typed edge in the graph is drawn from — what develops, narrated-in, involves, stated-in and named-by mean, what their inverses are, which types they connect, and how many edges use each. Also returns the 66-book canon table with OSIS ids, slugs and chapter counts, which is how you find out that Song of Songs is "Song" before building a reference.
Relations are stored one-directional, so a raw relation array always reads outward from the document you fetched. Read this before interpreting a predicate.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| note | No | |
| books | Yes | |
| licence | No | |
| predicates | Yes | |
| undeclared | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations mark the tool as read-only and idempotent, and the description goes further by revealing a non-obvious behavioral trait: relations are stored one-directionally, so raw relation arrays always read outward from the fetched document. It also emphasizes the vocabulary is a closed set, which is contextual data behavior beyond the structured fields.
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?
Every sentence in the description provides necessary information: the predicate vocabulary, the canon table, the directionality caveat, and the usage pointer. It is front-loaded with the most critical content and contains no repetition or 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?
Given that an output schema exists and annotations cover the read-only safety profile, the description supplies all needed behavioral context: what the returned data contains, how predicates are organized, a concrete example (Song), and a crucial directionality warning. An agent can decide when and how to invoke it 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?
The input schema has zero parameters, so the baseline of 4 applies. The description correctly adds no unnecessary parameter details because there are none to clarify.
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 names a concrete resource: the closed set of graph predicates and the canon table, including their meanings, inverses, and usage counts. This clearly differentiates it from all sibling tools, which focus on references, entities, connections, passages, or searches.
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 communicates when to use the tool: 'Read this before interpreting a predicate' and before building a reference against the canon table (e.g., finding the OSIS slug 'Song'). It does not explicitly name a sibling alternative, but given that no sibling covers vocabulary/canon data, this is a clear enough use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse or page through any collection in the knowledge base. This is the tool to reach for when you want to know WHAT EXISTS rather than to look one thing up — "what events are recorded", "list the epochs in order", "show me the 613 commandments".
Collections: Person (people/), Place (places/), Theme (themes/), Lexeme (lexemes/), Commandment (commandments/), Event (sa/events/), Epoch (epochs/), Book (bible/), Chapter (bible/), Source (sources/), Dataset (references/), Relation Vocabulary (schema/).
Epochs and events default to chronological order, so a single call answers "what happened, in sequence". Everything else defaults to alphabetical. Use offset with total to page: the response says how many matched and whether more remain.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Only documents carrying this tag. See get_tags for the vocabulary. | |
| sort | No | title = alphabetical; degree = most-connected first; canonical = Bible order; chronological = by start year (epochs) or narrative order (events). | |
| type | No | Collection to list. One of: Person, Place, Theme, Lexeme, Commandment, Event, Epoch, Book, Chapter, Source, Dataset, Relation Vocabulary. Plurals and folder names also work ("themes", "sa/events"). Omit to list everything. | |
| limit | No | How many to return. Defaults to 50, capped at 200. | |
| folder | No | Restrict by bundle folder prefix, e.g. "bible/john" for one book's chapters. This is the only way to scope a listing by path rather than by type — Books and Chapters share the bible/ folder, so `type` cannot express it. | |
| offset | No | Skip this many before returning. Use with `total` in the response to page. |
| Name | Required | Description |
|---|---|---|
| tag | No | |
| note | No | |
| sort | No | |
| type | No | |
| count | No | |
| error | No | |
| total | No | |
| offset | No | |
| hasMore | No | |
| licence | No | |
| results | No | |
| available | No | |
| collection | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate read-only, idempotent, non-destructive behavior. The description goes well beyond this by stating default sort orders (chronological for epochs/events, alphabetical otherwise), how to page using offset and total, and that the response reports whether more items remain. These behaviors meaningfully guide an agent without repeating the 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?
The description is well-organized: purpose and usage are front-loaded, the collection inventory is compactly listed, and a short paragraph covers ordering and paging. Every section earns its place and supports either selecting the tool or invoking it correctly.
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, 6-parameter listing tool with an output schema present and no required parameters, the description covers what collections exist, how ordering works, how pagination works, and how folder scoping behaves. It also points to complementary tools like get_tags for the tag vocabulary. No important operational gap remains.
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 input schema already covers 100% of parameters, so the baseline is 3, but the description adds substantial meaning: it explains the type collection names including folder-path aliases, identifies the bible/ folder ambiguity between Books and Chapters, clarifies that folder is the only path-based scoper, and explains default ordering per collection. This goes well beyond the schema's field 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: 'Browse or page through any collection in the knowledge base.' It then gives concrete example questions ('what events are recorded', 'list the epochs in order') and contrasts the tool with lookup tools ('rather than to look one thing up'), making its purpose and boundaries 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?
The description explicitly states when to use this tool: 'when you want to know WHAT EXISTS rather than to look one thing up.' It also provides detailed collection names, ordering defaults, foofolder scoping, and says how to page, so an agent knows exactly when to choose this over a lookup or search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search every document in the knowledge base by name, description, tag, path and type — people, places, themes, lexemes, commandments, events, epochs, books, chapters, sources and datasets alike.
All terms must match (AND), so adding a word narrows the result. Use type to stop one collection swamping another: there are ~3,000 people AND ~3,000 themes, so an unfiltered name query is a coin flip between a person and a topic.
This searches concept METADATA. To find a phrase in the text of Scripture use search_scripture; to fetch a reference you already know use get_passage.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Restrict to documents carrying this tag. | |
| type | No | Restrict to one collection: Person, Place, Theme, Lexeme, Commandment, Event, Epoch, Book, Chapter, Source, Dataset, Relation Vocabulary. | |
| limit | No | How many matches to return. Defaults to 25, capped at 100. | |
| query | Yes | One or more words, e.g. "sea galilee" or "zechariah king" | |
| offset | No | For paging; compare with `total` in the response. |
| Name | Required | Description |
|---|---|---|
| tag | No | |
| type | No | |
| count | Yes | |
| query | Yes | |
| total | Yes | |
| offset | Yes | |
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses that all terms must match using AND, that matching applies to metadata only, and that unfiltered queries can return ambiguous results due to collection sizes. This adds real behavioral insight beyond structured 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?
The description is compact, immediately states the core purpose, then adds high-value behavioral and usage guidance in a logical order. Every sentence provides actionable information without redundancy or 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?
With an output schema present and full parameter schema coverage, the description is complete for this tool's complexity. It explains the critical behavioral distinction between metadata search and full-text Scripture search, provides collection-level guidance, and routes to the correct sibling tools.
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 parameters are already fully described in the schema. The description adds useful guidance about the `query` and `type` parameters, but it does not need to repeat all parameter details. The extra context tips this slightly positive but stays at baseline because the schema carries the load.
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 specifies a precise verb+resource: searches every concept in the knowledge base by metadata fields (name, description, tag, path, type). It also clearly enumerates the entity types covered and distinguishes itself from search_scripture and get_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?
The description explicitly states when to use this tool vs alternatives: search_scripture for phrases in text, get_passage for known references. It also gives practical guidance on using `type` to prevent collection imbalance from overwhelming results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all 31,102 verses of the Berean Standard Bible. This is how you find a passage you can half-remember but cannot cite: "a still small voice", "faith hope love".
All words must appear in the same verse. Wrap words in double quotes to require them adjacent as a phrase. Results are ranked by how much of the verse is your query, so short exact matches come first. Restrict with book or testament when a common word would otherwise match hundreds of verses.
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | Restrict to one book, by slug or OSIS id, e.g. "john" or "John". See get_vocabulary. | |
| limit | No | How many verses to return. Defaults to 25, capped at 100. | |
| query | Yes | Words to find, e.g. `still small voice` or `"the word became flesh"` | |
| offset | No | Skip this many verses before returning. Use with `total` to page. | |
| testament | No | Restrict to the Old or New Testament. Omit to search all 66 books. |
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| count | Yes | |
| query | Yes | |
| terms | Yes | |
| total | Yes | |
| offset | Yes | |
| phrases | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavior well beyond the annotations: all words must appear in the same verse, double quotes make phrases, and results are ranked by how much of the verse matches the query. These details give an agent a concrete model of how the search works and what to expect from the results.
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 five sentences, each carrying necessary information: the core action, the typical use case, query constraints, ranking, and a filtering tip. It is front-loaded with the main action and contains no redundant or promotional language.
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 an output schema exists and all parameters are documented, the description covers everything needed to use the tool effectively: it defines search scope, query syntax, ranking logic, and performance-oriented tuning. No important behavioral aspect of the search operation is left unexplained.
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 already describes every parameter, providing a baseline of 3. The description adds value for query semantics by specifying same-verse requirement, phrase adjacency, and ranking behavior, and it recommends using book/testament to limit unwanted results. It does not add meaning for limit or offset, but those are already clearly documented in 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 opens with 'Full-text search across all 31,102 verses of the Berean Standard Bible', giving a specific verb, resource, and scope. The second sentence explains a clear use case (a passage you half-remember but cannot cite) and distinguishes it from citation-based retrieval tools like get_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?
The phrase 'This is how you find a passage you can half-remember but cannot cite' clearly sets expectations for when to use this tool, and the guidance to restrict with book or testament addresses common-search scenarios. However, it never names alternatives or states explicit when-not-to-use conditions, leaving some sibling differentiation to inference.
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.
v1.0.7get_supportv1.0.6find_cross_references4 fields changedInput schema / properties / offsetAdded value: +{
+ "description": "For paging; compare with `total` in the response.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / offsetAdded value: +{
+ "type": "number"
+}Output schema / properties / totalAdded value: +{
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "osis",
- "minVotes",
- "count",
- "threshold",
- "references"
-]New value: +[
+ "osis",
+ "minVotes",
+ "total",
+ "offset",
+ "count",
+ "threshold",
+ "references"
+]find_places_near3 fields changedInput schema / properties / offsetAdded value: +{
+ "description": "For paging; compare with `total` in the response. A wide radius holds far more than one page.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / offsetAdded value: +{
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "centre",
- "radiusKm",
- "total",
- "count",
- "results"
-]New value: +[
+ "centre",
+ "radiusKm",
+ "total",
+ "offset",
+ "count",
+ "results"
+]get_connections10 fields changedInput schema / properties / offsetAdded value: +{
+ "description": "For paging, applied to every ranked list in the response. Each list carries its own total — topChaptersTotal, topBookPairsTotal, referencesOutTotal, referencesInTotal.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / offsetAdded value: +{
+ "type": "number"
+}Output schema / properties / referencesInCountAdded value: +{
+ "type": "number"
+}Output schema / properties / referencesInTotalAdded value: +{
+ "type": "number"
+}Output schema / properties / referencesOutCountAdded value: +{
+ "type": "number"
+}Output schema / properties / referencesOutTotalAdded value: +{
+ "type": "number"
+}Output schema / properties / topBookPairsCountAdded value: +{
+ "type": "number"
+}Output schema / properties / topBookPairsTotalAdded value: +{
+ "type": "number"
+}Output schema / properties / topChaptersCountAdded value: +{
+ "type": "number"
+}Output schema / properties / topChaptersTotalAdded value: +{
+ "type": "number"
+}get_graph_neighborhood4 fields changedInput schema / properties / offsetAdded value: +{
+ "description": "For paging the node list, in the walk order the response returns. Edges are those internal to the page, so one that spans a page boundary appears on neither — fetch the neighbourhood in a single call if you need the edges whole.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Output schema / properties / offsetAdded value: +{
+ "type": "number"
+}Output schema / properties / totalAdded value: +{
+ "type": "number"
+}Output schema / requiredPrevious value: -[
- "root",
- "depth",
- "count",
- "truncated",
- "nodes",
- "edgeCount",
- "edges"
-]New value: +[
+ "root",
+ "depth",
+ "total",
+ "offset",
+ "count",
+ "truncated",
+ "nodes",
+ "edgeCount",
+ "edges"
+]v1.0.5get_statusv1.0.4searchsearch_conceptsv1.0.3find_cross_references1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "document": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "minVotes": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "references": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "target": {
+ "type": "string"
+ },
+ "votes": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "from",
+ "target",
+ "votes"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "threshold": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "osis",
+ "minVotes",
+ "count",
+ "threshold",
+ "references"
+ ],
+ "type": "object"
+}find_places_near1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "centre": {
+ "additionalProperties": {},
+ "properties": {
+ "lat": {
+ "type": "number"
+ },
+ "lon": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "lat",
+ "lon"
+ ],
+ "type": "object"
+ },
+ "count": {
+ "type": "number"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "origin": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lon": {
+ "type": "number"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "radiusKm": {
+ "type": "number"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "distanceKm": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lon": {
+ "type": "number"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type",
+ "distanceKm"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "centre",
+ "radiusKm",
+ "total",
+ "count",
+ "results"
+ ],
+ "type": "object"
+}get_changelog1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "bundleGenerated": {
+ "type": "string"
+ },
+ "indexBuilt": {
+ "type": "string"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "data",
+ "shareAlike",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ "log": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "okfVersion": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "indexBuilt",
+ "log",
+ "url"
+ ],
+ "type": "object"
+}get_connections1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "book": {
+ "additionalProperties": {},
+ "properties": {
+ "name": {
+ "type": "string"
+ },
+ "osisId": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "testament": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "osisId",
+ "name",
+ "slug"
+ ],
+ "type": "object"
+ },
+ "chapter": {
+ "additionalProperties": {},
+ "properties": {
+ "linkedChapters": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "osis": {
+ "type": "string"
+ },
+ "rank": {
+ "type": "string"
+ },
+ "reference": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "verses": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "votes": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "osis",
+ "reference",
+ "url"
+ ],
+ "type": "object"
+ },
+ "error": {
+ "type": "string"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "referencesIn": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "book": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ },
+ "osisId": {
+ "type": "string"
+ },
+ "votes": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "book",
+ "osisId",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "referencesOut": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "book": {
+ "type": "string"
+ },
+ "count": {
+ "type": "number"
+ },
+ "osisId": {
+ "type": "string"
+ },
+ "votes": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "book",
+ "osisId",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "topBookPairs": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "crossTestament": {
+ "type": "boolean"
+ },
+ "from": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ },
+ "votes": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "from",
+ "to",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "topChapters": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "linkedChapters": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "osis": {
+ "type": "string"
+ },
+ "reference": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "verses": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "votes": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "osis",
+ "reference",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "totals": {
+ "additionalProperties": {},
+ "properties": {
+ "arcs": {
+ "type": "number"
+ },
+ "chapters": {
+ "type": "number"
+ },
+ "crossTestament": {
+ "type": "number"
+ },
+ "distinctPairs": {
+ "type": "number"
+ },
+ "generated": {
+ "type": "string"
+ },
+ "references": {
+ "type": "number"
+ },
+ "selfPairs": {
+ "type": "number"
+ },
+ "source": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "references",
+ "distinctPairs",
+ "arcs",
+ "selfPairs",
+ "crossTestament",
+ "chapters"
+ ],
+ "type": "object"
+ }
+ },
+ "type": "object"
+}get_entity1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "backlinkCount": {
+ "type": "number"
+ },
+ "backlinks": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lon": {
+ "type": "number"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type",
+ "degree"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "backlinksTruncated": {
+ "type": "boolean"
+ },
+ "body": {
+ "type": "string"
+ },
+ "collection": {
+ "additionalProperties": {},
+ "properties": {
+ "description": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "route": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "label",
+ "route"
+ ],
+ "type": "object"
+ },
+ "count": {
+ "type": "number"
+ },
+ "degree": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "extension": {
+ "additionalProperties": {},
+ "properties": {
+ "license": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "source_id": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "vocabulary": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "type": "object"
+ },
+ "generated": {
+ "additionalProperties": {},
+ "properties": {
+ "at": {
+ "type": "string"
+ },
+ "by": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "by"
+ ],
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "document": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "text",
+ "data",
+ "shareAlike",
+ "attribution"
+ ],
+ "type": "object"
+ },
+ "linkCount": {
+ "type": "number"
+ },
+ "links": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lon": {
+ "type": "number"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type",
+ "degree"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "lon": {
+ "type": "number"
+ },
+ "note": {
+ "type": "string"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "relations": {
+ "additionalProperties": {},
+ "properties": {
+ "inbound": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "predicate": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "sourceType": {
+ "type": "string"
+ },
+ "statedAs": {
+ "type": "string"
+ },
+ "surface": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "predicate",
+ "statedAs",
+ "source",
+ "title",
+ "sourceType"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "outbound": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "predicate": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "surface": {
+ "type": "string"
+ },
+ "target": {
+ "type": "string"
+ },
+ "targetType": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "verses": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "predicate",
+ "target",
+ "title"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "outbound",
+ "inbound"
+ ],
+ "type": "object"
+ },
+ "sample": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lon": {
+ "type": "number"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type",
+ "degree"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "author": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "last_modified": {
+ "type": "string"
+ },
+ "resource": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "usage_count": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "resource"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "stale": {
+ "type": "boolean"
+ },
+ "status": {
+ "type": "string"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "trustTier": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "words": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+}get_family1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "ancestors": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "generation": {
+ "type": "number"
+ },
+ "people": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "generation",
+ "people"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "children": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "descendants": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "generation": {
+ "type": "number"
+ },
+ "people": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "generation",
+ "people"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "error": {
+ "type": "string"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "document": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "parents": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "person": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lon": {
+ "type": "number"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "siblings": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "spouses": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}get_graph_neighborhood1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "depth": {
+ "type": "number"
+ },
+ "edgeCount": {
+ "type": "number"
+ },
+ "edges": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "kind": {
+ "type": "string"
+ },
+ "predicate": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "target": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "source",
+ "target",
+ "kind"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "nodes": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "distance": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "lon": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "note": {
+ "type": "string"
+ },
+ "root": {
+ "type": "string"
+ },
+ "truncated": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "root",
+ "depth",
+ "count",
+ "truncated",
+ "nodes",
+ "edgeCount",
+ "edges"
+ ],
+ "type": "object"
+}get_interlinear1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "document": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "reference": {
+ "type": "string"
+ },
+ "translation": {
+ "type": "string"
+ },
+ "verses": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "osis": {
+ "type": "string"
+ },
+ "reference": {
+ "type": "string"
+ },
+ "words": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "english": {
+ "type": "string"
+ },
+ "from": {
+ "type": "number"
+ },
+ "language": {
+ "type": "string"
+ },
+ "lexeme": {
+ "type": "string"
+ },
+ "parsing": {
+ "type": "string"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "to": {
+ "type": "number"
+ },
+ "transliteration": {
+ "type": "string"
+ },
+ "word": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "from",
+ "to",
+ "language",
+ "word",
+ "transliteration",
+ "parsing",
+ "strongs",
+ "english"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "osis",
+ "reference",
+ "words"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "reference",
+ "translation",
+ "verses"
+ ],
+ "type": "object"
+}get_passage1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "backlinkCount": {
+ "type": "number"
+ },
+ "backlinks": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "type": "number"
+ },
+ "lon": {
+ "type": "number"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "backlinksTruncated": {
+ "type": "boolean"
+ },
+ "book": {
+ "additionalProperties": {},
+ "properties": {
+ "chapters": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "testament": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "slug",
+ "testament"
+ ],
+ "type": "object"
+ },
+ "chapter": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "additionalProperties": {},
+ "properties": {
+ "next": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "osis": {
+ "type": "string"
+ },
+ "previous": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "url": {
+ "type": "string"
+ },
+ "verseCount": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "osis"
+ ],
+ "type": "object"
+ }
+ ]
+ },
+ "context": {
+ "additionalProperties": {},
+ "properties": {
+ "crossReferences": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "osis": {
+ "type": "string"
+ },
+ "target": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "target"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "people": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "surface": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "places": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "surface": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "referencedBy": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "predicate": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type",
+ "predicate"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "themes": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "surface": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+ },
+ "id": {
+ "type": "string"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "document": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "boolean"
+ }
+ ]
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "next": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "note": {
+ "type": "string"
+ },
+ "omitted": {
+ "type": "boolean"
+ },
+ "omittedVerses": {
+ "items": {},
+ "type": "array"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "previous": {
+ "anyOf": [
+ {
+ "type": "string"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "reference": {
+ "type": "string"
+ },
+ "relations": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "from": {
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "predicate": {
+ "type": "string"
+ },
+ "source": {
+ "type": "string"
+ },
+ "surface": {
+ "type": "string"
+ },
+ "target": {
+ "type": "string"
+ },
+ "verses": {}
+ },
+ "required": [
+ "predicate",
+ "target"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "speakers": {
+ "items": {},
+ "type": "array"
+ },
+ "text": {
+ "type": "string"
+ },
+ "translation": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "verseCount": {
+ "type": "number"
+ },
+ "verses": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "omitted": {
+ "type": "boolean"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "speaker": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "verse": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "verse",
+ "osis",
+ "text"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "versification": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "osis",
+ "book",
+ "verses"
+ ],
+ "type": "object"
+}get_stats1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "books": {
+ "type": "number"
+ },
+ "brokenLinks": {
+ "type": "number"
+ },
+ "chapters": {
+ "type": "number"
+ },
+ "collections": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "description": {
+ "type": "string"
+ },
+ "example": {
+ "type": "string"
+ },
+ "folder": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ },
+ "route": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "label",
+ "count",
+ "folder",
+ "example",
+ "description"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "conceptEdges": {
+ "type": "number"
+ },
+ "connections": {
+ "type": "number"
+ },
+ "edges": {
+ "type": "number"
+ },
+ "edgesNote": {
+ "type": "string"
+ },
+ "generated": {
+ "type": "string"
+ },
+ "generatedNote": {
+ "type": "string"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "notes": {
+ "type": "number"
+ },
+ "okfVersion": {
+ "type": "string"
+ },
+ "orphans": {
+ "type": "number"
+ },
+ "tags": {
+ "type": "number"
+ },
+ "topTags": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "types": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "uncatalogued": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "verses": {
+ "type": "number"
+ },
+ "words": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "notes",
+ "edges",
+ "conceptEdges",
+ "connections",
+ "tags",
+ "words",
+ "orphans",
+ "brokenLinks",
+ "verses",
+ "chapters",
+ "books",
+ "collections",
+ "types",
+ "topTags",
+ "generated"
+ ],
+ "type": "object"
+}get_tags1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "tags": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "name",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "total",
+ "offset",
+ "count",
+ "tags"
+ ],
+ "type": "object"
+}get_vocabulary1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "books": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "chapters": {
+ "type": "number"
+ },
+ "name": {
+ "type": "string"
+ },
+ "order": {
+ "type": "number"
+ },
+ "osisId": {
+ "type": "string"
+ },
+ "path": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "testament": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "osisId",
+ "name",
+ "slug",
+ "testament",
+ "order",
+ "chapters",
+ "path"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "predicates": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "domain": {
+ "type": "string"
+ },
+ "edges": {
+ "type": "number"
+ },
+ "heading": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "inverse": {
+ "type": "string"
+ },
+ "range": {
+ "type": "string"
+ },
+ "symmetric": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "id",
+ "edges"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "undeclared": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "edges": {
+ "type": "number"
+ },
+ "id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "edges"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "predicates",
+ "undeclared",
+ "books"
+ ],
+ "type": "object"
+}list_documents1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "available": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "collection": {
+ "type": "string"
+ },
+ "count": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "error": {
+ "type": "string"
+ },
+ "hasMore": {
+ "type": "boolean"
+ },
+ "licence": {
+ "additionalProperties": {},
+ "properties": {
+ "attribution": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "document": {
+ "type": "string"
+ },
+ "reason": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "note": {
+ "type": "string"
+ },
+ "offset": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "results": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "endYearAH": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "epochType": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "lengthYears": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "lon": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "number": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "occurrences": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "osis": {
+ "type": "string"
+ },
+ "polarity": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "startYearAH": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "verseCount": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "sort": {
+ "type": "string"
+ },
+ "tag": {
+ "type": "string"
+ },
+ "total": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}search1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "query": {
+ "type": "string"
+ },
+ "results": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "degree": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "description": {
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "lat": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "lon": {
+ "anyOf": [
+ {
+ "type": "number"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "osis": {
+ "type": "string"
+ },
+ "shareAlike": {
+ "type": "boolean"
+ },
+ "strongs": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "tag": {
+ "type": "string"
+ },
+ "total": {
+ "type": "number"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "query",
+ "total",
+ "offset",
+ "count",
+ "results"
+ ],
+ "type": "object"
+}search_scripture1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "hits": {
+ "items": {
+ "additionalProperties": {},
+ "properties": {
+ "book": {
+ "type": "string"
+ },
+ "osis": {
+ "type": "string"
+ },
+ "reference": {
+ "type": "string"
+ },
+ "testament": {
+ "type": "string"
+ },
+ "text": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "osis",
+ "reference",
+ "url",
+ "text",
+ "book",
+ "testament"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "offset": {
+ "type": "number"
+ },
+ "phrases": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "query": {
+ "type": "string"
+ },
+ "terms": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "total": {
+ "type": "number"
+ }
+ },
+ "required": [
+ "query",
+ "total",
+ "count",
+ "offset",
+ "hits",
+ "terms",
+ "phrases"
+ ],
+ "type": "object"
+}v1.0.1find_cross_referencesfind_places_nearget_changelogget_connectionsget_entityget_familyget_graph_neighborhoodget_interlinearget_passageget_statsget_tagsget_vocabularylist_documentssearchsearch_scriptureScored across 17 tools
Each tool has a distinct role, and descriptions carefully separate search_scripture from search_concepts, get_connections from find_cross_references, and get_entity from get_passage. The main ambiguity is the cluster of graph/cross-reference tools and the similar-sounding get_stats/get_status, but the descriptions resolve these.
All tool names follow a consistent lowercase snake_case verb_noun pattern: get_*, search_*, list_*, and find_*. The verbs clearly signal the operation type, and there are no mixed conventions or vague generic names.
At 17 tools, this is slightly above the ideal 3-15 range, but the breadth of the domain justifies most of them. A few meta tools like get_support, get_status, and get_changelog could conceivably be consolidated, but none feels truly redundant.
The tool set covers the read-only lifecycle of the knowledge base well: discovery via get_stats/list_documents/get_tags, lookup via get_passage/get_entity, search via search_concepts/search_scripture, and relationship exploration via get_graph_neighborhood/get_family/find_cross_references. There are no obvious dead ends for the stated purpose.
Bible knowledge graph: 31,102 verses, 341,289 cross references, people, places, themes.
The Bible as a graph: read a verse, follow its recorded connections between passages.
Bible translations, books, chapters, verses, and search
Bible research: 59 translations, Hebrew/Greek Strong's, morphology, cross-refs, 13 dictionaries
