Skip to main content
Glama

get_chapter_text

Retrieve clean, readable text from a climbing book chapter PDF. Specify book and chapter, then adjust character length or start position to get the exact excerpt needed.

Instructions

Get readable text from a chapter - combines extraction and cleaning into one tool

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
lengthNoNumber of characters to return
book_nameYesThe name of the book directory
start_charsNoStarting character position (0 for beginning of chapter)
chapter_nameYesThe filename of the chapter PDF
force_reextractNoForce re-extraction even if cached version exists
Install Server

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the burden. It adds that the tool performs extraction and cleaning and returns readable text, but it does not mention caching behavior, force re-extraction, or truncated output by default. These are visible only in parameter descriptions, not in the tool description.

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 sentence that leads with the core purpose and follows with the key differentiator. No wasted words or redundancy.

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 enough to identify what the tool returns, and the schema handles parameter semantics. However, it leaves gaps around how this relates to get_chapter_section and extract_chapter_content, and it does not surface that results are limited by length/start_chars. Some of this is recoverable from schema defaults, but not fully.

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 every parameter has a useful description, such as start_chars as the starting character position and force_reextract as a cache override. The tool description adds no additional parameter meaning, so it sits at the high-coverage baseline 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?

States a specific action and resource: getting readable text from a chapter. The phrase 'combines extraction and cleaning into one tool' differentiates it from the sibling extract_chapter_content, and 'from a chapter' distinguishes it from get_chapter_section.

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?

Implies it should be used when cleaned readable text is wanted instead of raw extraction, but it does not explicitly say when to use alternatives like get_chapter_section or extract_chapter_content. No when-not conditions or alternative tool names are provided.

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

Other Tools

Latest Blog Posts

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/MateoGonzalezGomez/ClimbMCP'

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