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

With no annotations, the description carries the full burden of behavioral disclosure. It adds critical context by specifying that category paths must be exact, wrong paths will 404, and offering a fallback strategy via search_gospel_library. It also notes the lang default behavior, going beyond the basic listing semantics.

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 purpose and keeps critical warnings in the IMPORTANT section. It is somewhat long but every sentence earns its place, with no redundant or vague phrasing.

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?

This is a simple two-parameter tool with no output schema. The description covers purpose, use cases, parameter nuances, error behavior (404), and fallback to a sibling tool, 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?

Although the schema already covers both parameters (100% coverage), the description enriches the semantics with concrete path examples, warnings against generic paths, and an explicit default for lang. This adds meaningful value beyond the schema definitions.

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 lists articles and talks in a Gospel Library category, returns titles and URLs, and differentiates from siblings by focusing on browsing categories rather than searching or fetching single items.

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 identifies use cases ('browsing conference sessions, scripture books, or magazine issues'), tells the agent to use search_gospel_library first when unsure of a path, and warns against guessing generic paths that will 404. This provides strong when-to-use and when-not-to-use guidance.

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 transparency burden. It discloses that the tool returns clean markdown text and that lang defaults to the OS locale language, which adds meaningful behavioral context. It does not mention error cases or side effects, but for a read-only fetch tool the key behaviors are 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?

Three sentences, each earning its place: purpose and return type, usage context, and parameter behavior. The description is front-loaded with the primary action and is free of redundant phrasing.

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 two-parameter tool with no output schema, the description is sufficiently complete: it names supported content types, explains the return format, gives usage context relative to search_gospel_library, and documents language handling. No critical gaps remain for selecting and invoking this 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, but the description adds semantic clarity by explaining that the URL targets articles/talks/manual chapters/policy pages and explicitly links lang to language selection with an example. This goes slightly beyond what the schema 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 opens with a specific verb ('Fetch') and a specific resource ('full content of a specific Gospel Library article, talk, manual chapter, or policy page by URL'), clearly distinguishing it from related tools like search_gospel_library (search) and get_scripture (scripture). It also names the return format ('clean markdown text'), making 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?

The description explicitly states when to use it: 'Use this after search_gospel_library to read the full content of an article.' It gives clear context for language selection but does not explicitly mention when not to use it or alternatives like browse_category or get_scripture.

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. It discloses the output format (markdown) and the language default behavior, which is helpful. Yet it does not mention what happens on invalid references, error handling, or any rate limits, leaving some 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.

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

The description is three sentences, each adding distinct value: purpose, return format, and language handling. It is concise, front-loaded, and contains no redundant or filler content.

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 low complexity (2 params, no output schema, no annotations), the description covers the main aspects: what it does, supported sources, return format, and language behavior. It could mention error handling or valid reference format validation, but it is largely complete for a simple fetch tool.

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

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

Schema description coverage is 100%, so both parameters are already well-described. The description adds context about the return format being markdown and the language default, but it does not offer additional parameter-specific semantics beyond what the schema already provides. Baseline 3 is appropriate.

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

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

The description uses a specific verb 'Fetch' with a clear resource 'scripture passage by reference' and explicitly lists the supported canons. This distinguishes it from sibling tools like search_gospel_library, which is for searching rather than direct reference lookup.

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 states the tool fetches a specific passage by reference, which implies the use case of having a known reference. However, it does not explicitly mention when to use this tool versus alternatives like search_gospel_library, nor does it provide exclusions or prerequisites.

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 full burden and does disclose 'No API key required' and the return format (list with titles and URLs). However, it omits potential edge cases (e.g., rate limits, empty results) and gives no detail on result pagination or ranking.

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 four short sentences, each adding distinct value: scope, return format, key requirement, and usage guidance. There is no redundancy or filler, and the main purpose is front-loaded.

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 purpose, usage context, return format, and authentication requirement. Given no output schema, it explains what is returned. However, it does not explicitly differentiate from sibling tools like get_article or browse_category, leaving a minor completeness gap.

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 covers 100% of parameter descriptions, including examples for query and category. The description adds no extra parameter semantics beyond what is already in the schema, so the baseline of 3 applies.

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 a specific verb 'Search' and resource 'Church of Jesus Christ Gospel Library (churchofjesuschrist.org)', and enumerates content types (articles, talks, scriptures, manuals, policies) and return format (list of titles and URLs). This clearly distinguishes it from siblings like get_article and browse_category.

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 advises to 'Use this proactively when answering questions about Church doctrine, policies, scriptures, or general conference talks,' providing clear when-to-use context. It does not mention when to prefer alternatives, but the proactive guidance is a strong usage signal.

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