orthotomeo
Server Details
Read-only scripture-study engine: complete-or-fail concordance over Greek NT, Hebrew OT, LXX.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- jrainsberger/orthotomeo
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
12 toolsattestationManuscript attestationRead-onlyInspect
Returns the WHNT-style Type/Editions manuscript-tradition columns as neutral text-critical data (e.g. Mark 16:9-20 = Type KO) - which editions carry a word, with no argument for or against a variant.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | USFM book code (e.g. GEN, PSA, MAT, REV) or the full English book name, any case (e.g. Genesis, matthew) | |
| word | No | 1-based word_no within the verse; omit for every word in the verse | |
| verse | Yes | verse number | |
| corpus | Yes | word-tagged corpus: TAGNT, TAHOT, Swete, OSS-LXX-lemma | |
| chapter | Yes | chapter number |
Output Schema
| Name | Required | Description |
|---|---|---|
| sources | No | |
| citations | Yes |
citeFormat citationRead-onlyInspect
Renders Citations (from any of the above tools) as quoted, fully-attributed Markdown bullets - the only sanctioned bridge from a query result to pastable study-document text.
| Name | Required | Description | Default |
|---|---|---|---|
| citations | Yes | Citations previously returned by another tool call, to render as a pastable reference block |
Output Schema
| Name | Required | Description |
|---|---|---|
| text | Yes |
concord_lemmaSearch concordance (lemma)Read-onlyInspect
Complete-or-fail concordance: every words row in corpus whose lemma, dStrong, or (with by="surface") exact inflected surface form matches query. Route lemma/Strong's-number/surface-word lookups here, never by writing SQL or guessing occurrences from memory. This deployment caps one concordance result at 2000 occurrences and refuses anything broader, reporting the exact match count in the error. Call count first when a query might be broad - count is never capped.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | optional match column override: lemma, dstrong, or surface. Omit for auto-detect (dStrong shape, else lemma) - surface must always be requested explicitly, it is never guessed | |
| query | Yes | a lemma (e.g. ἄφεσις), a disambiguated Strong's number (e.g. G0859, H7225G), or (with by="surface") the exact inflected word as it appears in the verse | |
| corpus | Yes | word-tagged corpus to search: TAGNT (Greek NT), TAHOT (Hebrew OT), Swete (LXX surface), OSS-LXX-lemma (LXX lemma) |
Output Schema
| Name | Required | Description |
|---|---|---|
| sources | No | |
| citations | Yes |
concord_phraseSearch concordance (phrase)Read-onlyInspect
Complete-or-fail multi-word concordance: every occurrence, within one verse, of tokens (lemma strings) appearing in order within window intervening words of each other (window=0 = strictly adjacent). This is the tool for a phrase query like εἰς ἄφεσιν. This deployment caps one concordance result at 2000 occurrences and refuses anything broader, reporting the exact match count in the error. Call count first when a query might be broad - count is never capped.
| Name | Required | Description | Default |
|---|---|---|---|
| corpus | Yes | word-tagged corpus to search: TAGNT, TAHOT, Swete, OSS-LXX-lemma | |
| tokens | Yes | ordered lemma strings to find co-occurring within one verse, e.g. ["εἰς","ἄφεσις"] | |
| window | Yes | max words allowed between consecutive tokens; 0 = strictly adjacent |
Output Schema
| Name | Required | Description |
|---|---|---|
| sources | No | |
| citations | Yes |
countCount occurrencesRead-onlyInspect
Occurrence tally (total + per-book breakdown) for the identical query concord_lemma would match. count.Total always equals len(concord_lemma(...)) - use this to sanity-check a concordance result, or when only the number matters.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | optional match column override: lemma, dstrong, or surface, same as concord_lemma | |
| query | Yes | a lemma, dStrong, or (with by="surface") exact inflected word, same as concord_lemma | |
| corpus | Yes | word-tagged corpus: TAGNT, TAHOT, Swete, OSS-LXX-lemma |
Output Schema
| Name | Required | Description |
|---|---|---|
| total | Yes | |
| by_book | Yes |
get_passageGet passage textRead-onlyInspect
Returns get_verse's result for every canonical verse in a contiguous, single-book range, in order - verse boundaries preserved, never concatenated into one blob.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | USFM book code (e.g. GEN, PSA, MAT, REV) or the full English book name, any case (e.g. Genesis, matthew) | |
| editions | Yes | verse-text editions to fetch verbatim text from: KJV, ASV, WEB, Brenton | |
| end_verse | Yes | last verse of the range, inclusive | |
| end_chapter | Yes | last chapter of the range, inclusive | |
| start_verse | Yes | first verse of the range, inclusive | |
| start_chapter | Yes | first chapter of the range, inclusive |
Output Schema
| Name | Required | Description |
|---|---|---|
| sources | No | |
| citations | Yes |
get_verseGet verse textARead-onlyInspect
Returns verbatim verse text with provenance for one canonical reference, one Citation per requested edition (KJV, ASV, WEB, Brenton).
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | USFM book code (e.g. GEN, PSA, MAT, REV) or the full English book name, any case (e.g. Genesis, matthew) | |
| verse | Yes | verse number | |
| chapter | Yes | chapter number | |
| editions | Yes | verse-text editions to fetch verbatim text from: KJV, ASV, WEB, Brenton |
Output Schema
| Name | Required | Description |
|---|---|---|
| sources | No | |
| citations | Yes |
Tool Definition Quality
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 return type (verbatim text with provenance) but lacks details on error handling, authentication, or limitations. The description is adequate but not comprehensive for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the key verb and resource. Every word earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 required params) and presence of an output schema, the description covers the essential behavior. It could mention output format or error cases but remains largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond the schema. It reiterates 'verbatim verse text' and 'one Citation per requested edition', which is already implied. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (returns), resource (verbatim verse text with provenance), and scope (one canonical reference, one Citation per requested edition). It distinguishes from siblings like get_passage by specifying 'one' reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like get_passage or cite. It mentions 'one canonical reference' but does not contrast with other sibling tools or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
interlinearInterlinear reading viewARead-onlyInspect
Returns a row-aligned reading view for every word in a verse (or one word, if word is given): original text, transliteration, gloss (via lexicon_lookup), and grammar stacked per word - the composed display shape for a study reading view, built on parse and lexicon_lookup rather than any new query.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | USFM book code (e.g. GEN, PSA, MAT, REV) or the full English book name, any case (e.g. Genesis, matthew) | |
| word | No | 1-based word_no within the verse; omit for every word in the verse | |
| verse | Yes | verse number | |
| corpus | Yes | word-tagged corpus: TAGNT, TAHOT, Swete, OSS-LXX-lemma | |
| chapter | Yes | chapter number |
Output Schema
| Name | Required | Description |
|---|---|---|
| words | Yes | |
| sources | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the return structure (row-aligned, stacked per word) and the dependency on other tools. However, it lacks details on error scenarios, pagination, size limits, or exact output format, which would help an agent use it correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the main action and components. It is front-loaded with the key outcome. While dense, it contains no wasted words, earning a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema (assumed complete), the description adequately explains the return concept. However, it does not address prerequisites (e.g., corpus must be word-tagged) or error conditions, leaving some gaps for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add significant meaning beyond the schema; it briefly mentions the 'word' parameter's role but the schema already describes it fully. No additional parameter clarification is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Returns') and a clear resource ('row-aligned reading view for every word in a verse or one word') with explicit data components (original text, transliteration, gloss, grammar). It distinguishes from siblings by noting it is a composed display built on parse and lexicon_lookup, not a new query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context by stating the tool is built on parse and lexicon_lookup, implying it combines these for a display view. However, it does not explicitly state when not to use this tool or name alternatives for individual data, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lemmatizeList lemmasARead-onlyInspect
Returns the ordered lemma list for a verse (words with no lemma are omitted, not fabricated).
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | USFM book code (e.g. GEN, PSA, MAT, REV) or the full English book name, any case (e.g. Genesis, matthew) | |
| verse | Yes | verse number | |
| corpus | Yes | word-tagged corpus: TAGNT, TAHOT, Swete, OSS-LXX-lemma | |
| chapter | Yes | chapter number |
Output Schema
| Name | Required | Description |
|---|---|---|
| sources | No | |
| citations | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the list is ordered and that words without lemmas are omitted (not fabricated). However, with no annotations, it lacks details on safety, reversibility, or permissions. For a read-like operation, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and contains no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 4 required parameters, full schema coverage, and presence of an output schema, the description is sufficiently complete. It explains the return format and a key behavioral caveat. Slight improvement could be mentioning ordering rationale.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully describes parameters. The description does not add semantic detail beyond what the schema provides, meeting the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns an ordered lemma list for a verse, with a specific note about omitted words. This distinguishes it from siblings like parse or interlinear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verse-level lemma retrieval but provides no explicit guidance on when to use this tool versus alternatives like concord_lemma or parse. No exclusion criteria or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
lexicon_lookupLexicon lookupRead-onlyInspect
Resolves a disambiguated Strong's number (dStrong) to its lexicon entry: lemma, transliteration, gloss, and - for a Greek entry only - a fuller definition (Abbott-Smith 1922, Public Domain). A Hebrew entry's definition field is always omitted: it is abridged BDB via Online Bible, which requires permission not yet obtained, so only its gloss is ever returned. Not to be confused with the get_verse/get_passage tools, which resolve a Ref to translated verse text, not a dStrong to a dictionary entry.
| Name | Required | Description | Default |
|---|---|---|---|
| dstrong | Yes | a disambiguated Strong's number, e.g. G0859, H7225G |
Output Schema
| Name | Required | Description |
|---|---|---|
| gloss | Yes | |
| lemma | Yes | |
| dstrong | Yes | |
| language | Yes | |
| translit | Yes | |
| definition | No |
parseParse morphologyRead-onlyInspect
Returns dStrong + expanded morphology (via the T6 morph_codes table) for every word in a verse, or one word if word is given. LXX corpora (Swete, OSS-LXX-lemma) are always Flagged - neither carries morphology.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | USFM book code (e.g. GEN, PSA, MAT, REV) or the full English book name, any case (e.g. Genesis, matthew) | |
| word | No | 1-based word_no within the verse; omit for every word in the verse | |
| verse | Yes | verse number | |
| corpus | Yes | word-tagged corpus: TAGNT, TAHOT, Swete, OSS-LXX-lemma | |
| chapter | Yes | chapter number |
Output Schema
| Name | Required | Description |
|---|---|---|
| sources | No | |
| citations | Yes |
resolve_refResolve referenceARead-onlyInspect
Reports, for every per-verse content edition (KJV, ASV, WEB, Brenton, TAGNT, TAHOT, Swete, OSS-LXX-lemma), whether a canonical reference has a counterpart there and where. Cross-edition divergence (a T4b merge/renumber/divide, or a reference simply missing from an edition) is reported as Caveats - never a silent shift.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | USFM book code (e.g. GEN, PSA, MAT, REV) or the full English book name, any case (e.g. Genesis, matthew) | |
| verse | Yes | verse number | |
| chapter | Yes | chapter number |
Output Schema
| Name | Required | Description |
|---|---|---|
| ref | Yes | |
| caveats | Yes | |
| addresses | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: it reports per-verse content editions, always reports caveats for divergences (never silent shifts), and lists the specific editions. However, it does not explicitly state whether the tool is read-only or if any side effects occur, though the verb 'reports' implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the purpose, lists the editions, and explains the caveat mechanism. There is no unnecessary information; every part is essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of cross-edition reference resolution and the existence of an output schema, the description is adequate. It explains what the tool does, which editions it covers, and how divergences are reported. It does not need to detail return values since the output schema presumably handles that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (book, chapter, verse). The tool description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reports for each of the listed editions whether a canonical reference has a counterpart and where, which is a specific verb+resource combination. It distinguishes from siblings like 'get_passage' or 'cite' by focusing on cross-edition reference resolution, not just retrieval or citation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking references across multiple Bible editions, but it does not explicitly state when to use this tool versus alternatives (e.g., get_verse for a single edition) or provide exclusions. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!