How do I use biblical-linguistics-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@biblical-linguistics-mcp parse John 1:1" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

biblical-linguistics-mcp

by mpduarte

Overview Schema Related Servers Score Discussions

Python

Biblical Linguistics MCP

A production-quality Biblical Linguistic Research Agent exposed as a standalone MCP (Model Context Protocol) server in Python. Provides Hebrew & Greek word study, full morphological parsing, cross-references, LXX alignment, and more — all from free, open-licensed data sources.

Usable by any MCP-compatible client: Claude Desktop, Claude Code, OpenClaw, custom agents, etc.

Quick Start

# Clone the repo
git clone https://github.com/your-org/biblical-linguistics-mcp.git
cd biblical-linguistics-mcp

# Create virtual environment
python -m venv .venv
source .venv/bin/activate  # or .venv\Scripts\activate on Windows

# Install dependencies
pip install -e ".[dev]"

# Bootstrap the database (downloads open datasets + builds SQLite DB)
python scripts/bootstrap.py

# Run the MCP server (stdio mode for Claude Desktop / Claude Code)
python -m biblical_linguistics_mcp --transport stdio

# Or run in SSE mode for network access
python -m biblical_linguistics_mcp --transport sse --port 8080

Related MCP server: mcp-bible

Configuration

Option	CLI Flag	Env Var	Default
Transport mode	`--transport stdio\|sse`	—	`stdio`
SSE port	`--port 8080`	—	`8080`
SSE host	`--host 0.0.0.0`	—	`0.0.0.0`
Database path	`--db /path/to/db`	`BIBLICAL_LINGUISTICS_DB`	`data/biblical_linguistics.db`
Log level	`--log-level DEBUG`	—	`INFO`

MCP Integration Examples

Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "biblical-linguistics": {
      "command": "python",
      "args": ["-m", "biblical_linguistics_mcp", "--transport", "stdio"],
      "cwd": "/path/to/biblical-linguistics-mcp"
    }
  }
}

Claude Code

# Add as MCP server
claude mcp add biblical-linguistics -- python -m biblical_linguistics_mcp --transport stdio

Custom MCP Client (SSE)

from mcp import ClientSession
from mcp.client.sse import sse_client

async with sse_client("http://localhost:8080/sse") as (read, write):
    async with ClientSession(read, write) as session:
        await session.initialize()
        result = await session.call_tool("parse_verse", {"reference": "John 1:1"})
        print(result)

Tool Reference

Tool	Description	Key Parameters
`parse_verse`	All words with full morphology for a verse	`reference` (str)
`lookup_word`	Full lexical entry by Strong's number	`strongs` (str), `include_occurrences` (bool)
`reverse_lookup`	English word → Hebrew/Greek lexemes	`english_word` (str), `testament` (OT/NT)
`search_by_root`	Find verses sharing a lexeme/root	`strongs` (str), `book` (str), `testament` (str)
`cross_reference_tsk`	TSK cross-references for a verse	`reference` (str)
`cross_reference_thematic`	Topical/thematic related passages	`reference` (str) or `topic` (str)
`lxx_alignment`	LXX Greek ↔ Hebrew alignment	`reference` (str), `direction` (str)
`word_frequency`	Frequency and distribution stats	`strongs` (str)
`compare_translations`	Verse across KJV, ASV, WEB	`reference` (str), `versions` (list)

Example: `parse_verse`

// Request
{"reference": "John 1:1"}

// Response (abbreviated)
{
  "reference": "John 1:1",
  "testament": "NT",
  "text_kjv": "In the beginning was the Word...",
  "words": [
    {
      "position": 1,
      "text": "Ἐν",
      "morphology": {"part_of_speech": "preposition"}
    },
    {
      "position": 2,
      "text": "ἀρχῇ",
      "strongs": "G746",
      "gloss": "beginning, ruler",
      "morphology": {
        "part_of_speech": "noun",
        "case_form": "dative",
        "number": "singular",
        "gender": "feminine"
      }
    }
  ]
}

Resource Reference

URI Pattern	Description
`bible://books`	All Bible books with metadata
`bible://lexicon/hebrew/{strongs}`	Hebrew lexical entry
`bible://lexicon/greek/{strongs}`	Greek lexical entry
`bible://verse/{reference}`	Verse text in available translations
`bible://morphology-codes`	Hebrew & Greek morphology code reference

Prompt Reference

Prompt	Description	Arguments
`word_study`	Comprehensive word study report	`strongs` (required), `depth` (brief/full)
`passage_exegesis`	Exegetical analysis of a passage	`reference` (required)
`trace_theme`	Trace theme across both testaments	`topic` (required)
`lxx_quotation_analysis`	Analyze NT quotation of OT via LXX	`nt_reference`, `ot_reference`

Data Sources & Licensing

All data is free and open-licensed:

Dataset	License	Use
Open Scriptures Hebrew Bible (OSHB)	CC BY 4.0	Hebrew text + morphology
Dodson Greek Lexicon	CC BY-SA 3.0	Greek lexical data
Open Scriptures Hebrew Lexicon	CC BY 4.0	Hebrew lexical data
Strong's Concordance	Public Domain	Numbering system, definitions
Treasury of Scripture Knowledge	Public Domain	Cross-references
King James Version	Public Domain	English Bible text
American Standard Version	Public Domain	English Bible text
World English Bible	Public Domain	English Bible text
scrollmapper/bible_databases	Public Domain	Structured Bible data

Development

# Install dev dependencies
pip install -e ".[dev]"

# Run tests
pytest

# Run with coverage
pytest --cov=biblical_linguistics_mcp --cov-report=term-missing

# Re-download data sources
python scripts/download_sources.py --force

# Re-bootstrap database
python scripts/bootstrap.py

Project Structure

src/biblical_linguistics_mcp/
├── __main__.py          # CLI entry point
├── server.py            # MCP server (tools, resources, prompts)
├── db/                  # SQLite schema, connection, queries
├── morphology/          # Hebrew & Greek morphology parsers
├── lexicon/             # Hebrew & Greek lexicon access
├── crossref/            # TSK, thematic, root search, LXX
├── references/          # Bible reference parser
└── tools/               # MCP tool implementations

Requirements

Python 3.11+
No paid APIs or API keys required
~100 MB disk space for the full database

License

MIT

Available Tools

9 tools

compare_translationsB

Show a verse across multiple Bible translations (KJV, ASV, WEB)

ParametersJSON Schema

Name	Required	Description	Default
`versions`	No	List of version codes (kjv, asv, web). Defaults to all.
`reference`	Yes	Bible verse reference

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description carries full burden. It only says 'Show a verse', lacking details on behavior such as output format, prerequisites, or limitations (e.g., valid reference format, version availability).

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 a single, efficient sentence that conveys the core purpose without any extraneous words.

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?

For a simple tool with 2 parameters and no output schema, the description is adequate but fails to describe the return value or format, which would be helpful for an agent.

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% with both parameters documented. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 the verb 'Show' and the resource 'verse across multiple Bible translations (KJV, ASV, WEB)', which immediately distinguishes this tool from sibling tools like parse_verse or lookup_word.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as cross_reference_tsk or word_frequency. There are no explicit when-to-use or when-not-to-use instructions.

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

cross_reference_thematicB

Find topical/thematic related passages by reference or topic keyword

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No	Topic keyword to search (optional if reference provided)
`reference`	No	Bible verse reference (optional if topic provided)

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It only states the tool's purpose (find related passages) but does not disclose any behavioral traits such as authentication needs, rate limits, or side effects. The behavior beyond the action remains opaque.

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 a single, clear sentence of 14 words. It is front-loaded, efficient, and contains no filler. Every word contributes to understanding.

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?

Given the tool has two optional parameters and no output schema, the description is moderately complete. It fails to specify the output format (e.g., passages, references), whether both parameters can be used together, or any depth/limit. Additional detail would improve completeness.

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% with clear descriptions of each parameter (optional if the other is provided). The description adds that the tool finds topical/thematic passages, but does not enhance parameter meaning beyond the schema itself.

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?

The description clearly states the tool finds topical/thematic related passages using a reference or topic keyword. It is specific with verb and resource but does not explicitly differentiate from sibling tools like cross_reference_tsk.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage via reference or topic, and the schema clarifies they are optional if the other is provided. However, no explicit when-to-use or when-not-to-use guidance is given, nor comparisons to alternatives.

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

cross_reference_tskC

Get Treasury of Scripture Knowledge cross-references for a verse

ParametersJSON Schema

Name	Required	Description	Default
`reference`	Yes	Bible verse reference

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only states the basic action, omitting details about return format, side effects, authentication, or rate limits. This is insufficient for an agent to understand the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence, but it lacks front-loaded critical information. It could be expanded to include key details without losing conciseness.

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

Completeness2/5

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

Given the lack of an output schema, the description should explain what cross-references are returned. It does not mention the number of results, format, or any limitations, making it incomplete for practical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds no additional meaning beyond the schema. The parameter 'reference' is already described as 'Bible verse reference' in the schema; the description merely restates the purpose without providing examples or format constraints.

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?

The description clearly states the tool retrieves cross-references for a verse using a specific resource (Treasury of Scripture Knowledge). It uses a specific verb ('Get') and identifies the resource, distinguishing it from sibling tools like cross_reference_thematic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as cross_reference_thematic or search_by_root. The description does not include any context for usage.

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

lookup_wordA

Full lexical entry by Strong's number (e.g. H7225, G3056)

ParametersJSON Schema

Name	Required	Description	Default
`strongs`	Yes	Strong's number, e.g. 'G3056' or 'H7225'
`include_occurrences`	No	Include list of verse occurrences (default false)

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are present, yet the description only says 'Full lexical entry' without specifying what fields or behavior to expect. The parameter 'include_occurrences' is mentioned in schema but not in description, and no output format is described.

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?

Single sentence, front-loaded with purpose and example. No unnecessary words.

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?

Given no output schema and moderate complexity, the description could explain what 'full lexical entry' includes. It is adequate but not comprehensive.

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% with parameter descriptions for 'strongs' and 'include_occurrences'. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 the tool provides a 'Full lexical entry' for a Strong's number, with examples of format. This distinguishes it from sibling tools like parse_verse, reverse_lookup, etc.

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 implicitly indicates use when a Strong's number is known. It does not explicitly mention when not to use or provide alternatives, but the context is clear.

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

lxx_alignmentA

Show LXX Greek for a Hebrew verse or find Hebrew source for LXX Greek word

ParametersJSON Schema

Name	Required	Description	Default
`direction`	Yes	Direction of alignment lookup
`reference`	Yes	Hebrew verse reference (for hebrew_to_lxx) or Greek Strong's number (for lxx_to_hebrew)

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It discloses the two alignment directions but omits any behavioral details such as error handling, rate limits, or what happens with invalid references. The description adds minimal transparency beyond the schema.

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 a single sentence with no extraneous words. It front-loads the purpose and efficiently conveys the two modes. Every element contributes to understanding the tool's function.

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

Completeness2/5

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

Given the tool's bidirectional complexity and lack of output schema, the description should indicate what the result looks like (e.g., aligned text, verse references, word mappings). It does not, leaving the output unclear. The description is incomplete for a tool with no output schema.

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?

Both parameters have schema descriptions (100% coverage). The description adds value by specifying the type of reference expected for each direction (Hebrew verse reference vs. Greek Strong's number), which clarifies usage beyond 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 clearly states the tool's bidirectional functionality: showing LXX Greek for a Hebrew verse and finding Hebrew source for LXX Greek word. It uses specific verbs ('Show', 'find') and identifies the two distinct operations, distinguishing it from sibling tools that perform different lookups or analyses.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context by specifying two modes, but it does not explicitly state when to use this tool versus alternatives like lookup_word or cross_reference tools. No exclusion criteria or prerequisites are provided, leaving the agent to infer from the sibling names.

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

parse_verseB

Return all words with full morphological parsing for a Bible verse

ParametersJSON Schema

Name	Required	Description	Default
`reference`	Yes	Bible verse reference, e.g. 'John 1:1', 'Genesis 1:1'

TDQS

B3.1/5.0

Behavior2/5

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

No annotations exist, and the description only mentions the output without disclosing behavioral traits such as read-only nature, authentication needs, or potential side effects. It assumes a simple fetch operation.

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 a single, direct sentence with no unnecessary words. However, it could be slightly more informative about the output format or scope.

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

Completeness2/5

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

Given the presence of multiple sibling tools for different biblical analyses, the description does not adequately differentiate or explain what 'full morphological parsing' entails. It lacks details on return structure, making it incomplete for an agent to confidently use.

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% for the single parameter 'reference', which includes examples. The tool description adds no additional meaning beyond the schema, so baseline score 3 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 states the tool returns all words with full morphological parsing for a Bible verse, with a specific verb and resource. It is distinct from siblings like lookup_word which likely handles single words.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like lookup_word or reverse_lookup. The description does not specify exclusions or context.

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

reverse_lookupB

English word to possible Hebrew/Greek lexemes reverse lookup

ParametersJSON Schema

Name	Required	Description	Default
`testament`	No	Filter by testament (optional)
`english_word`	Yes	English word to look up

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description is too brief to disclose behavior like output format (list of lexemes) or read-only nature. Minimal value added beyond name.

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?

Extremely concise, single phrase with no waste. Front-loaded key information, though it sacrifices completeness.

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

Completeness2/5

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

For a bilingual lookup tool with 2 parameters and no output schema, description lacks context about reverse mapping, expected results, or relationship to 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 already describes both parameters (100% coverage). Description adds 'reverse lookup' context but does not enhance parameter understanding beyond 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?

Description clearly states the action (reverse lookup) and resources (English word to Hebrew/Greek lexemes). It distinguishes from sibling tools like lookup_word (forward lookup) and search_by_root.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Does not mention filtering by testament or when to prefer other lexeme search tools.

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

search_by_rootB

Find verses sharing a lexeme/root by Strong's number

ParametersJSON Schema

Name	Required	Description
`book`	No	Filter by book name (optional)
`strongs`	Yes	Strong's number to search for
`testament`	No	Filter by testament (optional)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It does not disclose read-only nature, return format, limits, or side effects. For a search tool, minimal behavioral transparency.

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?

Single sentence of 9 words, front-loaded with action and target. Efficient and to the point with no wasted words.

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

Completeness2/5

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

Lacks return format information, no indication of result structure or pagination. No output schema to compensate. For a search tool, these omissions create ambiguity.

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% with descriptions for all parameters. Description adds context that Strong's number represents a lexeme/root, clarifying search logic beyond schema. However, it does not elaborate further on book or testament 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?

Clear verb 'Find verses', specific resource 'sharing a lexeme/root', and input 'by Strong's number'. Distinguishes from siblings like parse_verse, lookup_word, and cross_references, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs siblings such as reverse_lookup or cross_reference_tsk. Description only states functionality without usage context or exclusions.

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

word_frequencyB

Get frequency and distribution statistics for a lexeme by Strong's number

ParametersJSON Schema

Name	Required	Description	Default
`strongs`	Yes	Strong's number, e.g. 'G3056' or 'H7225'

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not specify what 'distribution statistics' entails, whether it includes per-book counts, or any data limitations, leaving significant ambiguity.

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?

A single sentence with no wasted words. While effective, it could be slightly expanded for clarity without losing conciseness.

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

Completeness2/5

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

The description does not explain what the output will look like or how the distribution data is structured. Given no output schema, this is a notable gap for a tool that returns statistical data.

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?

With 100% schema coverage, the description adds minimal value beyond the schema's parameter description. The baseline of 3 is appropriate.

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 it gets frequency and distribution statistics for a lexeme by Strong's number. This purpose is distinct from sibling tools like lookup_word or search_by_root.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case (when frequency/distribution stats are needed), but does not explicitly state when not to use or suggest alternatives among sibling tools.

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. Dates show when Glama detected each change.

9 tool updatesv0.1.0Jul 28, 2026
- First observedcompare_translations
- First observedcross_reference_thematic
- First observedcross_reference_tsk
- First observedlookup_word
- First observedlxx_alignment
- First observedparse_verse
- First observedreverse_lookup
- First observedsearch_by_root
- First observedword_frequency

Install Server

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

TDQS

B3.4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: morphological parsing, lexical lookup, reverse lookup, root search, cross-references (two distinct types), LXX alignment, frequency statistics, and translation comparison. No overlap in functionality.

Naming Consistency4/5

All tool names use snake_case and predominantly follow a verb-noun pattern (e.g., parse_verse, lookup_word, compare_translations). Minor deviations like 'reverse_lookup' and 'lxx_alignment' still fit the overall convention, making names predictable and understandable.

Tool Count5/5

With 9 tools, the set is well-scoped for biblical linguistics. Each tool covers a key operation (parsing, lookup, cross-referencing, statistics, translations) without redundancy or unnecessary clutter.

Completeness4/5

The tool surface covers major needs: morphological analysis, lexical lookups, cross-references, LXX alignment, frequency stats, and translation comparisons. Minor gaps like phrase search or lemma-based search are absent but the core workflows are well supported.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

bible-mcp A
io.github.nirajagarwal
Bible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Search Knowledge & Memory Open Data
1312
orthotomeo A
io.github.jrainsberger
Read-only scripture-study engine: complete-or-fail concordance over Greek NT, Hebrew OT, LXX.
Search Research & Data Education & Learning Tools
122
uiule A
io.github.pipeworx-io
Bible MCP — wraps the Bible API (free, no auth)
Art & Culture Search Open Data
342
NuBereaOAuth
com.streamsapps
AI-powered biblical research tools — lexicons, morphology, manuscripts, and more.
Research & Data Art & Culture
23

Related MCP Servers

Bible MCP
Education & Learning Tools Open Data
midvash
A
license
A
quality
A
maintenance
Free, no-key MCP server for reading scripture from 35+ public-domain translations in 8 languages. Lets users fetch verses, chapters, and passages via natural language from any MCP client.
Updated a month ago (2026-07-30 16:59 UTC)
7
MIT
mcp-bible
Search Knowledge & Memory Research & Data
molpass
A
license
A
quality
A
maintenance
MCP server for Bible study, providing multi-version verse lookup, keyword/semantic search, cross-references, and word studies with original language and lexicon details.
Updated 2 months ago (2026-07-22 08:37 UTC)
6
MIT
textual-criticism-mcp
Art & Culture Search Research & Data
NoveltyDreams
A
license
Not graded
quality
D
maintenance
Biblical text analysis with textual criticism support. An MCP server for morphological analysis, manuscript variants, and concordance searches across Hebrew and Greek biblical texts.
Updated 7 months ago (2026-01-23 11:49 UTC)
MIT
theosis-mcp
Research & Data Search Databases
PrattyT85
A
license
Not graded
quality
B
maintenance
PostgreSQL-backed MCP server for deep Bible study, integrating 140+ translations, Greek/Hebrew lexicons, cross-references, and semantic search.
Updated a month ago (2026-08-04 14:59 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mpduarte/biblical-linguistics-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Biblical Linguistics MCP

Quick Start

Configuration

MCP Integration Examples

Claude Desktop

Claude Code

Custom MCP Client (SSE)

Tool Reference

Example: parse_verse

Resource Reference

Prompt Reference

Data Sources & Licensing

Development

Project Structure

Requirements

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Example: `parse_verse`