Click on "Install 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., "@JW Research MCP search WOL for 'hope'"
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.
A remote Model Context Protocol server for traceable research across JW.org and
the Watchtower Online Library. This project extends
advenimus/jw-mcp with full WOL
articles, publication pagination, direct library search, Study Bible footnotes,
full-text cross-references, daily texts, caching, and optional server-side
research synthesis with Kimi. Paragraphs, scriptures, related articles, and
publication images retain direct source links for verification.
The original tool names and workflows remain available:
search_bible_books
get_bible_verse
get_verse_with_study
get_bible_verse_url
getWorkbookLinks / getWorkbookContent
getWatchtowerLinks / getWatchtowerContent
get_jw_captions
get_verse_with_study.fields now also accepts footnotes. WOL exposes
translation footnotes separately from both study notes and marginal
cross-references, so no content is duplicated between those fields.
Related MCP server: jw-org-mcp
Tool | Purpose |
| Full translation footnotes for a verse |
| Complete article with paragraph anchors, live inline links, images, and related material |
| Paginated full-size images, thumbnails, captions, alt text, and exact source anchors |
| Linked subheadings and WOL-recommended similar material |
| Bounded publication slices by sequential TOC entry and paragraph page |
| Direct article URLs, including natural TOC pages for large works |
| Direct WOL full-text search |
| Topic search for images across matching WOL articles |
| Marginal references with complete cited verse text |
| Daily scripture and comment for a date |
| Conversational Kimi K3 synthesis with evidence, URLs, confidence, gaps, and follow-ups |
All network-backed responses contain:
{
"metadata": {
"source_url": "https://...",
"timestamp": "2026-07-28T00:00:00.000Z",
"cache_hit": false
}
}The default cache TTL is 15 minutes. Retrieval tools accept langwritten;
supported WOL routes currently include E, S, F, X, I, T, J,
KO, and U. Research retrieval tools support format: "json" and
format: "markdown".
Markdown output uses clickable titles, paragraph source anchors, scripture references, footnotes, related articles, and image links. JSON output retains both plain text and source URLs for programmatic use.
analyze_research supports four modes:
answer — direct evidence-based response
explore — map themes and connections
compare — contrast publications, passages, or time periods
verify — audit a claim and identify missing evidence
Use depth: "focused", "deep", or "exhaustive". For follow-up questions,
pass a concise conversation_context; it preserves continuity but is never
treated as source evidence. Every result includes a short answer, deep
synthesis, source-linked key points, confidence ratings, consistency or
tension findings, uncertainties, a source index, and suggested follow-ups.
For maximum accuracy, retrieve broad evidence in bounded pages first, include
each block's source and source_url, and then call analyze_research.
get_book_content treats chapter as a 1-based sequential entry in the
publication TOC. A call returns at most three chapters and 25 paragraphs per
chapter. Use page and next_page, or an explicit paragraph_range, to walk
the content without placing an entire bound volume in one model context.
{
"publication_code": "it",
"chapter_range": "1-3",
"page": 1,
"page_size": 15,
"langwritten": "E",
"format": "json"
}For large reference works such as Insight on the Scriptures,
get_publication_toc also exposes WOL's natural TOC pages.
Requires Node.js 20 or newer.
npm install
npm run typecheck
npm test
npm startTo test Streamable HTTP:
cp .env.example .env
npm run build
MCP_TRANSPORT=http MCP_AUTH=false npm run start:httpThen run the MCP Inspector:
npx @modelcontextprotocol/inspectorConnect it to http://localhost:8080/mcp.
The live WOL smoke test is:
npm run build
node scripts/smoke-live.mjsVariable | Default | Description |
|
| Use |
|
| HTTP listen port |
| local URL | Public Railway URL used in OAuth metadata |
|
| Set |
| — | Required when OAuth is enabled; minimum 8 characters |
| — | Required only by |
|
| Kimi model used for research synthesis |
|
| OpenAI-compatible Kimi API base URL |
|
| In-memory fetch cache TTL |
|
| Default |
The included multi-stage Dockerfile compiles TypeScript and the included
railway.toml uses /health for deployment health checks. Configure the
environment variables above, deploy, generate a Railway domain, then set
MCP_BASE_URL to that exact https://... domain and redeploy.
The MCP endpoint is:
https://YOUR-RAILWAY-DOMAIN/mcpKeep this connector separate from existing services until its retrieval and analysis behavior has been verified with your own research workflow.
The automated suite verifies:
footnotes remain distinct from study notes and cross-references
full-article paragraph numbering and marker preservation
linked paragraph citations, media captions, and related-material parsing
hard paragraph pagination bounds
cache-hit behavior
localized WOL route construction
schema-validated analyze_research JSON without Markdown fences
The live smoke test additionally verifies a real Insight TOC and pagination, WOL search, article media, related research trails, full-text cross-references, daily text parsing, and cached repeats.
Forked from advenimus/jw-mcp.
Licensed under the MIT license of the upstream project.
Conduct conversational, evidence-bound JW research with Kimi K3. Supports deep synthesis, comparison, claim verification, source URLs, confidence, uncertainties, and follow-up questions.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | Controls analytical coverage. Exhaustive should be used after retrieving broad paginated evidence. | deep |
| content | Yes | Text, text blocks, or {source,text} blocks returned by the retrieval tools. | |
| research_mode | No | answer gives a direct response; explore maps a topic; compare contrasts sources; verify audits a claim. | answer |
| research_question | Yes | ||
| conversation_context | No | Optional summary of earlier questions and findings for a conversational follow-up. It is context, not source evidence. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks disclosure of side effects, permissions, or rate limits. It does not state if the tool is read-only or modifies state. The mention of 'Kimi K3' and 'conversational' hints at LLM usage but is unclear.
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 (two sentences) but reads as a feature list. Efficient, but could be more structured with bullet points.
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 5 parameters, no output schema, and no annotations, the description partially covers output features (confidence, follow-up questions) but does not explicitly state return format or prerequisite flow with retrieval tools.
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 high (80%), so baseline 3. The description adds no extra parameter detail; the schema already explains depth, research_mode, and content well.
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 it conducts conversational, evidence-bound research and supports synthesis, comparison, verification, etc. It distinguishes from sibling tools which are retrieval-focused.
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 it is used after retrieving evidence, but does not explicitly state when to use vs alternatives or provide exclusions. No guidance on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a complete WOL article with numbered paragraphs, exact paragraph source URLs, clickable inline references, images, and related material.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A https://wol.jw.org article URL | |
| format | No | json | |
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently lists output features (numbered paragraphs, URLs, references, images, related material), implying a read-only, non-destructive operation. However, it does not mention authorization requirements, rate limits, or error handling, but these are typical for a get tool.
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-structured sentence that efficiently conveys the tool's core value without redundancy or extraneous details. Every word serves a purpose.
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 3 parameters, no output schema, and 18 sibling tools, the description covers the key output aspects and is sufficient for a straightforward retrieval tool. It could mention that the URL must be a valid WOL article URL, but otherwise it is adequately 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 67% (url and langwritten described; format has enum/default but no description). The description does not add meaning to parameters beyond what the schema provides. It focuses on output rather than parameter usage, so the agent gains no extra insight into how to use format or langwritten correctly.
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 'Get a complete WOL article' with a list of specific components (numbered paragraphs, source URLs, references, images, related material), making the tool's purpose and scope very clear. It distinguishes itself from sibling tools like get_article_media or get_related_content by emphasizing completeness.
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 guidance is provided on when to use this tool versus similar ones like get_article_media, get_related_content, or get_cross_references. The description lacks context for selection or prerequisites (e.g., requiring a valid WOL URL).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get paginated images from one WOL article with full-size and thumbnail URLs, captions, alt text, dimensions, paragraph references, and exact source links.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A https://wol.jw.org article URL | |
| page | No | ||
| format | No | json | |
| page_size | No | ||
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It describes output fields but does not disclose any behavioral traits such as authentication requirements, rate limits, error handling (e.g., invalid URL), or whether it is read-only. The name suggests a read operation, but safety information is missing.
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 well-constructed sentence that front-loads the core action and resource. It is concise without superfluous words. While dense, it earns its place by conveying the tool's purpose and output.
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 5 parameters, pagination, and no output schema, the description covers the output fields but omits details on pagination behavior, optional parameter effects, and return structure. The sibling list provides context but the description does not leverage it to clarify when to use this tool. Incomplete for a paginated media retrieval 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 description coverage is 40% (only 2 of 5 parameters have descriptions). The description adds context for the url parameter by implying it is a WOL article, but does not explain parameters page, format, page_size, or langwritten. With low coverage, the description fails to compensate and leaves parameter usage unclear.
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 'Get' and the resource 'paginated images from one WOL article', and lists the specific data fields returned (full-size and thumbnail URLs, captions, alt text, dimensions, paragraph references, exact source links). This distinguishes it from siblings like search_wol_media (searching media) and get_article_full (full article text).
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 by stating 'from one WOL article' (requires a specific article URL), but does not explicitly state when to use this tool versus alternatives like search_wol_media or when not to use it. No exclusions or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get plain Bible verse text from wol.jw.org. Returns just the verse text without study notes or additional content. For comprehensive study content including notes and cross-references, use get_verse_with_study instead.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Bible book number (1-66). Examples: Genesis=1, Matthew=40, John=43, Revelation=66. Use search_bible_books to find book numbers. | |
| verse | Yes | Verse number within the chapter | |
| chapter | Yes | Chapter number within the book | |
| langwritten | No | JW language code, such as E, S, or F | E |
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 states the tool returns plain verse text without notes, implying a read-only operation, but does not disclose other behavioral traits like rate limits, authentication, or error handling. The description adds some value but lacks full transparency.
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 extremely concise with two sentences, front-loading the core purpose, and contains no superfluous information.
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 text retrieval tool with 100% schema coverage and no output schema, the description adequately covers the purpose, scope, and distinction from a sibling. It does not elaborate on error handling or edge cases, but this is reasonable given the tool's simplicity.
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 100%, so the schema already documents all parameters. The description does not add additional parameter semantics beyond what is in the schema. 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 the tool gets plain Bible verse text from wol.jw.org and distinguishes it from the sibling tool get_verse_with_study by specifying it returns only verse text without notes.
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 clear guidance on when to use this tool (for plain verse text) and when to use an alternative (get_verse_with_study for comprehensive study content). It does not mention other sibling tools but the distinction is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the jw.org URL for a Bible verse or range of verses. Returns a direct link to view the scripture on jw.org. Supports single verses (e.g., verse: "18"), verse ranges (e.g., verse: "14-16"), and comma-separated verses (e.g., verse: "1,3,5" - will convert to range if contiguous). Use search_bible_books to find book numbers. Perfect for adding clickable scripture links to markdown documents.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Bible book number (1-66). Examples: Genesis=1, Psalms=19, Isaiah=23, Matthew=40, Revelation=66. Use search_bible_books to find book numbers. | |
| verse | No | Optional verse reference. Can be: single verse ("18"), verse range ("14-16"), or comma-separated verses ("1,3,5"). If omitted, returns URL for the entire chapter. | |
| chapter | Yes | Chapter number within the book | |
| langwritten | No | JW language code for wtlocale | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It explains supported verse formats and automatic range conversion for contiguous comma-separated verses. However, it lacks details on error handling (e.g., invalid book numbers) or potential limitations like non-contiguous comma-separated verses not being converted.
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: three sentences with efficient front-loading of purpose. It includes examples of supported formats without extraneous text.
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 no output schema, the description states the return value ('direct link to view the scripture on jw.org'). For a simple URL-returning tool with 4 parameters and no nested objects, this is adequate. It covers the main use case, though could mention the URL's format or potential redirection.
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 100% with each parameter described. The description adds value by detailing the verse parameter behavior (single, range, comma-separated) and noting conversion to range if contiguous, which is not in the schema's brief description.
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's purpose: 'Get the jw.org URL for a Bible verse or range of verses.' It uses specific verb 'Get' and resource 'jw.org URL', and distinguishes from siblings like search_bible_books and get_bible_verse by implying it returns a link rather than text.
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 usage context: 'Perfect for adding clickable scripture links to markdown documents.' It also mentions search_bible_books for finding book numbers, offering a path for prerequisite steps. However, it does not explicitly state when not to use this tool versus alternatives like get_bible_verse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a bounded, paginated slice of a publication. Chapter numbers are 1-based sequential TOC entries. At most 3 chapters and 25 paragraphs per chapter are returned per call.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| format | No | json | |
| chapter | No | 1-based sequential TOC entry | |
| page_size | No | ||
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
| chapter_range | No | At most 3 entries, for example "1-3" | |
| paragraph_range | No | Optional explicit range, for example "1-20" | |
| publication_code | Yes | WOL publication code, such as it or rs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses key constraints: 1-based chapter numbering, maximum of 3 chapters and 25 paragraphs per chapter per call. However, it does not mention whether the operation is read-only, authentication needs, error handling, or pagination behavior for the 'page' parameter.
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?
Two concise sentences provide all key information without filler. The most important action ('Get a bounded, paginated slice') is front-loaded, and constraints are clearly listed.
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 8 parameters, no output schema, and no annotations, the description is not fully complete. It explains return caps but omits output format, pagination logic for 'page', the role of 'langwritten', and does not clarify what happens when constraints are exceeded.
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 description adds meaning beyond the schema by clarifying that chapter numbers are 1-based and that 'chapter_range' is limited to 3 entries. It also ties 'page_size' and 'paragraph_range' to the return limits (max 25 paragraphs per chapter). Schema coverage is 63%, so the description partially compensates for undocumented parameters like 'page' and 'format'.
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's purpose: 'Get a bounded, paginated slice of a publication.' It specifies verb ('Get'), resource ('slice of a publication'), and adds constraints (max 3 chapters, 25 paragraphs per chapter) that distinguish it from sibling tools like 'get_publication_toc' which provides TOC structure.
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 guidance is provided on when to use this tool versus alternatives like 'get_publication_toc' or 'get_article_full'. The description does not mention context, dependencies, or scenarios where this tool is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Study Bible marginal cross-references for one verse, including the complete text of each referenced verse.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Bible book number (1-66) | |
| verse | Yes | ||
| format | No | json | |
| chapter | Yes | ||
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the main behavior: returning cross-references with full verse text. No annotations exist, so the description handles transparency. It lacks details on limits or error states, but the core action is 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?
One 14-word sentence, front-loaded with key action and scope. No filler or redundancy. 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?
For a tool with 5 parameters, no output schema, and no annotations, the description is minimal. It omits the meaning of 'marginal cross-references', format options, and potential default behaviors (e.g., missing book?). Adequate but not comprehensive.
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 40% with only book and langwritten described. The description adds no parameter details (e.g., what format='markdown' means or how chapter/verse relate). It does not compensate for missing schema descriptions.
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 it retrieves 'Study Bible marginal cross-references for one verse' and includes 'complete text of each referenced verse'. This verb+resource combination distinguishes it from sibling tools like get_bible_verse or get_footnotes.
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 when needing cross-references for a specific verse but provides no explicit guidance on when not to use it or which sibling alternatives (e.g., get_footnotes for footnotes) might be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the daily text scripture and comment for a date.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | YYYY-MM-DD; defaults to today | |
| format | No | json | |
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behaviors like error handling or output format. It only states the action without any behavioral details.
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 directly states the purpose without any filler. It is front-loaded and efficient.
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?
The description is minimal but covers the essential action. However, it does not explain output format or edge cases, which would be helpful given no output schema.
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 67%, and the description adds no extra meaning beyond the schema. The 'format' parameter lacks a description and the tool description does not compensate.
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 verb 'Get' and the specific resource 'daily text scripture and comment for a date'. It distinguishes from siblings which deal with publications, Bible verses, or media.
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 guidance is provided on when to use this tool versus alternatives like search_wol_library or get_bible_verse. There is no mention of prerequisites or contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full Study Bible footnote text for one verse. Footnotes are kept distinct from study notes and marginal cross-references.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Bible book number (1-66) | |
| verse | Yes | ||
| format | No | json | |
| chapter | Yes | ||
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes the action without revealing behavioral traits such as error handling, authentication, rate limits, or response format. Minimal disclosure for a read tool, but insufficient for full transparency.
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?
Two sentences, front-loaded with the core purpose, no redundant or extraneous words.
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?
Despite having 5 parameters and no output schema, the description does not explain the return value format or structure. It is adequate for a simple fetch but incomplete regarding response expectations and edge cases.
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 60% (3 of 5 parameters have descriptions). The description adds no new parameter information beyond the schema; it only reiterates the verse input. Baseline is 3 due to moderate coverage, and the description does not compensate for the missing parameter descriptions.
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 verb 'Get' and the resource 'full Study Bible footnote text' for 'one verse'. It distinguishes footnotes from study notes and marginal cross-references, providing clear differentiation from sibling tools like get_cross_references.
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 notes that footnotes are distinct from study notes and cross-references, indicating when this tool is appropriate (for footnotes) and implicitly that other tools are for other references. However, it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetches video captions from JW.org by video ID or URL. Accepts either a direct video ID (e.g., "pub-jwbvod25_17_VIDEO") or a JW.org URL (e.g., "https://www.jw.org/finder?srcid=jwlshare&wtlocale=E&lank=pub-jwbvod25_17_VIDEO")
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | The JW.org video ID or a JW.org URL containing the video ID. If a URL is provided, the video ID will be automatically extracted. | |
| langwritten | No | JW language code | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose output format, authentication needs, rate limits, or any side effects. Only input handling is described, leaving behavioral aspects unclear.
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?
Two sentences, front-loaded with core purpose, followed by input clarification with examples. No unnecessary words or repetition.
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 simple tool and no output schema, the description is partially complete. It explains inputs well but omits what the captions contain or how they are returned. The langwritten parameter is not described.
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 baseline is 3. The description adds examples but does not provide new information beyond the schema property descriptions. The langwritten parameter is not mentioned in the description.
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 it fetches video captions from JW.org, specifying the resource and source. It distinguishes from sibling tools which are primarily for publications, Bible, and library content, not captions.
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 states what inputs are accepted (ID or URL) with examples, making usage clear. It does not mention when not to use or alternatives, but the tool's specificity reduces need for such guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a publication table of contents with direct article URLs. Large reference works expose natural TOC pages that can be walked with page/next_page.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Alternative WOL publication URL | |
| page | No | ||
| format | No | json | |
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
| publication_code | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full burden. It hints at pagination behavior ('walked with page/next_page') but does not disclose read-only nature, authentication needs, rate limits, or error handling.
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 two sentences long, with the first stating the core purpose and the second adding useful context about pagination. It is efficient with no redundant words.
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 5 parameters and no output schema, the description does not explain the structure of the returned TOC, such as fields included, nor does it cover error scenarios or prerequisites like publication availability.
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 only 40%, and the description adds no information about any of the 5 parameters. It does not explain the purpose of url, page, format, langwritten, or publication_code beyond what little is 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 clearly states the tool gets a publication table of contents with direct article URLs, which is a specific function. It distinguishes from siblings like get_book_content by focusing on TOC, but does not explicitly contrast with other 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 mentions that large reference works expose natural TOC pages that can be walked, implying use for such publications, but provides no explicit guidance on when to use this tool over siblings or 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.
Get Bible verse(s) with comprehensive study content from wol.jw.org. Supports single verses or ranges (e.g., "14-16"). Returns verse text, study notes, cross-references, research articles from the Research Guide, and chapter outlines. Field selection allows you to customize what content is returned.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | Bible book number (1-66). Use search_bible_books to find book numbers. | |
| fetch | No | Force fresh data from wol.jw.org (useful when content appears to be missing). Default: false | |
| limit | No | Maximum number of study articles to return. Default: 5 for articles, unlimited for other fields. | |
| verse | Yes | Single verse number (e.g., "14") or verse range (e.g., "14-16") | |
| fields | No | Content fields to include. "footnotes" are translation footnotes and are distinct from "study_notes". Default: ["verses", "study_notes"] | |
| chapter | Yes | Chapter number within the book | |
| langwritten | No | JW language code, such as E, S, or F | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It mentions the ability to force fresh data via the fetch parameter, but lacks details on authentication, rate limits, caching behavior, or prerequisites. Basic transparency is present but incomplete.
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—two sentences covering purpose, supported ranges, return content, and customization. No unnecessary words or redundant information.
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?
While the description explains what fields are returned, it does not describe output structure or pagination. Given the complexity (7 parameters, many siblings) and absence of output schema, slightly more detail would be ideal, but the core functionality is captured.
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 100%, so the schema already documents all parameters. The description adds minimal value: it reinforces field selection and gives a verse range example, but these are also present in the schema. 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 the tool retrieves Bible verses with comprehensive study content from wol.jw.org, specifying the return of verse text, study notes, cross-references, and more. It distinguishes itself from simpler tools like get_bible_verse by emphasizing study content and customization via field selection.
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 comprehensive study (versus simpler verse lookup) but does not explicitly state when to use this tool versus alternatives like get_bible_verse or search_wol_library. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
STEP 2: Get the actual Watchtower article content after user chooses an article. Use this tool AFTER getWatchtowerLinks when user specifies which article they want (e.g., "Imitate the Faithful Angels" or "Look to Jehovah for Comfort"). Takes the RTF URL from Step 1 results, downloads the RTF file, parses it to clean plain text, and returns the formatted article content with proper structure and line breaks.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The RTF file URL from getWatchtowerLinks results (e.g., "https://cfp2.jw-cdn.org/a/...") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It describes the process: takes RTF URL, downloads, parses to plain text, and returns formatted content. Missing potential issues like encoding errors or size limits, but core behavior is 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?
Description is a single paragraph with clear structure: purpose, condition, details. It is concise but could be slightly more streamlined. No wasted words overall.
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 no output schema, description explains the return value (formatted article content with structure and line breaks). It covers the input parameter and the tool's context within a workflow. Adequate for a simple 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% for the single parameter. Description adds context by specifying the parameter is the RTF URL from getWatchtowerLinks results and provides an example URL, which adds meaning beyond 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 clearly states the tool's action: get Watchtower article content after user selection. It specifies the step in a workflow (STEP 2) and distinguishes it from sibling tools like getWatchtowerLinks by mentioning it is used AFTER that step.
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?
Explicitly says when to use: after getWatchtowerLinks when user specifies an article. Provides example user requests (e.g., 'Imitate the Faithful Angels'). No ambiguity about 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.
STEP 1: Get JW.org Watchtower study articles. When a user asks for current/this week's Watchtower content, use this tool FIRST without any parameters - it automatically gets the correct issue for current study articles (Watchtower publications are 2 months ahead, so May 2025 studies come from March 2025 issue). Returns article titles like "Imitate the Faithful Angels (July 14-20)" with their RTF download URLs. Just use defaults for current articles.
| Name | Required | Description | Default |
|---|---|---|---|
| pub | No | Publication code: "w" for Watchtower (Study edition) | w |
| issue | No | Issue in YYYYMM00 format. Leave empty for current study articles (server automatically calculates correct issue - Watchtower studies are 2 months ahead of publication) | |
| fileformat | No | File format: "RTF" for Rich Text Format | RTF |
| langwritten | No | Language code: "E" for English, "S" for Spanish, etc. | E |
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 that it automatically gets the correct issue, that no parameters are needed for current articles, and returns titles with URLs. It also explains the 2-month offset. It does not mention permissions, rate limits, or side effects, but those are not likely required.
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 front-loaded with 'STEP 1' and key purpose, then provides necessary context. It is informative without being overly verbose, though it could be slightly tightened.
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 parameters and no output schema, the description is complete enough for the primary use case (current articles). It does not cover advanced usage with non-default parameters, but that is secondary. The explanation of the timing offset adds necessary context.
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 100%, so the schema already documents all parameters. The description adds practical context like default behavior and the timing offset, but does not significantly add meaning beyond the schema. 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 it gets JW.org Watchtower study articles and returns article titles with RTF download URLs. It distinguishes from siblings by specifying it's for current/this week's Watchtower content and should be used FIRST.
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 states when to use this tool (for current/this week's Watchtower content) and advises to use it FIRST without parameters. It also explains the timing offset. However, it does not provide guidance on when not to use it or alternatives for other editions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
STEP 2: Get the actual CLM workbook content after user chooses a week. Use this tool AFTER getWorkbookLinks when user specifies which week they want (e.g., "May 5-11" or "June 30-July 6"). Takes the RTF URL from Step 1 results, downloads the RTF file, parses it to clean plain text, and returns the formatted workbook content with proper line breaks and structure.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The RTF file URL from getWorkbookLinks results (e.g., "https://cfp2.jw-cdn.org/a/...") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the process: downloads RTF, parses to clean plain text, returns formatted content with line breaks. This transparently sets expectations for a read-only operation.
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?
Four sentences, front-loaded with purpose and usage, no wasted words. Every sentence 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 one parameter and no output schema, the description fully covers input, process, and output format. No gaps for this simple 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% and the schema's parameter description already explains the URL source. The tool description adds workflow context but doesn't significantly enhance parameter semantics beyond 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 clearly states 'Get the actual CLM workbook content' with a specific verb and resource. It distinguishes itself from siblings like getWorkbookLinks by positioning as STEP 2, making its purpose unambiguous.
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?
Explicitly instructs to use after getWorkbookLinks when the user specifies a week, providing example inputs. While it doesn't state when not to use, the workflow context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
STEP 1: Get JW.org "Our Christian Life and Ministry" (CLM) meeting workbook weeks. When a user asks for CLM workbook content, use this tool FIRST to show them available weeks. Returns weekly titles like "May 5-11 (Proverbs 12)" with their RTF download URLs. Automatically uses current month/year for the issue.
| Name | Required | Description | Default |
|---|---|---|---|
| pub | No | Publication code: "mwb" for Meeting Workbook (CLM workbook) | mwb |
| issue | No | Issue in YYYYMM00 format. Leave empty to use current month/year automatically (e.g., "20250500" for May 2025) | |
| fileformat | No | File format: "RTF" for Rich Text Format | RTF |
| langwritten | No | Language code: "E" for English, "S" for Spanish, etc. | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it reads data (retrieves weeks), returns specific content (titles with RTF URLs), and auto-defaults the issue. However, it does not mention error behavior or authentication requirements.
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 two concise sentences, front-loaded with the key action 'STEP 1: Get...', and no unnecessary words. Every sentence 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?
For a simple retrieval tool with well-documented schema, the description covers purpose, usage context, and return format. It lacks details on edge cases or error handling, but is largely complete given the tool's straightforwardness.
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?
All 4 parameters have descriptions in the schema (100% coverage), so baseline is 3. The description adds minimal extra meaning beyond schema, e.g., clarifying the auto-default for issue, but largely repeats schema info.
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 retrieves CLM meeting workbook weeks, specifying it returns weekly titles and RTF download URLs. It explicitly positions this as STEP 1, distinguishing it from sibling tools like getWorkbookContent.
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 says to use this tool FIRST when a user asks for CLM workbook content, providing clear usage context. However, it does not explicitly list when not to use it or name alternatives beyond the step sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for Bible books by name or abbreviation. Returns book numbers (1-66) and names. Useful for finding the correct book number for other scripture tools. Examples: "matt" -> Matthew (40), "1 john" -> 1 John (62), "gen" -> Genesis (1).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | Search query - can be book name, abbreviation, or number. Examples: "matthew", "matt", "mt", "40", "1 john" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of transparency. It accurately describes that the tool returns book numbers and names, and gives examples. No behavioral information is omitted beyond what is reasonable for a simple lookup tool.
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 three sentences long, front-loads the main purpose, and includes examples. Every sentence adds value without redundancy.
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 low complexity of the tool, the description covers all necessary aspects: purpose, input, output, and use case. The schema fully describes parameters, so no further detail is required.
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% with both parameters described. The description adds meaningful context, such as the return format (book numbers 1-66 and names) and concrete examples, which adds value beyond the schema alone.
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 searches for Bible books by name or abbreviation and returns book numbers and names. This distinct purpose is well-differentiated from sibling tools like get_bible_verse or search_wol_library.
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 mentions that the tool is 'useful for finding the correct book number for other scripture tools,' providing clear guidance on when to use it. While it doesn't explicitly state when not to use it, the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Watchtower Online Library directly and return WOL article/topic results with excerpts and direct URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| format | No | json | |
| language | No | Alias for langwritten | |
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the basic action and output, omitting behavioral traits such as read-only nature, rate limits, or authentication needs. The superficial description adds minimal transparency.
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, achieving conciseness and front-loading the essential purpose. It could benefit from slight restructuring to include more context, but it is not verbose.
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 having 20 sibling tools and 5 parameters with low schema coverage, the description is insufficient. It does not help the agent distinguish this search from other specific search tools, nor does it explain output format or limits.
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 40% (only language and langwritten have descriptions). The description does not clarify the remaining parameters (limit, query, format) beyond their names. It adds no semantic value to compensate for the low coverage.
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 it searches the Watchtower Online Library and returns results with excerpts and URLs. However, it does not differentiate from sibling tools like search_wol_media or search_bible_books, which also search the same library but for different content types.
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 guidance on when to use this tool vs alternatives is provided. There is no mention of preferred use cases, prerequisites, or exclusions, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find relevant WOL publication images by topic. Searches WOL, scans matching articles, and returns bounded image results with captions and exact article/image links.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| format | No | json | |
| language | No | Alias for langwritten | |
| image_limit | No | Maximum images to return | |
| langwritten | No | JW language code. Defaults to DEFAULT_LANGUAGE or E. | E |
| article_limit | No | Maximum matching articles to inspect |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool searches WOL, scans matching articles (bounded by article_limit), and returns images with captions and exact links. It doesn't mention authentication or rate limits, but these are often not required. The behavior is adequately 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?
Two sentences with a front-loaded purpose statement. Every word earns its place; no repetition or fluff. Efficiently communicates the tool's function and output.
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 6 parameters, no output schema, and no annotations, the description covers the core functionality well. It could be slightly more complete by mentioning the format parameter or explicitly bounding limits, but overall it provides sufficient context for an AI agent to use the tool 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?
Schema coverage is 67% (4 of 6 parameters have descriptions), so baseline is 3. The description adds value by mentioning 'bounded image results' and 'captions and exact links', which clarify return format not in schema. However, it doesn't explain the meaning of bounded (i.e., image_limit and article_limit).
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 'Find' and identifies the resource as 'WOL publication images', which clearly distinguishes it from sibling tools like search_wol_library (text search) and get_article_media (media for a specific article).
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 phrase 'by topic' indicates when to use the tool. While it doesn't explicitly state when not to use or list alternatives, the context of sibling tools provides implicit guidance. A direct mention of alternatives like 'Use search_wol_library for text searches' would elevate this.
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. Dates show when Glama detected each change.
v2.1.0analyze_researchget_article_fullget_article_mediaget_bible_verseget_bible_verse_urlget_book_contentget_cross_referencesget_daily_textget_footnotesget_jw_captionsget_publication_tocget_related_contentget_verse_with_studygetWatchtowerContentgetWatchtowerLinksgetWorkbookContentgetWorkbookLinkssearch_bible_bookssearch_wol_librarysearch_wol_mediaEach tool targets a distinct resource or action: Bible verses, study content, publications, media, workbook/Watchtower materials, and research analysis. The step-by-step workflow tools (getWorkbookLinks/getWorkbookContent) are clearly paired, and overlapping tools like get_bible_verse vs get_verse_with_study are distinguished by depth of content. No confusion between tool purposes.
The majority use a consistent 'verb_noun' pattern with snake_case (get_*, search_*), but three tools break this: getWorkbookLinks, getWorkbookContent (camelCase), and analyze_research (different verb). This inconsistency, while not severe, prevents a perfect score.
20 tools is on the high end but appropriate for the broad scope of JW research, covering Bible study, publications, media, meeting materials, and AI-assisted analysis. Each tool serves a specific function without unnecessary redundancy, though a few could potentially be merged.
The tool surface covers all major JW research workflows: Bible verse access with study aids, publication browsing and content retrieval, media search, meeting materials (workbook and Watchtower), and advanced synthesis via analyze_research. The only possible gap is a more comprehensive publication search, but the library search and article tools mitigate this.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Bible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Remote MCP server for AIStoryHub: stories, chapters, story bible, Voiceprints, AI generation.
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Remote MCP server for supportsheep: run AI interviews and manage support content for your blog.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/prreobby/jw-research-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
