The JW MCP Server provides tools to access and process content from JW.org, including Bible scriptures, meeting workbooks, Watchtower articles, and video captions, with multi-language support.
Bible Scripture Lookup: Search for Bible books by name, abbreviation, or number; retrieve plain verse text; or get study-enhanced content including study notes, cross-references, research guide articles, and chapter outlines (single verses or ranges)
JW.org URL Generation: Generate direct clickable links to Bible verses, verse ranges, or entire chapters on JW.org
CLM Workbook Access: Retrieve available "Our Christian Life and Ministry" workbook weeks (titles + RTF URLs) and download/parse RTF content into clean plain text (~70% token reduction)
Watchtower Articles: Discover available Watchtower study articles (automatically accounting for the 2-month publication offset) and download/parse their RTF content into clean plain text
Video Captions: Fetch video captions and metadata from JW.org using a video ID or any JW.org URL
Multi-language Support: All tools support multiple languages via the langwritten parameter (e.g., E for English, S for Spanish, F for French)
Works with MCP-compatible clients such as Claude Desktop, Claude Code, Cursor, and Windsurf.
Used for HTML parsing and web scraping to extract Bible verses, study notes, cross-references, and research articles from wol.jw.org.
Runtime environment for executing the MCP server with ES modules support.
Package manager for installing server dependencies and managing the project.
Provides tools for accessing JW.org content including Christian Life and Ministry Workbook materials, Watchtower study articles with RTF parsing, Bible scripture lookup with study notes and cross-references from wol.jw.org, and video captions retrieval.
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., "@JW MCP Server get John 3:16 with study notes"
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 working with JW.org content — Bible scripture lookup with study notes, workbook materials, Watchtower articles, and video captions.
claude mcp add jw-mcp -- npx -y jw-mcpDownload the latest jw-mcp.mcpb from Releases and open it — Claude Desktop will install it automatically.
Or add manually to your config (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):
{
"mcpServers": {
"jw-mcp": {
"command": "npx",
"args": ["-y", "jw-mcp"]
}
}
}npx -y jw-mcpRelated MCP server: jw-org-mcp
Run this server on a machine with a public HTTPS URL, then paste that URL into Grok, Claude.ai, or ChatGPT as a custom connector.
Compose binds the container to loopback only (127.0.0.1:8080). Do not publish port 8080 on the public internet. Put a reverse proxy on the host, terminate TLS there, and proxy to 127.0.0.1:8080.
Copy .env.example to .env.
Set MCP_BASE_URL to your public origin, with no path. Example: https://jw-mcp.example.com.
Set MCP_AUTH_SECRET to a long access key (at least 16 characters).
Keep MCP_AUTH=true. HTTP mode with auth off is loopback-only. Do not disable auth in Docker.
Set MCP_TRUST_PROXY=true only when the reverse proxy overwrites X-Forwarded-For. Leave it unset otherwise.
Start it:
docker compose up --build -dThe connector URL is:
https://your-host/mcpWhen you add the connector, the AI site opens a login page. Type the same access key you put in MCP_AUTH_SECRET.
Client | Where to add it |
Grok | grok.com/connectors → New Connector → Custom |
Claude.ai | Customize → Connectors → Add custom connector |
ChatGPT | Settings → enable Developer mode → add the server URL |
Local HTTP (http://localhost:8080) is fine for testing because compose binds loopback. Claude, ChatGPT, and Grok must reach a public HTTPS URL. A tunnel such as ngrok or Cloudflare Tunnel can expose that loopback port for a live click-test. Do not publish 8080 on 0.0.0.0.
Auth codes, clients, and tokens are stored in the jw-mcp-auth Docker volume so a container restart does not drop every connection.
All tools support multiple languages via the langwritten parameter (E = English, S = Spanish, F = French, etc.).
search_bible_booksSearch for Bible books by name, abbreviation, or number.
{ "query": "matthew" }get_bible_verseGet plain verse text from wol.jw.org. Books are numbered 1-66 (1-39 OT, 40-66 NT).
{ "book": 43, "chapter": 3, "verse": 16 }get_verse_with_studyGet verses with study notes, cross-references, and research articles. Supports ranges.
{
"book": 40, "chapter": 5, "verse": "3-5",
"fields": ["verses", "study_notes", "study_articles"]
}Available fields: verses, study_notes, study_articles, cross_references, chapter_level, combined_text
get_bible_verse_urlGenerate JW.org URLs for verses, ranges, or chapters — useful for adding clickable links to documents.
{ "book": 19, "chapter": 83, "verse": "18" }
{ "book": 23, "chapter": 46, "verse": "9-11" }
{ "book": 40, "chapter": 5 }
getWorkbookLinksGet available Christian Life and Ministry workbook weeks for the current or a specific issue.
{ "issue": "20250500", "langwritten": "E" }getWorkbookContentDownload and parse a workbook week's RTF content to clean plain text (70% token reduction).
{ "url": "https://cfp2.jw-cdn.org/a/clm_E_202505_01.rtf" }
getWatchtowerLinksGet available Watchtower study articles. Automatically uses the correct issue (published 2 months ahead of study period).
{ "issue": "20250300", "langwritten": "E" }getWatchtowerContentDownload and parse a Watchtower article's RTF content to clean plain text (70% token reduction).
{ "url": "https://cfp2.jw-cdn.org/a/w_E_202509_01.rtf" }
get_jw_captionsFetch video captions and metadata by video ID or any JW.org URL.
{ "video_id": "pub-jwbvod25_17_VIDEO" }Also accepts full JW.org URLs — the video ID is extracted automatically.
"Could not read package.json" — Use absolute path in Claude Desktop config
Server disconnects — Ensure Node.js is installed (npm install)
Permission denied — chmod +x start-server.sh
npm start # stdio mode (local)
npm run start:http # HTTP mode (testing)
npm test # OAuth + HTTP connector testsBuilt with Node.js, MCP SDK, node-fetch, and cheerio.
MIT
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('just the verse text without study notes or additional content'), which is valuable behavioral context. However, it doesn't mention potential limitations like rate limits, authentication needs, or error conditions, leaving some behavioral aspects unspecified.
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 with zero waste: the first sentence states the purpose and output, and the second provides usage guidance. It's front-loaded with essential information and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 required parameters, no output schema, no annotations), the description is mostly complete: it clarifies the purpose, distinguishes from siblings, and describes the return format. However, it could benefit from mentioning potential errors or limitations to be fully 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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, which is acceptable given the high coverage, resulting in the baseline score of 3.
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 specific action ('Get plain Bible verse text') and resource ('from wol.jw.org'), distinguishing it from sibling tools like 'get_verse_with_study' by specifying it returns 'just the verse text without study notes or additional content'. This provides precise 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?
The description explicitly states when to use this tool ('for plain Bible verse text') and when to use an alternative ('For comprehensive study content including notes and cross-references, use get_verse_with_study instead'), providing clear guidance on tool selection.
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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses key behavioral traits: it returns a direct link, supports various verse formats (single, range, comma-separated), and converts contiguous comma-separated verses to ranges. However, it doesn't mention error handling, rate limits, or authentication needs, leaving some gaps for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the first sentence stating the core purpose. Each subsequent sentence adds useful context without waste, such as usage examples, sibling tool reference, and practical application. No redundant or verbose phrasing is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is largely complete. It covers purpose, usage, and behavioral aspects well. However, it lacks details on output format (e.g., URL structure) and error cases, which could be helpful since there's no output schema. This minor gap prevents a perfect score.
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 thoroughly. The description adds minimal value beyond the schema by briefly mentioning verse formats and the optional nature of 'verse', but it doesn't provide additional syntax or format details. This meets the baseline of 3 for high schema 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 the specific action ('Get the jw.org URL for a Bible verse or range of verses') and distinguishes it from sibling tools by specifying it returns a direct link, unlike tools like 'get_bible_verse' or 'get_verse_with_study' which likely return content. It explicitly mentions the resource (Bible verses on jw.org) and verb (get URL).
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 explicit guidance on when to use this tool ('Perfect for adding clickable scripture links to markdown documents') and when to use alternatives ('Use search_bible_books to find book numbers'). It clearly differentiates from siblings by focusing on URL generation rather than content retrieval or search.
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. |
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 does disclose a key behavior: auto-extraction of video ID from a URL. However, it doesn't mention whether the operation is read-only, what happens on invalid inputs, or any rate limits/auth requirements. The word 'fetches' implies a read operation, but this is implicit rather than explicit.
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, consisting of two sentences. The first sentence states the primary function and input options, while the second provides illustrative examples. No unnecessary words or repetition, making it an exemplar of efficient description.
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 tool with one parameter and no output schema, the description covers the essential aspects: purpose, accepted inputs, and extraction behavior. It doesn't detail the exact return format (e.g., plain text vs. structured captions), but this is a minor gap given the tool's simplicity and clear primary function.
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 description for the single parameter already covers the core semantics (video ID or URL, auto-extraction). The tool description adds valuable concrete examples (e.g., 'pub-jwbvod25_17_VIDEO' and a full URL) that go beyond the schema, helping the agent understand the accepted formats. This exceeds the baseline of 3 set by high schema 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 the tool 'Fetches video captions from JW.org' with a specific verb and resource. It further specifies the input types (video ID or URL) and includes concrete examples, which fully distinguishes it from sibling tools that handle workbook, watchtower, or Bible content.
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 context for when to use this tool: fetching captions for videos on JW.org. It doesn't explicitly exclude alternatives, but the siblings are all for distinct content types (links, content, Bible verses, lessons), making the intended use unmistakable. A slight deduction for not stating 'when not to use' or explicitly naming alternatives.
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. Options: "verses" (verse text), "study_notes" (verse-specific notes), "study_articles" (research guide articles), "cross_references" (related scriptures), "chapter_level" (outline and chapter content), "combined_text" (all verses as single text). Default: ["verses", "study_notes"] | |
| chapter | Yes | Chapter number within the book |
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 mentions the source ('wol.jw.org') and that it 'Returns verse text, study notes...', but does not disclose critical behaviors such as rate limits, authentication requirements, error handling, or pagination for large verse ranges. The 'fetch' parameter hint about 'fresh data' is useful but insufficient for comprehensive 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 efficiently structured in two sentences: the first states the purpose and scope, the second details the return content and customization. It is front-loaded with key information and avoids redundancy, though it could be slightly more concise by integrating the field examples into the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose, return content, and parameter customization, but lacks details on behavioral aspects (e.g., rate limits, errors) and does not fully compensate for the missing output schema by describing the response structure. It is minimally viable 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds marginal value by mentioning 'single verses or ranges' for the 'verse' parameter and 'customize what content is returned' for 'fields', but does not provide additional syntax, format details, or usage examples beyond what the schema specifies. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Get Bible verse(s) with comprehensive study content'), resource ('from wol.jw.org'), and scope ('single verses or ranges'). It distinguishes itself from siblings like 'get_bible_verse' by emphasizing comprehensive study content including notes, articles, and cross-references, not just verse 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 for retrieving enriched Bible content with study materials, but does not explicitly state when to use this tool versus alternatives like 'get_bible_verse' (which likely returns only verse text) or 'search_bible_books' (for finding book numbers). It mentions field selection for customization but lacks explicit guidance on tool selection scenarios.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the tool's process: takes the RTF URL, downloads the RTF file, parses it to plain text, and returns formatted workbook content. This goes beyond a simple 'get' and reveals the underlying workflow. It does not mention error handling or side effects, but for a read-only parse operation, this level of detail is sufficient.
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: the first sentence states the purpose, the second provides usage sequencing and process details. It is front-loaded with the action ('Get'), includes a step indicator, and avoids unnecessary fluff. Every sentence contributes to understanding 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?
The tool has a single parameter, no annotations, and no output schema, so the description must cover purpose, usage, process, and return value. It does all of this: it explains the inputs (RTF URL from getWorkbookLinks), the process (download, parse), and the output (formatted workbook content with line breaks). The flow context is also provided, making it complete for an agent to invoke 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 schema description coverage for the 'url' parameter is 100%, already explaining that it is the RTF file URL from getWorkbookLinks results. The tool description reinforces this by stating it takes the RTF URL from Step 1, adding context about the source and format. This achieves the baseline of 3 and earns an extra point for reinforcing the parameter's provenance.
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 actual CLM workbook content' after the user chooses a week. It specifies the resource (CLM workbook), the verb (get), and distinguishes from sibling tools like getWatchtowerContent by explicitly referencing getWorkbookLinks as the source. The step numbering and mention of RTF parsing make the function unmistakable.
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 explicit when-to-use guidance: 'Use this tool AFTER getWorkbookLinks when user specifies which week they want.' It even gives example week formats. This clearly sequences the tool relative to its sibling and explains the prerequisite, leaving no ambiguity about when to select 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 "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?
No annotations are provided, so the description carries the full burden. It discloses the return format (weekly titles with RTF URLs) and the automatic month/year behavior. However, it does not describe pagination, limit of results, error handling, or indicate that this is a non-destructive read operation. The extra context about STEP 1 adds workflow transparency but not deep behavioral detail.
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, front-loaded with 'STEP 1' and a gerund phrase that immediately states the action. Every sentence contributes: purpose, usage timing, return value and default behavior. No filler or redundant information. It is concise and well-structured.
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 4 optional parameters and no output schema, the description covers the essential return value (weekly titles with URLs) and the default behavior (current month/year). It does not explain how the URLs might be used downstream or what happens with no results, but the focus on listing available weeks is sufficient for its simple role. The missing details are minor.
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 baseline is 3. The description adds minimal semantic value: it mentions automatic use of current month/year (already in the 'issue' parameter) and RTF URLs (already in 'fileformat'). No new parameter nuances are introduced. The schema already handles parameter documentation.
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 tool's function: getting JW.org CLM meeting workbook weeks, returning weekly titles with RTF download URLs. It distinguishes itself from siblings like getWorkbookContent by positioning itself as the first step. The verb 'Get' and specific resource 'JW.org CLM workbook weeks' make the purpose unmistakable.
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 the tool: 'When a user asks for CLM workbook content, use this tool FIRST.' It also explains the automatic fallback to current month/year. While it doesn't explicitly list alternatives or exclusions, the 'FIRST' directive implies a workflow priority over content tools. This is clear context with a strong usage hint, but lacks direct comparison to alternatives.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_bible_verseget_bible_verse_urlget_jw_captionsget_verse_with_studygetWatchtowerContentgetWatchtowerLinksgetWorkbookContentgetWorkbookLinkssearch_bible_booksScored across 9 tools
Most tools have distinct purposes, but there is some overlap between get_bible_verse and get_verse_with_study, as both retrieve Bible verses, though the latter includes study content. The descriptions clearly differentiate them, reducing confusion. Other tools target unique resources like captions, Watchtower articles, or workbook content, making them easy to distinguish.
Naming is inconsistent, mixing snake_case (e.g., get_bible_verse) with camelCase (e.g., getWatchtowerContent) and varying verb styles. Some tools use 'get' prefix, while others use 'search', but the pattern is not uniform across all tools. This inconsistency can make the tool set harder to navigate and predict.
With 9 tools, the count is well-scoped for a JW.org content server, covering Bible verses, study materials, Watchtower articles, and meeting workbooks. Each tool serves a specific function, and there are no extraneous tools, making the set manageable and focused on the domain.
The tool set covers key areas like Bible access, study content, and publication retrieval, with clear workflows (e.g., getWatchtowerLinks followed by getWatchtowerContent). Minor gaps might include direct search for publications or additional Bible study features, but core operations are well-covered, allowing agents to perform most tasks without dead ends.
Bible translations, books, chapters, verses, and search
Scripture-cited answers to any Bible question, plus verse text and study pages, for AI agents.
Summarize and transcribe videos, audio, documents and web pages; subtitles; search your library.
Read-only BSB and WEB Scripture evidence with provenance, context, comparison, and search.
