VineVerse — Bible Knowledge Graph

Bundle log and generation time

get_changelog

Read-onlyIdempotent

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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.

All VineVerse — Bible Knowledge Graph tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

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

Need Help?