Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses an important and non-obvious behavior: poetic books are stored as separate lines and are joined here, ensuring complete verses. It also specifies the translation and source. It does not mention return format or error conditions, but the core behavior is well covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, each earning its place: purpose, a specific behavioral nuance, and an alternative-tool pointer. It is front-loaded with the primary action and avoids any filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the rich schema coverage, and no output schema, the description is complete. It covers the source, translation, the special line-joining behavior, and the alternative for study notes. There are no significant gaps that would impair an agent's ability to select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides 100% coverage of all four parameters, including descriptions and examples for book numbers and language codes. The tool description does not add extra parameter semantics, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's function: retrieving plain Bible verse text from a specific source (wol.jw.org, NWT Study Edition). It distinguishes itself from sibling get_verse_with_study by explicitly stating it returns plain text, not study notes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit guidance: use this tool for plain verse text, and use get_verse_with_study for study notes and cross-references. This directly addresses when to use the tool versus its main alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must disclose behavioral traits on its own. It does so by explaining that omitted verse returns the entire chapter, and that comma-separated verses 'will convert to range if contiguous.' This adds meaningful insight into tool behavior. It does not cover failure modes or edge cases, but for a simple URL generator, the disclosed behavior is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, opening with the core purpose, then detailing supported verse formats and implementation notes. Every sentence adds information: the return type, the verse handling rules, the book number lookup reference, and the markdown use case. No fluff or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (4 flat parameters, no output schema), the description covers all essential aspects: input formats, default behavior, and common use cases. It references search_bible_books for book numbers and aligns langwritten with sibling tools. It misses explicit differentiation from get_bible_verse (content vs. URL), but the purpose and use case already imply this distinction.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has 100% coverage of all parameters with descriptions, so the baseline is 3. The description does add some interpretive value by explaining the comma-separated conversion and default language, but this largely repeats what the schema states. It also adds a pointer to search_bible_books, which is helpful but not a major semantic enhancement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the jw.org URL for a Bible verse or range of verses.' It specifies the output (direct link) and distinguishes from sibling content tools like get_bible_verse that likely return scripture text. The examples and use case ('adding clickable scripture links') reinforce its unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides practical guidance on when to use the tool, such as 'Perfect for adding clickable scripture links to markdown documents.' It also directs users to search_bible_books for book numbers and notes the langwritten parameter matches other tools. However, it does not explicitly state when NOT to use this tool versus alternatives like get_bible_verse, leaving some room for ambiguity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose a key behavior: auto-extraction of video ID from a URL. However, it doesn't mention whether the operation is read-only, what happens on invalid inputs, or any rate limits/auth requirements. The word 'fetches' implies a read operation, but this is implicit rather than explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, consisting of two sentences. The first sentence states the primary function and input options, while the second provides illustrative examples. No unnecessary words or repetition, making it an exemplar of efficient description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the essential aspects: purpose, accepted inputs, and extraction behavior. It doesn't detail the exact return format (e.g., plain text vs. structured captions), but this is a minor gap given the tool's simplicity and clear primary function.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description for the single parameter already covers the core semantics (video ID or URL, auto-extraction). The tool description adds valuable concrete examples (e.g., 'pub-jwbvod25_17_VIDEO' and a full URL) that go beyond the schema, helping the agent understand the accepted formats. This exceeds the baseline of 3 set by high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'Fetches video captions from JW.org' with a specific verb and resource. It further specifies the input types (video ID or URL) and includes concrete examples, which fully distinguishes it from sibling tools that handle workbook, watchtower, or Bible content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: fetching captions for videos on JW.org. It doesn't explicitly exclude alternatives, but the siblings are all for distinct content types (links, content, Bible verses, lessons), making the intended use unmistakable. A slight deduction for not stating 'when not to use' or explicitly naming alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 only the supported lesson range (1-116) but omits behavior for invalid inputs, language selection defaults, authentication needs, or return format. Minimal disclosure 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that is direct and front-loaded with the resource name and action. No filler or redundant explanation, every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple content retrieval tool with full schema parameter coverage and no output schema, the description provides essential context: resource name, scope, and valid range. Missing details like error cases or response language are not critical given the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover both parameters fully (language enum with default ko, lesson_number with min/max). The tool description restates the range in prose but adds no additional semantic meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb '가져옵니다' (fetches) and names the exact resource '「하느님의 교훈이 담긴 성경 이야기 (훈)」' with scope '특정 과' (specific lesson) and range 1-116. This clearly distinguishes it from sibling tools like get_lesson_list or getWorkbookContent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives such as get_lesson_list for listing lessons or get_bible_verse for scripture. The description only implies it is for specific lesson content; no exclusions or alternative tool references.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description bears full responsibility for behavioral disclosure. It only says 'entire list' but does not explain that start/end parameters allow subsetting, what the list items contain, or how language affects output. The term '전체 목록' also slightly conflicts with the ability to specify a range via the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that immediately conveys the tool's core function. It is appropriately concise for a simple list-fetching operation with no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema and annotations, the description should explain the return format and parameter behavior, but it only states that it fetches the entire list. It does not mention that start/end control the range, the meaning of '언어 코드', or that the response is a list of lesson titles. This is a notable gap for a tool with three configurable parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have schema descriptions with defaults and ranges (start, end, language), so schema coverage is 100%. The tool description adds no additional parameter semantics beyond what the schema already provides, maintaining the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states '「하느님의 교훈이 담긴 성경 이야기 (훈)」 전체 목록을 가져옵니다' which clearly identifies the resource and the action (fetching the full list). This distinguishes it from sibling tools like get_lesson_content, which fetches the actual lesson content. The specific publication name and verb '가져옵니다' make the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided; the description neither explains when to prefer this tool over get_lesson_content nor when a range parameter would be appropriate. It simply states what it does without any contextual instructions. This leaves the agent to infer the tool's positioning from its name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden of behavioral disclosure. It describes what the tool returns and its source (wol.jw.org), which is helpful. However, it omits behavioral traits such as caching behavior (the 'fetch' parameter forces fresh data) and default field selection, which are important for setting user expectations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the purpose and clearly list the returned content. Every word earns its place, with no redundant information or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter tool with no output schema, the description provides a solid high-level overview, including the types of returned content and the ability to customize fields. However, it does not address important operational details like the default fields, the limit parameter's effect on list fields, or the meaning of fetch, though these are covered in the schema. It is adequate but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, and the schema itself provides detailed parameter descriptions. The tool description adds a verse range example and mentions field selection, which supplements but does not significantly exceed schema information. This aligns with the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get Bible verse(s) with comprehensive study content', listing specific content types (verse text, study notes, cross-references, research articles, chapter outlines). This differentiates it from the simpler sibling tool get_bible_verse, which likely returns only verse text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives like get_bible_verse. It implies use when comprehensive study content is needed, but lacks direct guidance such as 'for plain verse text, use get_bible_verse instead.' The usage context is implied through the feature list, not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description details the download-convert process and enumerates the structured object's components, giving transparency about output. No annotations exist, so this description carries the burden, and it sufficiently explains behavior without side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured, starting with a clear step label and a concise summary, then providing necessary detail about the structured object. No unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description adequately describes both return formats and their fields, enabling the agent to know what to expect. It also hints at token-saving via the structured parameter, though that's in schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover all four parameters with examples and default behavior. The tool description reinforces the URL source but doesn't add significant new meaning beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves Watchtower article content, converting an RTF URL to plain text and structured data. It distinguishes itself from getWatchtowerLinks by referencing it as the source and marking this as STEP 2.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says to use the RTF URL from getWatchtowerLinks and provides guidance on choosing between `structured` and `parsedText`, indicating appropriate usage contexts. It does not explicitly state when not to use the tool, but the sequential reference implies its role.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 auto-picks the issue, returns machine-readable dates and isCurrentWeek, and that wolUrl resolution costs an extra request. It does not disclose the exact return format (e.g., array vs object) but provides sufficient behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then provides necessary context about publication timing and output fields. While slightly verbose (around 100 words), every sentence adds useful information; the example about July 2026/May 2026 is helpful, not fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the key output (weekStart/weekEnd, isCurrentWeek, wolUrl) and the automatic issue selection, which is essential for correct use. It does not fully detail the return structure or error/edge cases, but given the tool's simplicity and no output schema, it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema—it emphasizes that no parameters are needed for the current week and explains the issue date offset, which is already in the schema. No additional value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'STEP 1: Get JW.org Watchtower study articles,' which clearly states the verb (get), resource (Watchtower study articles), and scope (JW.org). It distinguishes this tool from siblings like getWatchtowerContent by focusing on articles and their associated links/metadata, not content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says to use this tool FIRST for current/this week's Watchtower content and without parameters, explaining the auto-selection logic. However, it does not explicitly mention alternatives or when-not-to-use cases, though the sibling names imply content retrieval would follow this step.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the tool's process: takes the RTF URL, downloads the RTF file, parses it to plain text, and returns formatted workbook content. This goes beyond a simple 'get' and reveals the underlying workflow. It does not mention error handling or side effects, but for a read-only parse operation, this level of detail is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: the first sentence states the purpose, the second provides usage sequencing and process details. It is front-loaded with the action ('Get'), includes a step indicator, and avoids unnecessary fluff. Every sentence contributes to understanding the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a single parameter, no annotations, and no output schema, so the description must cover purpose, usage, process, and return value. It does all of this: it explains the inputs (RTF URL from getWorkbookLinks), the process (download, parse), and the output (formatted workbook content with line breaks). The flow context is also provided, making it complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage for the 'url' parameter is 100%, already explaining that it is the RTF file URL from getWorkbookLinks results. The tool description reinforces this by stating it takes the RTF URL from Step 1, adding context about the source and format. This achieves the baseline of 3 and earns an extra point for reinforcing the parameter's provenance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get the actual CLM workbook content' after the user chooses a week. It specifies the resource (CLM workbook), the verb (get), and distinguishes from sibling tools like getWatchtowerContent by explicitly referencing getWorkbookLinks as the source. The step numbering and mention of RTF parsing make the function unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance: 'Use this tool AFTER getWorkbookLinks when user specifies which week they want.' It even gives example week formats. This clearly sequences the tool relative to its sibling and explains the prerequisite, leaving no ambiguity about when to select it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the return format (weekly titles with RTF URLs) and the automatic month/year behavior. However, it does not describe pagination, limit of results, error handling, or indicate that this is a non-destructive read operation. The extra context about STEP 1 adds workflow transparency but not deep behavioral detail.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with 'STEP 1' and a gerund phrase that immediately states the action. Every sentence contributes: purpose, usage timing, return value and default behavior. No filler or redundant information. It is concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 optional parameters and no output schema, the description covers the essential return value (weekly titles with URLs) and the default behavior (current month/year). It does not explain how the URLs might be used downstream or what happens with no results, but the focus on listing available weeks is sufficient for its simple role. The missing details are minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value: it mentions automatic use of current month/year (already in the 'issue' parameter) and RTF URLs (already in 'fileformat'). No new parameter nuances are introduced. The schema already handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool's function: getting JW.org CLM meeting workbook weeks, returning weekly titles with RTF download URLs. It distinguishes itself from siblings like getWorkbookContent by positioning itself as the first step. The verb 'Get' and specific resource 'JW.org CLM workbook weeks' make the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool: 'When a user asks for CLM workbook content, use this tool FIRST.' It also explains the automatic fallback to current month/year. While it doesn't explicitly list alternatives or exclusions, the 'FIRST' directive implies a workflow priority over content tools. This is clear context with a strong usage hint, but lacks direct comparison to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the transparency burden. It explains that it searches English names/abbreviations and, with langwritten set, other languages' names/abbreviations. Examples show input/output behavior. It doesn't discuss ordering, limit, or error cases, but for a simple search tool this is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph with 4 sentences. It front-loads the purpose, then provides language details and examples. Every sentence earns its place with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with no output schema, the description covers what it does, why it's needed, and gives examples. It could be more explicit about the exact return format (book name and number) and edge cases, but it is adequate for an agent to select and use the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by providing concrete query examples ('matt', '잠언') and clarifying the langwritten effect. It does not add detail about limit, but the schema already describes it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Search for Bible books by name or abbreviation and get their book number (1-66)'. It also differentiates from siblings by noting that other scripture tools require the book number. Examples reinforce the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'which the other scripture tools require' gives strong context for when to use this tool: as a lookup step before using other scripture tools. Examples show usage patterns, but it doesn't explicitly name alternatives or state when not to use it, so not a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.