Skip to main content
Glama
vgnshiyer

apple-books-mcp

by vgnshiyer

Get chapter text

get_chapter_content
Read-only

Return a chapter's plain-text content from an Apple Books EPUB, paginated to fit context limits. Specify book ID and optional chapter ID to fetch a specific or the current chapter.

Instructions

Return the plain-text content of a chapter, paginated by default to protect the context window. Get chapter_id from list_book_chapters or from the (ch=...) suffix on annotation listing rows, or pass "current" (the default) for the chapter the user is reading in Apple Books. Works for non-DRM EPUBs downloaded to this Mac.

Default max_chars=10000 (~2500 words) fits most chapters in one call. Longer chapters return a slice with a footer naming the exact offset to pass next. At most 50000 chars are returned per call.

Every response ends with a footer like one of::

(full chapter returned: 4,872 chars.)
…(returned chars 0–10000 of 24,311 [10000 chars]. Call again with
  offset=10000 to continue; 14,311 chars remaining.)
(returned chars 20000–24311 of 24311 [4311 chars]. End of chapter.)

Args: book_id: The book's numeric ID. chapter_id: Chapter identifier, the 1-based chapter order as a string (e.g. "5"), or "current" (the default): the chapter of the user's reading position. A chapter whose id is literally "current" wins. offset: Character offset to start from. Defaults to 0. max_chars: Max chars to return (1–50000). Default 10000.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
offsetNo
book_idYes
max_charsNo
chapter_idNocurrent

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.9.0
    • addedInput schema / properties / chapter_id / default
      Added value: +"current"
    • changedInput schema / required
      Previous value: -[
      -  "book_id",
      -  "chapter_id"
      -]New value: +[
      +  "book_id"
      +]
  2. First observedv0.8.4

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover readOnlyHint and openWorldHint; the description adds substantial behavior beyond that: default pagination, the 50000-char hard cap, what the footer looks like and how to continue, the 'current' reading-position semantics, and the non-DRM EPUB limitation. These are exactly the traits an agent needs to call it correctly.

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?

Front-loaded with purpose, then pagination behavior, then args. Slightly long due to three footer examples, but each illustrates a distinct return state (full, mid-chapter, end-of-chapter), so the space is largely earning its place.

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

Completeness5/5

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

No output schema exists, yet the description documents the return shape via footer examples and continuation semantics, and contextualizes input sources. Nothing an agent needs to call this correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries the load — and it does: book_id, chapter_id (1-based order, "current" default, literal-'current' edge case), offset (start position), and max_chars (1–50000 range, 10000 default). All four parameters are meaningfully documented.

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 verb+resource: 'Return the plain-text content of a chapter.' It also scopes itself immediately via 'paginated by default' and 'Works for non-DRM EPUBs,' which distinguishes it from the listing/routing siblings like list_book_chapters.

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?

Gives clear routing context: 'Get chapter_id from list_book_chapters or from the (ch=...) suffix on annotation listing rows, or pass "current".' This tells the agent where inputs come from, but stops short of stating when to avoid this tool or an alternative to prefer.

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