JW Research MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.1.0
Disambiguation5/5
Each 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.
Naming Consistency3/5
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.
Tool Count4/5
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.
Completeness5/5
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.
Average 3.7/5 across 20 of 20 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden but discloses minimal behavioral traits. It does not mention read-only status, auth requirements, rate limits, error handling, or response structure beyond vague 'linked research trail'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence, front-loaded with the core action. It is efficient, though the second clause is a fragment. No extraneous details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is incomplete. It omits output structure, error states, and usage patterns. The 'research trail' concept is vague without further detail, especially given sibling tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so baseline is 3. The description adds no additional meaning to parameters (e.g., no explanation of 'format' choices or 'langwritten' usage). It focuses on output rather than parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool builds a 'linked research trail' from a WOL article, specifying outputs include subheading anchors and similar-material recommendations. However, it does not explicitly differentiate from sibling tools like get_cross_references or search_wol_library that may also return related content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_article_full for full text, search_wol_library for broader searches). The description lacks 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden 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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It 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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like '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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses 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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's 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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jw-research-mcp MCP server](https://glama.ai/mcp/servers/prreobby/jw-research-mcp/badges/card.svg)](https://glama.ai/mcp/servers/prreobby/jw-research-mcp)

Score Badge

Copy to your README.md:

[![jw-research-mcp MCP server](https://glama.ai/mcp/servers/prreobby/jw-research-mcp/badges/score.svg)](https://glama.ai/mcp/servers/prreobby/jw-research-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/prreobby/jw-research-mcp'

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