JW MCP Server

Server Quality Checklist

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

Latest release: v1.3.2
Disambiguation4/5
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 Consistency2/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4/5 across 9 of 9 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 9 commits in the last 12 weeks
- Last stable release on August 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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 provided, so the description carries the full burden. It describes the input behavior (accepts ID or URL, extracts ID from URL) but does not disclose critical traits like authentication needs, rate limits, error handling, or output format. For a tool with no annotations, this leaves significant behavioral gaps.
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 front-loaded with the core purpose and efficiently uses two sentences to explain input formats with clear examples. Every sentence adds essential information without redundancy, making it highly concise and well-structured.
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 no annotations, no output schema, and a single parameter with high schema coverage, the description is incomplete. It lacks information on output (e.g., caption format, structure), error cases, or behavioral constraints, which are crucial for a tool fetching external data. The description does not compensate for these gaps adequately.
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 the parameter. The description adds value by explaining the semantics of 'video_id' (e.g., examples of ID and URL formats, automatic extraction from URL), but it does not provide additional details beyond what the schema implies. Baseline 3 is appropriate as the schema handles most documentation.
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 specific action ('fetches video captions') and resource ('from JW.org by video ID or URL'), distinguishing it from sibling tools that focus on Bible verses, Watchtower, or workbook content. It precisely defines what the tool does without ambiguity.
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 specifying input formats (video ID or URL) but does not explicitly state when to use this tool versus alternatives or provide context on prerequisites. It offers basic guidance but lacks explicit when/when-not directives or named alternatives.
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 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.
Conciseness4/5
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.
Completeness3/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the automatic current month/year behavior and RTF format focus, which are useful behavioral traits. However, it doesn't mention potential rate limits, authentication needs, error conditions, or pagination behavior for the returned list of weeks.
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 appropriately sized and front-loaded with the core purpose. The 'STEP 1' framing and automatic behavior explanation are useful. However, the phrasing could be slightly more concise by integrating the RTF and automatic behavior into the main purpose statement rather than as separate sentences.
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 4 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate context about when to use it and the automatic behavior. However, it doesn't describe the structure of returned data (beyond mentioning titles and URLs) or potential limitations, leaving some gaps for an agent to understand the complete tool behavior.
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 fully documents all 4 parameters. The description adds minimal parameter semantics beyond the schema - it mentions 'RTF download URLs' which aligns with the fileformat parameter, and 'current month/year' which relates to the issue parameter. 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.
Purpose4/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 JW.org "Our Christian Life and Ministry" (CLM) meeting workbook weeks' and specifies it returns weekly titles with RTF download URLs. It distinguishes from sibling 'getWorkbookContent' by indicating this tool shows available weeks first, but doesn't explicitly contrast with other workbook-related tools like 'getWatchtowerLinks'.
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?
The description provides explicit usage guidance: 'When a user asks for CLM workbook content, use this tool FIRST to show them available weeks.' This clearly indicates when to use this tool versus alternatives like 'getWorkbookContent' for actual content, and specifies the automatic current month/year behavior.
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 provided, the description carries the full burden of behavioral disclosure. It adequately describes the search functionality and return format (book numbers and names), but doesn't mention potential limitations like case sensitivity, partial matching behavior, or error handling for invalid queries.
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 efficiently structured with three sentences: purpose statement, usage context, and concrete examples. Every sentence adds value, and the examples are directly relevant to understanding the tool's functionality.
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 search tool with no annotations and no output schema, the description provides adequate context about what the tool does and its purpose. However, without an output schema, it could benefit from more detail about the exact structure of returned results beyond 'book numbers and names'.
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?
The input schema has 100% description coverage, providing complete documentation for both parameters. The description adds minimal value beyond the schema by mentioning examples of query formats, but doesn't provide additional semantic context about parameter interactions or constraints.
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 specific action ('Search for Bible books'), resource ('by name or abbreviation'), and output ('Returns book numbers (1-66) and names'). It distinguishes this tool from siblings like get_bible_verse by focusing on book metadata rather than verse content.
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 context for when to use this tool ('Useful for finding the correct book number for other scripture tools'), establishing its role as a helper for other Bible-related operations. However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings.
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 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.
Conciseness5/5
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.
Completeness4/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines5/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 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.
Behavior4/5
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 effectively describes key behaviors: automatic issue calculation ('server automatically calculates correct issue'), timing logic ('Watchtower publications are 2 months ahead'), return format ('article titles... with their RTF download URLs'), and default parameter usage. It doesn't mention error handling or rate limits, but covers most essential operational aspects.
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 appropriately sized and front-loaded with the core purpose and usage instructions. Every sentence serves a clear function: establishing purpose, providing usage guidelines, explaining timing logic, describing returns, and reinforcing default usage. It could be slightly more concise by combining some timing explanations, but overall it's well-structured with minimal waste.
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 tool's moderate complexity (4 parameters, no annotations, no output schema), the description provides good contextual completeness. It covers purpose, usage guidelines, behavioral aspects like automatic calculation and timing logic, and return format. The main gap is the lack of output schema, but the description compensates by describing what's returned. For a read-only tool with good parameter documentation, this is sufficient.
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 thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions using defaults for current articles and explains the timing logic for the issue parameter, but doesn't provide additional syntax or format details. This meets the baseline expectation when schema coverage is high.
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 JW.org Watchtower study articles' with specific details about the resource (current/this week's Watchtower content) and distinguishes it from potential alternatives by specifying it should be used 'FIRST without any parameters' for current articles, differentiating from sibling tools like getWatchtowerContent which might handle different use cases.
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?
The description provides explicit usage guidelines: 'When a user asks for current/this week's Watchtower content, use this tool FIRST without any parameters' and explains the timing logic (2-month ahead publication). It also implies when not to use it (e.g., for non-current articles or other publications), though it doesn't name specific alternatives beyond the context of sibling tools.
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 provided, the description carries the full burden of behavioral disclosure. It describes the tool's processing steps (download, parse, clean, format) and output characteristics ('formatted workbook content with proper line breaks and structure'), which is helpful. However, it doesn't address potential behavioral aspects like error handling, rate limits, authentication requirements, or file size limitations that might be relevant for a download and parsing operation.
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 appropriately sized and front-loaded with the most important information (when to use the tool). Every sentence adds value, though the 'STEP 2' framing could be slightly more concise. The structure effectively guides the agent through the workflow context and tool 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?
For a single-parameter tool with no output schema and no annotations, the description does a good job explaining the tool's purpose, usage context, and processing behavior. It could be more complete by addressing potential error cases or output format details, but given the tool's relative simplicity and clear workflow positioning, it provides sufficient context for effective use.
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 schema description coverage is 100%, so the schema already documents the single parameter. The description adds meaningful context by specifying that the URL should come 'from getWorkbookLinks results' and provides an example URL pattern, which helps the agent understand the parameter's provenance and format beyond the basic schema definition.
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 specific action ('downloads the RTF file, parses it to clean plain text, and returns the formatted workbook content') and resource ('CLM workbook content'), distinguishing it from sibling tools like getWorkbookLinks (which provides links) and getWatchtowerContent (which handles different content). It explicitly mentions the tool's role in a two-step workflow.
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?
The description provides explicit guidance on when to use this tool ('AFTER getWorkbookLinks when user specifies which week they want') and includes examples of user input ('e.g., "May 5-11" or "June 30-July 6"'). It clearly positions this as Step 2 in a specific workflow, making the usage context unambiguous.
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?
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.
Conciseness5/5
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.
Completeness4/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behaviors: it downloads files, parses RTF to clean plain text, and returns formatted content with structure and line breaks. It doesn't mention error handling, rate limits, or authentication needs, but provides substantial operational context for a read 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?
Perfectly structured with zero waste. The first sentence establishes purpose and positioning, the second explains the processing pipeline, and every phrase adds value. It's front-loaded with the most important information (when to use) and maintains appropriate density.
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 single-parameter tool with no output schema, the description provides excellent context about the workflow, processing behavior, and expected output format. It could mention what happens with invalid URLs or network errors, but covers the essential operational context thoroughly 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 the single 'url' parameter. The description adds marginal value by specifying this is 'The RTF file URL from getWatchtowerLinks results' and providing an example URL pattern, but doesn't add significant semantic information beyond what the schema provides.
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 with specific verbs ('downloads', 'parses', 'returns') and resources ('RTF file', 'article content'). It distinguishes from sibling getWatchtowerLinks by specifying this is 'STEP 2' for getting content after article selection, not for listing links.
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 states when to use ('AFTER getWatchtowerLinks when user specifies which article they want') and provides concrete examples of user requests ('Imitate the Faithful Angels' or 'Look to Jehovah for Comfort'). It clearly positions this tool in a workflow sequence with its sibling.
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-mcp MCP server](https://glama.ai/mcp/servers/advenimus/jw-mcp/badges/card.svg)](https://glama.ai/mcp/servers/advenimus/jw-mcp)

Score Badge

Copy to your README.md:

[![jw-mcp MCP server](https://glama.ai/mcp/servers/advenimus/jw-mcp/badges/score.svg)](https://glama.ai/mcp/servers/advenimus/jw-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/advenimus/jw-mcp'

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