Skip to main content
Glama

remarkable_read

Read-onlyIdempotent

Extract text and annotations from reMarkable documents, with page selection and OCR for handwritten notes.

Instructions

Read and extract text content from a reMarkable document. Extracts content from a document with pagination to preserve context window.

Content types:

  • "text" (default): Full extracted text (annotations, highlights, OCR)

  • "annotations": Only annotations, highlights, and handwritten notes

Reading modes:

  • Single page: page=N returns the real page N (PDF pages, EPUB sections, notebook pages)

  • Multi-page: pages="all", pages="1-3", pages="2,4,5" — returns multiple pages concatenated

  • grep auto-redirects to the first matching page when no match on current page

When REMARKABLE_OCR_BACKEND=sampling is set and the client supports sampling, OCR will use the client's LLM for handwriting recognition (no API keys needed).

  • document: Document name or path (use remarkable_browse to find documents)

  • content_type: "text" (full), "annotations" (notes only)

  • page: Page number for single-page mode (default: 1)

  • pages: Multi-page spec: "all", "1-3", "2,4,5" (overrides the page param)

  • grep: Regex pattern to filter content (auto-redirects to matching page)

  • include_ocr: Enable handwriting OCR for annotations (default: False)

  • auto_ocr: Auto-retry with OCR on empty notebooks (default: True, set False to skip)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
grepNo
pageNo
pagesNo
auto_ocrNo
documentYes
include_ocrNo
content_typeNotext
compact_outputNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.7.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context: pagination to preserve context, content type selection, multi-page specs, grep auto-redirect, and OCR behavior depending on environment. This goes well beyond what annotations provide.

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?

Well-structured with usecase, instructions, parameters, and examples. Each section is purposeful, front-loaded with the core purpose, and avoids redundancy. Appropriate length for a complex tool.

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?

Covers all major behaviors: pagination, content types, grep, OCR, and multi-page modes. The only missing detail is the compact_output parameter, which is not mentioned. Output schema exists, so return values are documented elsewhere. Overall very complete for a tool with 8 parameters.

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

Parameters4/5

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

Schema description coverage is 0%, so the description's parameter section is essential. It explains document, content_type, page, pages, grep, include_ocr, and auto_ocr with clear semantics and examples. However, it omits the 'compact_output' parameter present in the schema, leaving a small gap in meaning.

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 and resource: 'Read and extract text content from a reMarkable document.' Clearly distinguishes from siblings like remarkable_browse (finding documents) and remarkable_search (searching), making it unambiguous for an agent.

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?

Provides detailed instructions on content types, reading modes, pagination, and grep behavior, plus a note to use remarkable_browse for finding documents. It does not explicitly list when NOT to use this tool versus alternatives like search, but the usecase and examples give enough context for an agent to select appropriately.

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