Besorah — the Bible in Hebrew, Greek, Aramaic and English

Trace a theme

trace_theme

Read-onlyIdempotent

Follows a passage's connections outward — voted cross-references plus quotations and parallels between books — one to three steps (depth, default 2), and returns the most strongly connected verses (20 by default, limit 1-40) with their text, hops from the start, strength (it grows with the number of short paths that reach the verse) and how each was reached. Example: the connections of Passover outward from Exodus 12. Use when the user asks to follow a theme or passage outward through the Bible.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "reference": "<reference>"
    },
    "name": "trace_theme"
  }
}

Input Schema

Name	Required	Description
`depth`	No	1-3 steps, default 2
`limit`	No	how many results to return (1-40, default 20)
`follow`	No	both, xref (cross-references only) or quotes (quotations and parallels only)
`format`	No	optional: json (default) or markdown (compact, readable)
`breadth`	No	links followed per verse, 2-10, default 5
`max_chars`	No	optional: cap the answer at about this many characters (lists are shortened and marked truncated; use offset/nextOffset to get the rest)
`reference`	Yes	a verse, short range or chapter

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 12, 2026

changedInput schema / properties / limit / description

Previous value: -"how many to return"New value: +"how many results to return (1-40, default 20)"

Changed1 schema field changedNov 12, 2026

addedInput schema / properties / follow / description

Added value: +"both, xref (cross-references only) or quotes (quotations and parallels only)"

First observedNov 11, 2026

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuine value by explaining the return shape (text, hops, strength, path) and that strength grows with the number of short paths, but it also references 'offset/nextOffset' parameters that do not appear in the input schema, creating confusion about how to retrieve truncated results.

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 core behavior is front-loaded in the first clause and the example and usage sentence are short and useful. The opening sentence is long and em-dash-dense, packing parameters, defaults and output fields into one breath, but no sentence is genuinely wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With seven parameters, no output schema and full schema coverage, the description does well to describe the result fields so the agent knows what comes back. However, the unexplained offset/nextOffset reference and the absence of any note on cost or performance for deep, high-breadth traversals leave gaps for a multi-step graph-walk tool.

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 all seven parameters are already documented in the schema. The description repeats depth and limit defaults and explains the meaning of 'hops' and 'strength' in the output, but leaves the breadth and follow parameters entirely to the schema, so it adds only modest meaning beyond structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource: it 'follows a passage's connections outward' through voted cross-references, quotations and parallels, one to three steps, returning ranked verses with strength scores. The multi-hop traversal plus strength ranking implicitly distinguishes it from single-hop lookups like get_cross_references, but no sibling is named, so differentiation is inferred rather than explicit.

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?

Provides a concrete when-to-use trigger ('Use when the user asks to follow a theme or passage outward through the Bible') plus a worked example (Passover from Exodus 12). It stops short of stating when not to use it or naming a simpler alternative for one-hop reference lists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Besorah — the Bible in Hebrew, Greek, Aramaic and English tools Inspect

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.

Resources

Need Help?