A
licenseA
qualityA
maintenanceBible knowledge graph: 31,102 verses, 341,289 cross references, people, places, themes.
2
17
MIT
VineVerse — Bible Knowledge Graph
Server Details
Bible knowledge graph: 31,102 verses, 341,289 cross references, people, places, themes.
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
TDQS
A4.5/5.0
Scored across 17 tools
Disambiguation5/5
Each tool targets a distinct operation and entity kind: passage lookup, full-text search, metadata search, cross-reference discovery, graph shape, genealogy, interlinear, geospatial proximity, and service metadata. Even close pairs like find_cross_references vs get_connections and get_stats vs get_status are explicitly differentiated in their descriptions.
Naming Consistency4/5
Most tools use a get_ + noun pattern for retrievals, while find_ is reserved for cross-references and nearby places, search_ for metadata/full-text queries, and list_documents for browsing. This is mostly predictable, but the multiple verb prefixes prevent a single uniform verb_noun pattern across the whole set.
Tool Count4/5
At 17 tools it sits just above the ideal 3–15 band, but the breadth of a Bible knowledge graph—passages, original languages, people/places/themes, graph analytics, geospatial lookup, and operational metadata—justifies most of them. A few service-related tools could potentially be merged, but none feel redundant.
Completeness5/5
The tool surface covers the full read-only lifecycle: known-item retrieval, browsing, two search modes, cross-reference lookup, graph neighborhood traversal, vocabulary and tag listing, interlinear data, genealogy, geospatial proximity, and operational metadata. There are no obvious dead ends, and the only missing capabilities are mutations, which are outside the purpose of a knowledge base API.
Available Tools
17 toolsfind_cross_referencesFind cross referencesARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| osis | Yes | |
| count | Yes | |
| total | Yes | |
| offset | Yes | |
| licence | No | |
| minVotes | Yes | |
| threshold | Yes | |
| references | Yes |
TDQS
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
find_places_nearFind places near a locationARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| count | Yes | |
| total | Yes | |
| centre | Yes | |
| offset | Yes | |
| origin | No | |
| licence | No | |
| results | Yes | |
| radiusKm | Yes |
TDQS
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
get_changelogBundle log and generation timeARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| log | Yes | |
| url | Yes | |
| note | No | |
| licence | No | |
| indexBuilt | Yes | |
| okfVersion | No | |
| bundleGenerated | No |
TDQS
A4.7/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
get_connectionsThe cross-reference corpus in aggregateARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| 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 |
TDQS
A4.7/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
get_entityGet a documentARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| 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 |
TDQS
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
get_familyGet a person's family and line of descentARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Person path, e.g. "people/moses" | |
| generations | No | Above 1, also returns ancestors and descendants generation by generation. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| error | No | |
| person | No | |
| licence | No | |
| parents | No | |
| spouses | No | |
| children | No | |
| siblings | No | |
| ancestors | No | |
| descendants | No |
TDQS
A4.8/5.0
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
get_graph_neighborhoodGet a graph neighbourhoodARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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". |
Output Schema
ParametersJSON Schema
| 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 |
TDQS
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
get_interlinearGet the original-language words behind a passageARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| osis | Yes | OSIS reference — a verse ("John.3.16") or a whole chapter ("John.3") |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| verses | Yes | |
| licence | No | |
| reference | Yes | |
| translation | Yes |
TDQS
A4.5/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
get_passageGet a passageARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| osis | Yes | OSIS reference: "John.3.16", "John.3.16-18", "Ps.23" or "1Sam.17.45" |
Output Schema
ParametersJSON Schema
| 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 |
TDQS
A4.3/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
get_statsWhat is in the knowledge baseARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| 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 |
TDQS
A4.5/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
get_statusService status and availabilityARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| sla | Yes | |
| status | Yes | |
| uptime | Yes | |
| datasets | Yes | |
| checkedAt | Yes | |
| components | Yes |
TDQS
A4.9/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
get_supportWho runs this, and how to support itARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| 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 |
TDQS
A4.9/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
get_tagsTag vocabularyARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tags | Yes | |
| count | Yes | |
| total | Yes | |
| offset | Yes |
TDQS
A4.3/5.0
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
get_vocabularyRelation vocabulary and canon tableARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| books | Yes | |
| licence | No | |
| predicates | Yes | |
| undeclared | Yes |
TDQS
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
list_documentsList documents in a collectionARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| 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 |
TDQS
A5/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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_conceptsSearch conceptsARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tag | No | |
| type | No | |
| count | Yes | |
| query | Yes | |
| total | Yes | |
| offset | Yes | |
| results | Yes |
TDQS
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
search_scriptureSearch the text of ScriptureARead-onlyIdempotentInspect
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.
ParametersJSON Schema
| 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| hits | Yes | |
| count | Yes | |
| query | Yes | |
| terms | Yes | |
| total | Yes | |
| offset | Yes | |
| phrases | Yes |
TDQS
A4.7/5.0
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Added
get_support
5 tool updates
- Changed
find_cross_references4 fields changed- added
Input schema / properties / offsetAdded value: +{ + "description": "For paging; compare with `total` in the response.", + "maximum": 9007199254740991, + "minimum": 0, + "type": "integer" +} - added
Output schema / properties / offsetAdded value: +{ + "type": "number" +} - added
Output schema / properties / totalAdded value: +{ + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "osis", - "minVotes", - "count", - "threshold", - "references" -]New value: +[ + "osis", + "minVotes", + "total", + "offset", + "count", + "threshold", + "references" +]
- Changed
find_places_near3 fields changed- added
Input 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" +} - added
Output schema / properties / offsetAdded value: +{ + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "centre", - "radiusKm", - "total", - "count", - "results" -]New value: +[ + "centre", + "radiusKm", + "total", + "offset", + "count", + "results" +]
- Changed
get_connections10 fields changed- added
Input 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" +} - added
Output schema / properties / offsetAdded value: +{ + "type": "number" +} - added
Output schema / properties / referencesInCountAdded value: +{ + "type": "number" +} - added
Output schema / properties / referencesInTotalAdded value: +{ + "type": "number" +} - added
Output schema / properties / referencesOutCountAdded value: +{ + "type": "number" +} - added
Output schema / properties / referencesOutTotalAdded value: +{ + "type": "number" +} - added
Output schema / properties / topBookPairsCountAdded value: +{ + "type": "number" +} - added
Output schema / properties / topBookPairsTotalAdded value: +{ + "type": "number" +} - added
Output schema / properties / topChaptersCountAdded value: +{ + "type": "number" +} - added
Output schema / properties / topChaptersTotalAdded value: +{ + "type": "number" +}
- Changed
get_graph_neighborhood4 fields changed- added
Input 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" +} - added
Output schema / properties / offsetAdded value: +{ + "type": "number" +} - added
Output schema / properties / totalAdded value: +{ + "type": "number" +} - changed
Output schema / requiredPrevious value: -[ - "root", - "depth", - "count", - "truncated", - "nodes", - "edgeCount", - "edges" -]New value: +[ + "root", + "depth", + "total", + "offset", + "count", + "truncated", + "nodes", + "edgeCount", + "edges" +]
- Added
get_status
2 tool updates
- Removed
search - Added
search_concepts
15 tool updates
- Changed
find_cross_references1 field changed- changed
Output 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" +}
- Changed
find_places_near1 field changed- changed
Output 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" +}
- Changed
get_changelog1 field changed- changed
Output 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" +}
- Changed
get_connections1 field changed- changed
Output 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" +}
- Changed
get_entity1 field changed- changed
Output 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" +}
- Changed
get_family1 field changed- changed
Output 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" +}
- Changed
get_graph_neighborhood1 field changed- changed
Output 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" +}
- Changed
get_interlinear1 field changed- changed
Output 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" +}
- Changed
get_passage1 field changed- changed
Output 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" +}
- Changed
get_stats1 field changed- changed
Output 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" +}
- Changed
get_tags1 field changed- changed
Output 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" +}
- Changed
get_vocabulary1 field changed- changed
Output 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" +}
- Changed
list_documents1 field changed- changed
Output 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" +}
- Changed
search1 field changed- changed
Output 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" +}
- Changed
search_scripture1 field changed- changed
Output 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" +}
15 tool updates
- First observed
find_cross_references - First observed
find_places_near - First observed
get_changelog - First observed
get_connections - First observed
get_entity - First observed
get_family - First observed
get_graph_neighborhood - First observed
get_interlinear - First observed
get_passage - First observed
get_stats - First observed
get_tags - First observed
get_vocabulary - First observed
list_documents - First observed
search - First observed
search_scripture
Related MCP Connectors
The Bible as a graph: read a verse, follow its recorded connections between passages.
Bible translations, books, chapters, verses, and search
- DarashOAuthpro.publifye
Bible research: 59 translations, Hebrew/Greek Strong's, morphology, cross-refs, 13 dictionaries
Bible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides source-grounded Christian research material with exact passages, provenance, and stable citations via a REST API.MIT
- AlicenseNot gradedqualityCmaintenanceEnables semantic search of the KJV Bible and personal knowledge graph for scripture study, notes, prayers, and memory verses, all running locally with no cloud dependencies.MIT
- AlicenseNot gradedqualityBmaintenancePostgreSQL-backed MCP server for deep Bible study, integrating 140+ translations, Greek/Hebrew lexicons, cross-references, and semantic search.MIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.