bible-mcp

get_concept

Look up a theological concept or lexical keyword in the OT+NT concept graph (~5,700 nodes seeded from Easton's Bible Dictionary — see DESIGN.md #5). Returns its definition (with a pointer to the full Easton entry), verse anchors, same-as equivalents, and entities that instantiate it (e.g. Abraham for Covenant). Easton cross-reference stubs are followed (Righteousness -> Justification). concept_type optional: theme | keyword. A Strong's number ('G225') also resolves directly to its keyword node. For typed relations to OTHER concepts (broader/narrower/ causes/part_of/symbol_of/fulfills/associated), use get_concept_relations(name).

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": {
      "name": "<name>"
    },
    "name": "get_concept"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes
`concept_type`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 28, 2026

TDQS

A4.4/5.0

Behavior4/5

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

No annotations are provided, but the description carries substantial behavioral weight on its own: it discloses that Easton cross-reference stubs are followed (Righteousness -> Justification), that a Strong's number resolves to its keyword node, and roughly what the payload contains. It does not say what happens when a name fails to resolve, which matters for a lookup tool with an unenumerated string key.

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?

Front-loaded with the verb and resource, then the return payload, then the alternative — a sensible order with no filler sentences. The parenthetical '~5,700 nodes seeded from Easton's Bible Dictionary — see DESIGN.md #5' is developer-facing and of limited use to a calling agent.

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?

An output schema exists, so return values need not be described, yet the description still surfaces the non-obvious alias-following and Strong's resolution behavior that no structured field conveys. Combined with the enum-in-prose and explicit sibling handoff, an agent has everything needed to call this 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?

Schema coverage is 0%, so the description must compensate and largely does: 'name' is documented as accepting a concept name, a lexical keyword, or a Strong's number in 'G225' form, and 'concept_type' is enumerated as theme | keyword even though the schema declares no enum. It omits the effect of the empty-string default and whether concept_type narrows or only hints at disambiguation.

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?

Specific verb ("look up") plus a precisely scoped resource (theological concept or lexical keyword in the OT+NT concept graph, with node count and seed source). It also names the sibling it is not — get_concept_relations — and states what that sibling does differently, so the two are separable without opening schemas.

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?

Explicitly routes relation queries to get_concept_relations(name) with the exact relation types listed, which is a real exclusion, not an implied one. It does not address when to prefer this over semantic_search or word_study for the same subject, so routing against the broader sibling set is only partially covered.

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

All bible-mcp 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.