Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Adventist Study MCP What happens when we die according to Adventist belief?"
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.
An MCP server for Seventh-day Adventist Bible study. It answers not just "what does this verse say?" but "why do Adventists believe this?" — connecting a topic to Scripture, to the church's official doctrinal statement, and to classic Adventist writings, with citations throughout.
Everything runs locally against a bundled SQLite database. No API keys, no network calls at query time.
Source | Content |
Bible | 4 public-domain translations — KJV, ASV, YLT, BBE (31,102 verses each) |
28 Fundamental Beliefs | The official General Conference statement, with the proof texts each belief cites |
Ellen G. White | 6 public-domain books — Steps to Christ, The Desire of Ages, The Great Controversy, Patriarchs and Prophets, Christ's Object Lessons, Thoughts From the Mount of Blessing (8,745 paragraphs) |
Related MCP server: EGH Research
python3 -m venv .venv && ./.venv/bin/pip install -e ".[dev]"Build the database (downloads sources once, ~15 MB, then works offline):
./.venv/bin/python scripts/build_all.pyclaude mcp add adventist-study -- /absolute/path/to/adventist-mcp/.venv/bin/adventist-mcpOr add it to your MCP config manually:
{
"mcpServers": {
"adventist-study": {
"command": "/absolute/path/to/adventist-mcp/.venv/bin/adventist-mcp"
}
}
}Tool | Purpose |
| Start here. Full cross-source study on a doctrine: what the church teaches, the proof texts the belief statement itself cites (with verse text), further verses, and relevant EGW passages |
| A passage by reference — |
| Full-text search, optionally scoped to one book |
| All 28 beliefs by number and title, grouped by doctrinal category |
| Full text of one belief, by number or topic |
| Search across the 28 beliefs |
| Available EGW writings and their citation abbreviations |
| Search EGW writings; results carry standard citations ( |
| A full chapter from an EGW book |
study_topic and beliefs_get accept colloquial phrasing, not just formal doctrine
names. A curated topic index maps everyday questions to the right belief:
You ask | You get |
"what happens when we die", "soul sleep", "hell" | #26 Death and Resurrection |
"1844", "investigative judgment" | #24 Christ's Ministry in the Heavenly Sanctuary |
"tithing", "giving" | #21 Stewardship |
"can Adventists eat pork", "health message" | #22 Christian Behavior |
"is the law abolished" | #19 The Law of God |
Anything not in the index falls back to stemmed full-text search over the belief statements.
Each source can be re-ingested independently. Downloads are cached in data/raw/, so
re-runs are offline.
./.venv/bin/python scripts/ingest_bible.py # all four translations
./.venv/bin/python scripts/ingest_bible.py kjv asv # or a subset
./.venv/bin/python scripts/ingest_beliefs.py
./.venv/bin/python scripts/ingest_egw.py GC DAdata/adventist.db is a build artifact and is gitignored.
./.venv/bin/python -m pytest tests/ -qThe server speaks stdio by default. --transport streamable-http serves it over HTTP,
which is what non-local clients need. This path is wired but untested against any
specific remote client.
All bundled content is public domain or an official church publication:
Bible translations from scrollmapper/bible_databases — KJV (1769), ASV (1901), YLT (1898), BBE (1949).
The 28 Fundamental Beliefs from the official General Conference statement, as published by the Southern Zambia Union Conference.
Ellen G. White writings from the official Ellen G. White Estate PDF editions — all first published before 1929 and in the public domain. Page numbers in citations are the original printed pages, so GC 574 refers to the same text a print edition does.
The EGW corpus here is a small public-domain subset. The complete corpus is available through the official EGW Writings API, which requires registering an application and OAuth — a possible future addition.
Sabbath School quarterly lessons — no cleanly licensed source identified yet.
Languages other than English.
Get the full official text of a Fundamental Belief.
Args: number_or_topic: a number 1-28, or a topic such as "sabbath", "state of the dead", or "second coming".
| Name | Required | Description | Default |
|---|---|---|---|
| number_or_topic | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does convey the core behavior: returning the full official text of a fundamental belief, which signals a read-only retrieval operation. However, it does not disclose edge-case behavior such as handling of invalid numbers, ambiguous topics, case sensitivity, or whether topic matching is exact or fuzzy.
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 compact and front-loaded with the purpose in the first sentence. The parameter explanation is immediately useful and free of filler. Every sentence contributes to understanding how to invoke the tool, achieving maximum clarity in minimal space.
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?
For a simple one-parameter getter, the description is largely complete: it states what the tool returns and how to specify the input. The presence of an output schema reduces the need to explain return formatting. Minor gaps remain around topic-matching behavior and when to prefer sibling tools, but the core invocation context is well covered.
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 description coverage is 0%, so the description must compensate. It does so effectively for the only parameter: it specifies the valid range (numbers 1-28) and provides concrete examples ('sabbath', 'state of the dead', 'second coming'). This adds meaningful guidance beyond the bare string type in the schema, though it leaves out details like case sensitivity or formatting.
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 identifies the operation with a specific verb and resource: 'Get the full official text of a Fundamental Belief.' This distinguishes it from a search or list operation. However, it does not explicitly contrast itself with sibling tools like beliefs_search or bible_lookup, so it stops short of full differentiation.
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?
Usage is implied rather than explicit: the description indicates this tool retrieves a specific belief by number or topic, which suggests when to use it. But it does not state when not to use it or mention alternatives such as beliefs_search for finding beliefs by keyword. The context of the single parameter creates a reasonable inference, but no explicit routing guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all 28 Fundamental Beliefs by number and title, grouped by doctrinal category.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It clearly communicates that the tool returns a grouped, numbered list of all 28 beliefs, which is a safe, read-only operation. It does not discuss side effects, auth, or edge cases, but for a listing tool these are minimal concerns and the output schema is available.
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, compact sentence that front-loads the action and resource, then specifies the output organization. Every phrase earns its place: 'all 28' sets scope, 'by number and title' defines format, and 'grouped by doctrinal category' explains structure.
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 zero parameters, an output schema, and a simple listing purpose, the description covers the essential information an agent needs. It could be slightly more explicit about when to choose this over beliefs_get or beliefs_search, but the scope is clear enough for correct invocation.
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 tool accepts zero parameters, so there are no parameter semantics to document. Per the baseline for zero-parameter tools, a score of 4 is appropriate. The description's mention of grouping and numbering adds useful output context beyond the empty schema.
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 ('List'), a precise resource ('all 28 Fundamental Beliefs'), and the exact output format ('by number and title, grouped by doctrinal category'). The phrase 'all 28' clearly distinguishes this from sibling tools like beliefs_get and beliefs_search, which operate on individual or matching beliefs.
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 when to use the tool: when a complete, categorized enumeration of Fundamental Beliefs is needed, rather than a single-belief lookup or a search. It does not explicitly name alternatives or state when not to use it, but the 'all 28' phrasing provides clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the 28 Fundamental Beliefs for a word or phrase.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'search'. It does not reveal whether matching is exact, substring, or fuzzy, what parts of the beliefs are searched, how the limit affects results, or what kind of result structure is returned.
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, direct, front-loaded sentence with no wasted words. It immediately identifies the action and target resource and does not repeat schema details.
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?
For a simple search tool with an output schema and an optional limit parameter, this is minimally viable: the agent knows what to pass in 'query'. But it lacks guidance on result behavior, limit semantics, and when to prefer sibling belief tools, and there are no annotations to compensate.
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 schema has 0% description coverage, so the description must compensate. It clarifies that 'query' is a word or phrase, which addresses the only required parameter. However, it says nothing about 'limit', leaving its meaning to be inferred from the name and default value in the schema.
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?
States a specific verb ('Search'), a specific resource ('the 28 Fundamental Beliefs'), and the input type ('word or phrase'). This distinguishes it from sibling tools like bible_search and beliefs_get because both the operation and target corpus are clearly named.
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 use case is implied: call this when you need to find a word or phrase within the 28 Fundamental Beliefs. However, it does not explicitly state when not to use it or mention alternatives such as beliefs_get for retrieving a specific belief or beliefs_list for browsing all beliefs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a Bible passage by reference.
Args: reference: e.g. "John 3:16", "Romans 8:1-4", "Psalm 23" (whole chapter). translation: kjv, asv, ylt, or bbe. KJV is the default and the most commonly cited translation in Adventist study.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | ||
| translation | No | kjv |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it discloses the acceptable translation values, the default translation, and notes that KJV is preferred in Adventist study. It does not discuss behavior on invalid references or retrieval limits, but for a simple lookup tool the key behavioral details are clear.
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 compact and front-loaded with the core purpose, followed by a clearly structured Args section. Every clause contributes, including the Adventist context that helps explain why KJV is the default.
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?
For a simple lookup tool, the description covers the essential invocation details: reference syntax, translation choices, and default behavior. The main gap is the absence of guidance differentiating it from bible_search, though this is partially offset by the clear 'by reference' wording. An output schema exists, so return-value documentation is less necessary.
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 description coverage is 0%, so the description must fully compensate, and it does: reference is clarified with three concrete formats, and translation is documented with allowed values and the default. This adds material meaning beyond the bare input schema.
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 opening sentence 'Look up a Bible passage by reference' uses a specific verb and resource and clearly distinguishes it from the sibling bible_search tool, which would be for searching rather than direct reference lookup. The examples of references further cement the purpose.
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 per-argument usage details, such as examples of valid references and available translations, but it does not explicitly state when to choose bible_lookup over sibling tools like bible_search. There is no when-to-use or when-not-to-use guidance for the tool as a whole.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search the Bible for words or phrases.
Args: query: words to find; wrap in double quotes for an exact phrase. translation: kjv, asv, ylt, or bbe. limit: maximum verses to return (1-100). book: optional book name to restrict the search, e.g. "Daniel".
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | ||
| limit | No | ||
| query | Yes | ||
| translation | No | kjv |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It explains exact-phrase behavior, the translations accepted, the verse limit, and the optional book restriction. It does not explicitly declare read-only or no side effects, but the search verb inherently signals a non-mutating operation, making this adequate for the tool's risk profile.
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 one-line summary is front-loaded and followed by a compact Args block. Every line adds information; there is no filler or repetition of the schema's default values.
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?
For a straightforward search tool with an output schema, this description is complete: all four parameters are semantically defined, the search behavior is explained, and the optional book restriction is illustrated. No critical information is missing for correct invocation.
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 description coverage is 0%, so the description must fully document the parameters, and it does. It explains the query format with double quotes, enumerates the four translations, gives the 1-100 limit range, and clarifies that book is an optional restrictor with an example.
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 opens with 'Full-text search the Bible for words or phrases,' which names a specific verb, resource, and mode of operation. This clearly separates it from the sibling bible_lookup, which implies reference-based lookup rather than full-text searching.
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 docstring gives detailed per-argument usage, including how to form an exact-phrase query and how to restrict by book, but it never explicitly states when to choose this tool over bible_lookup or the other search siblings. Usage is implied by the 'full-text search' wording rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available Ellen G. White writings and their citation abbreviations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It accurately describes a read-only listing operation and implies no side effects, but it does not describe the output format, ordering, or what 'available' means in practice.
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, well-front-loaded sentence that states the verb and resource immediately. Every word earns its place, with no redundant phrasing.
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 simple zero-parameter nature and the presence of an output schema, the description is nearly complete for invocation purposes. The only minor gap is the ambiguity of 'available' — whether it means all known EGW writings or only those loaded in the current environment.
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 tool has zero parameters, so the baseline is 4. There is no parameter detail for the description to add, and the schema already confirms an empty parameter set.
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 ('List') and a resource ('available Ellen G. White writings and their citation abbreviations'). This clearly distinguishes the tool from siblings like egw_search and egw_get_chapter, which handle lookup and retrieval, not inventory.
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?
No explicit when-to-use or when-not-to-use guidance is provided, and no alternative tools are named. However, the purpose is clear enough that an agent can infer it is the right choice when it needs an inventory of EGW writings and abbreviations, especially given the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a full chapter from an Ellen G. White book.
Args: book: title or abbreviation (SC, DA, GC, PP, COL, MB). chapter: chapter number.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | ||
| chapter | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the behavioral burden. 'Retrieve a full chapter' clearly signals a read-only operation with no side effects. It does not mention formatting, size, or authentication, but for a simple chapter-fetch tool these are less critical and the output schema is said to exist.
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 compact and front-loaded. The opening sentence states exactly what the tool does, and the Args section adds only the necessary parameter detail. No filler or redundant content.
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?
For a low-complexity tool with two required parameters and an output schema, the description covers the essential usage: target book and chapter number, plus acceptable book abbreviations. It is nearly complete, though it could briefly note that the chapter is from the specified EGW book only, and it does not address potential invalid-input behavior.
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 description coverage is 0%, so the description must compensate. It does: 'book' is explained as a title or abbreviation with concrete examples (SC, DA, GC, PP, COL, MB), and 'chapter' is clarified as a chapter number. This adds real meaning beyond the bare schema types.
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 uses a specific verb-resource pair: 'Retrieve a full chapter from an Ellen G. White book.' It clearly distinguishes itself from sibling tools like egw_search and egw_books by targeting full-chapter retrieval rather than search or book listing.
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 when to use the tool (when a full chapter is needed) and clarifies the book argument with accepted abbreviations, but it does not explicitly state when not to use it or name alternatives such as egw_search for searching. Usage context is implied rather than explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Ellen G. White's public-domain writings.
Results carry standard citations (e.g. "DA 123" = The Desire of Ages, page 123).
Args: query: words to find; wrap in double quotes for an exact phrase. book: optional title or abbreviation (SC, DA, GC, PP, COL, MB). limit: maximum passages to return (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | ||
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It does add value by stating that results include standard citations and by explaining parameter semantics. However, it omits behavioral details such as whether the search is full-text, how book abbreviations are matched, or what happens with invalid inputs or no results. It is not contradictory, but it is only partially transparent.
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 concise and well-structured. A one-line purpose statement is followed by a useful result-format note, then a clean args list. Every sentence contributes necessary information, and the purpose is front-loaded so an agent can quickly decide whether to invoke the tool.
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?
For a simple search tool with three parameters and an output schema, the description covers the essential information: what to search, how to refine by book and limit, and what the results look like. It does not discuss error cases or edge behaviors, but the output schema and examples fill most gaps. A short note on valid book matching might make it fully 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?
The input schema has 0% description coverage, so the description must carry the full semantic weight. It does so thoroughly: query is defined with exact-phrase guidance, book lists accepted abbreviations/examples, and limit specifies the valid range (1-50). This adds substantial meaning beyond the bare type/default information in the schema.
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 starts with a clear verb and resource: 'Search Ellen G. White's public-domain writings.' This distinguishes it from sibling tools like bible_search and beliefs_search by explicitly naming the corpus. The citation example adds useful specificity without obscuring the core purpose.
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 its usage context by naming Ellen G. White's writings, which separates it from bible_search and beliefs_search. However, it provides no explicit guidance on when to choose this tool over siblings like egw_get_chapter or egw_books, nor does it mention when not to use it. The usage context is clear but not fully articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a full study on a doctrinal topic across all three sources.
Returns what the church officially teaches, the proof texts the belief statement itself cites (with full verse text), further verses on the topic, and relevant Ellen G. White passages. Use this for "why do Adventists believe X?" questions.
Args: topic: e.g. "the Sabbath", "the state of the dead", "the second coming", "baptism", "the sanctuary", "spiritual gifts". translation: kjv, asv, ylt, or bbe.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| translation | No | kjv |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains exactly what the tool returns: official church teaching, cited proof texts with full verse text, additional topic verses, and relevant EGW passages. It does not discuss edge cases such as unrecognized topics, but the core behavior is clearly disclosed.
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 well structured: a summary sentence, a concise return overview, a usage cue, and a compact Args list. Every sentence contributes useful information, with no filler or repetition of schema details.
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?
For a two-parameter aggregation tool, the description covers purpose, return contents, the ideal question type, topic examples, and translation choices. Since an output schema exists, the description does not need to explain return structure, and the tool appears fully specified for an agent to invoke it correctly.
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 0% description coverage, so the Args section must compensate, and it does. It provides concrete topic examples ('the Sabbath', 'the state of the dead', 'the second coming') and explicitly lists the accepted translation values ('kjv, asv, ylt, or bbe'), adding real meaning beyond the bare parameter names.
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 first sentence, 'Build a full study on a doctrinal topic across all three sources,' states a specific verb, resource, and scope. The detailed list of returns—official teaching, cited proof texts, further verses, and Ellen G. White passages—clearly distinguishes this integrated tool from the single-source sibling tools.
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 explicitly gives a canonical use case: 'Use this for "why do Adventists believe X?" questions.' It clearly implies this tool is for comprehensive doctrinal studies rather than narrow source-specific lookups, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0beliefs_getbeliefs_listbeliefs_searchbible_lookupbible_searchegw_booksegw_get_chapteregw_searchstudy_topicScored across 9 tools
Each tool targets a distinct resource and action: bible_lookup vs bible_search are clearly reference lookup vs full-text search, beliefs_list/get/search are separate, and the EGW tools separate book listing, search, and chapter retrieval. study_topic is intentionally integrative but distinguishable from the point-source tools.
Tool names mostly follow a predictable [resource]_[action] pattern with snake_case, such as bible_lookup, bible_search, beliefs_list, and egw_get_chapter. Minor inconsistency: egw_books omits an action verb and study_topic is a noun phrase rather than the verb-led pattern seen elsewhere.
Nine tools is well-scoped for the server's purpose of covering three source types (Bible, fundamental beliefs, and Ellen G. White writings) plus an integrated study builder. Each tool earns its place without redundancy.
The tool set provides full read access to all three major Adventist study sources: lookup and search for the Bible, list/get/search for beliefs, and list/search/chapter retrieval for EGW writings. study_topic ties them together, leaving no obvious dead ends for doctrinal research workflows.
Scripture-cited answers to any Bible question, plus verse text and study pages, for AI agents.
Search Ellen G. White’s writings by keyword to surface relevant quotations. Retrieve exact passage…
Faith tools for AI agents: cited KJV Scripture, ORA Q&A, sermons, churches, prayer & giving.
Christian AI for any question, in any season. Bible (BSB), grace + truth. faith.tools 5/5.
