Skip to main content
Glama

Fetch a chapter

bible_chapter
Read-onlyIdempotent

Return all verses, groupings, and red letter data for a chapter.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bookYes
chapterYes
translationNoKJV

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / translation / default
      Added value: +"KJV"
    • changedInput schema / required
      Previous value: -[
      -  "translation",
      -  "book",
      -  "chapter"
      -]New value: +[
      +  "book",
      +  "chapter"
      +]
  2. First observed

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already indicate that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by specifying that the result includes groupings and red letter data, but it does not cover error cases, translation handling, or output structure. With strong annotations, this is acceptable but not exceptional.

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 efficient sentence that front-loads the action and result. Every phrase adds value, and there is no fluff or redundant restating of the title.

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 read-only fetch tool, the description covers the main return content and is sufficient for basic chapter retrieval. It does not explain valid book/translation values, but sibling tools like bible_books and bible_translations likely fill that gap. The lack of an output schema is partially mitigated by the description.

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 0%, and the description does not explain the book, chapter, or translation parameters or their expected formats. The schema provides basic type and default information, but an agent still lacks guidance on valid book names, translation codes, or other 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 uses a specific verb ('Return') and a clear resource ('a chapter'), and enriches it with scope details: all verses, groupings, and red letter data. This naturally distinguishes it from the sibling bible_verse tool, which would return a single verse, and from search/list siblings.

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 that this tool is for fetching full chapter content, but it does not explicitly state when to prefer it over bible_verse, nor does it mention any exclusions or alternative tools. Usage is inferable from the wording but not directly guided.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources