Skip to main content
Glama

VineVerse — Bible Knowledge Graph

Search the text of Scripture

search_scripture
Read-onlyIdempotent

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bookNoRestrict to one book, by slug or OSIS id, e.g. "john" or "John". See get_vocabulary.
limitNoHow many verses to return. Defaults to 25, capped at 100.
queryYesWords to find, e.g. `still small voice` or `"the word became flesh"`
offsetNoSkip this many verses before returning. Use with `total` to page.
testamentNoRestrict to the Old or New Testament. Omit to search all 66 books.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsYes
countYes
queryYes
termsYes
totalYes
offsetYes
phrasesYes

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.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Each tool targets a distinct retrieval task, and the only near-overlaps—get_connections vs find_cross_references, get_stats vs get_status, get_entity vs get_family—are clearly separated by the descriptions. An agent could occasionally hesitate between get_entity and get_family for genealogy, but the purpose statements make the boundary clear.

Naming Consistency4/5

All tool names use clear snake_case verb_noun phrasing, and most are get_* operations. There is a minor stylistic split between get_*, find_*, search_*, and list_*, which gives the set a slightly less uniform feel but is still predictable and readable enough for an agent.

Tool Count4/5

At 16 tools, this is slightly above the typical 3-15 range, but every tool covers a genuinely separate capability: passage lookup, concept search, graph queries, genealogy, interlinear, statistics, and service health. The count is large but reasonable for the breadth of a Bible knowledge graph.

Completeness5/5

For read-only knowledge-graph, the surface is well covered: known-lookup, text and concept search, browsing by collection, cross-references, graph neighborhoods, genealogy, places, interlinear, vocabulary, tags, and every diagnostics. get_stats and get_vocabulary together give an agent a reliable map of the whole domain, so there are no obvious dead ends.

Resources