Which integrations are available for this server?

Enables use of reMarkable content within Obsidian for second brain workflows and knowledge management.

How do I use reMarkable MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@reMarkable MCP Server search my meeting notes for action items" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

reMarkable MCP Server

by rbonitz

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

reMarkable MCP Server

Unlock the full potential of your reMarkable tablet as a second brain for AI assistants. This MCP server lets Claude, VS Code Copilot, and other AI tools read, search, and traverse your entire reMarkable library — including handwritten notes via OCR.

Why remarkable-mcp?

Your reMarkable tablet is a powerful tool for thinking, note-taking, and research. But that knowledge stays trapped on the device. This MCP server changes that:

Full library access — Browse folders, search documents, read any file
Typed text extraction — Native support for Type Folio and typed annotations
Handwriting OCR — Convert handwritten notes to searchable text
PDF & EPUB support — Extract text from documents, plus your annotations
Robust page rendering — Renders pages locally and automatically falls back to a source PDF when the local stroke renderer can't (USB/SSH use the tablet's own PDF export; cloud uses the original source PDF), so images work across firmware versions and even without system graphics libraries installed
Smart search — Find content across your entire library
Second brain integration — Use with Obsidian, note-taking apps, or any AI workflow

Whether you're researching, writing, or developing ideas, remarkable-mcp lets you leverage everything on your reMarkable through AI.

Related MCP server: remark-mcp

Quick Install

🔌 USB Web Interface (Recommended)

Connect via USB and enable the web interface in your tablet's Storage Settings.

Setup:

Connect your reMarkable via USB
On your tablet: Settings → Storage → Enable "USB web interface"
Install via the button above

Why USB Web?

✅ Fast offline access over USB
✅ No subscription required
✅ Simple — just enable in Storage Settings

Add to .vscode/mcp.json:

{
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp", "--usb"],
      "env": {
        "GOOGLE_VISION_API_KEY": "your-api-key"
      }
    }
  }
}

Troubleshooting:

Make sure your reMarkable is connected via USB and unlocked
Verify USB web interface is enabled in Settings → Storage
The tablet should be accessible at http://10.11.99.1

⚡ SSH Mode (Advanced)

For power users who need direct filesystem access. Faster than USB Web but requires developer mode (factory reset).

Requirements: Developer mode enabled + USB connection to your reMarkable

Add to .vscode/mcp.json:

{
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp", "--ssh"],
      "env": {
        "GOOGLE_VISION_API_KEY": "your-api-key"
      }
    }
  }
}

See SSH Setup Guide for detailed instructions.

☁️ Cloud Mode (Wireless)

Wireless access with no device connection required — your reMarkable syncs to the cloud and the MCP reads from there, so it works from anywhere. Requires a reMarkable Connect subscription.

Cloud mode fetches your whole library in parallel and caches content-addressed blobs on disk, so after the first run startups and document reads are near-instant (a 388-document library lists in ~4s cold, ~0.5s warm). See Cloud Performance & Caching to tune it.

1. Get a One-Time Code

Go to my.remarkable.com/device/desktop/connect and generate a code.

2. Convert to Token

uvx remarkable-mcp --register YOUR_CODE

3. Install

Install Cloud Mode in VS Code

Or configure manually in .vscode/mcp.json:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "remarkable-token",
      "description": "reMarkable API Token",
      "password": true
    },
    {
      "type": "promptString",
      "id": "google-vision-key",
      "description": "Google Vision API Key",
      "password": true
    }
  ],
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp"],
      "env": {
        "REMARKABLE_TOKEN": "${input:remarkable-token}",
        "GOOGLE_VISION_API_KEY": "${input:google-vision-key}"
      }
    }
  }
}

Connection Modes

All three modes share the same read, render, and upload tools. Cloud and SSH additionally support full library management — create folders, move, rename, and delete (all enabled by default) — so capability is near-identical and you can genuinely pick whichever matches how your tablet is connected:

☁️ Cloud — device-free, works from anywhere. Reads your library straight from reMarkable's cloud over Wi‑Fi with a Connect subscription — no cable, no developer mode. Full read/render plus full write (upload, create folder, move, rename, delete → trash). Parallel fetching and an on-disk blob cache make it fast after the first sync. Best for remote/headless setups or when you don't want to plug in.
🔌 USB Web Interface — best when the tablet is plugged in. Enable the web interface in Storage Settings — no subscription, no developer mode. Full read/render plus upload (to your root folder). The tablet's USB web firmware exposes no folder/move/rename/delete endpoints, so for those over a cable use SSH.
⚡ SSH — for power users who want filesystem-level access. Requires developer mode over USB. Full read/render plus full write including folder create/move/rename/delete, straight from the tablet filesystem.

Mode	Setup	Subscription	Offline	Read + render	Raw PDF/EPUB	Upload	Folder ops¹
☁️ Cloud	One-time code	Connect	❌	✅	✅ PDF/EPUB	✅	✅
🔌 USB Web	Enable in Settings	Not required	✅	✅	✅ PDF	✅ (to root)	❌
⚡ SSH	Developer mode	Not required	✅	✅	✅ PDF/EPUB	✅	✅

¹ Folder ops = create folder / move / rename / delete. Upload and folder ops are enabled by default; pass --read-only to expose a read-only server. Deletes move items to the trash and prompt for confirmation when your client supports elicitation, and are refused without it unless REMARKABLE_SKIP_CONFIRM=1 is set.

Automatic cloud fallback

If you select a device transport (--usb or --ssh) but the tablet isn't reachable at startup and a cloud token is configured (REMARKABLE_TOKEN or ~/.rmapi), the server automatically falls back to cloud mode and logs a warning. This means a single configuration works whether or not the tablet is plugged in — plug in for fast local access, unplug to keep working over the cloud. remarkable_status reports the effective transport and a fell_back_to_cloud flag when this happens.

Pass --no-cloud-fallback (or set REMARKABLE_DISABLE_CLOUD_FALLBACK=1) to disable this and fail instead when the device is unreachable.

📖 Detailed Setup Guides:

USB Web Interface Setup — recommended — simple setup, full feature support
SSH Setup Guide — for advanced users who need filesystem access
Cloud setup is documented in the Quick Install section above; tuning in Cloud Performance & Caching

OpenClaw Integration

remarkable-mcp works as an OpenClaw skill. Add to your openclaw.json:

{
  "mcpServers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp", "--usb"]
    }
  }
}

Install from ClawHub:

clawhub install remarkable-mcp

Or copy the SKILL.md from this repository into your ~/.openclaw/skills/remarkable-mcp/ directory.

Tools

Tool	Description
`remarkable_read`	Read and extract text from documents (with pagination and search)
`remarkable_browse`	Navigate folders, search by document name, or filter by tags
`remarkable_search`	Search content across multiple documents (with tag filtering)
`remarkable_recent`	Get recently modified documents
`remarkable_status`	Check connection status and the per-transport capability matrix
`remarkable_image`	Get PNG/SVG images of pages (supports OCR via sampling)

These six tools are read-only and return structured JSON with hints for next actions. Write tools (remarkable_upload, remarkable_mkdir, remarkable_move, remarkable_rename, remarkable_delete, and remarkable_author for native ink/notebooks) are enabled by default — pass --read-only to disable them — see Write Tools. An interactive canvas app (remarkable_canvas) is also registered automatically for clients that support MCP Apps.

📖 Full Tools Documentation

Smart Features

Auto-redirect — Browsing a document path returns its content automatically
Auto-OCR — Notebooks with no typed text automatically enable OCR
Batch search — Search across multiple documents in one call
Vision support — Get page images for visual context (diagrams, mockups, sketches)
Sampling OCR — Use client's AI for OCR on images (no API key needed)
Tag support — Filter and organize documents by tags

Example Usage

# Read a document
remarkable_read("Meeting Notes")

# Search for keywords
remarkable_read("Project Plan", grep="deadline")

# Enable OCR for handwritten notes
remarkable_read("Journal", include_ocr=True)

# Browse your library
remarkable_browse("/Work/Projects")

# Filter by tags
remarkable_browse("/", tags=["important"])
remarkable_browse("/Work", tags=["project", "active"])

# Search across documents
remarkable_search("meeting", grep="action items")

# Search with tag filter
remarkable_search("project", tags=["work"])

# Get recent documents
remarkable_recent(limit=10)

# Get a page image (for visual content like UI mockups or diagrams)
remarkable_image("UI Mockup", page=1)

# Get SVG for editing in design tools
remarkable_image("Wireframe", output_format="svg")

# Get image with OCR text extraction (uses sampling if configured)
remarkable_image("Handwritten Notes", include_ocr=True)

# Transparent background for compositing
remarkable_image("Logo Sketch", background="#00000000")

# Compatibility mode: return resource URI instead of embedded resource
remarkable_image("Diagram", compatibility=True)

Note: PNG rendering automatically falls back to a source PDF when the local stroke renderer can't produce an image (empty pages, newer .rm formats, or a machine without libcairo). USB and SSH modes use the tablet's native PDF export; cloud mode uses the document's original source PDF. This keeps remarkable_image working across firmware versions and platforms. Cloud mode has no native export, so it relies on the local renderer.

Resources

Documents are automatically registered as MCP resources:

URI Scheme	Description
`remarkable:///{path}.txt`	Extracted text content
`remarkableraw:///{path}.pdf`	Original PDF file (SSH only)
`remarkableraw:///{path}.epub`	Original EPUB file (SSH only)
`remarkableimg:///{path}.page-{N}.png`	PNG image of page N (notebooks only)
`remarkablesvg:///{path}.page-{N}.svg`	SVG vector image of page N (notebooks only)

📖 Full Resources Documentation

OCR for Handwriting

For handwritten content, remarkable-mcp offers several OCR backends. Choose based on your setup and requirements:

Backend	Setup	Quality	Offline	Best For
Sampling	No API key	Depends on client model	✅	Users with capable AI clients
Google Vision	API key	Excellent	❌	Best handwriting accuracy
Tesseract	System install	Poor for handwriting	✅	Printed text, offline fallback

Quick Setup

Set REMARKABLE_OCR_BACKEND in your MCP config:

{
  "env": {
    "REMARKABLE_OCR_BACKEND": "sampling"
  }
}

Options: sampling, google, tesseract, auto

Uses your MCP client's AI model for OCR. Works with clients that support MCP sampling (VS Code + Copilot, Claude Desktop, etc.).

Pros:

No additional API keys needed
Quality depends on your client's model (GPT-4, Claude, etc.)
Private — handwriting stays local to your client

Cons:

Only available with sampling-capable clients
Falls back to Google Vision (if API key configured) or Tesseract if sampling unavailable

Provides consistently excellent handwriting recognition.

Setup:

Enable Cloud Vision API
Create an API key
Add to config: "GOOGLE_VISION_API_KEY": "your-key"

Cost: 1,000 free requests/month, then ~$1.50 per 1,000.

📖 Full Google Vision Setup Guide

Open-source OCR designed for printed text. Poor results with handwriting, but useful as an offline fallback.

# Install Tesseract
# macOS
brew install tesseract

# Ubuntu/Debian
sudo apt install tesseract-ocr

# Windows
choco install tesseract

Default Behavior (`auto`)

When REMARKABLE_OCR_BACKEND=auto (default):

Google Vision (if GOOGLE_VISION_API_KEY is set)
Tesseract (fallback)

SSH vs USB Web vs Cloud Comparison

Feature	SSH Mode	USB Web	Cloud API
Speed	⚡ 10-100x faster	⚡ Fast	⚡ Fast (parallel + cached)
Offline	✅ Yes	✅ Yes	❌ No
Subscription	✅ Not required	✅ Not required	❌ Connect required
Raw files	✅ PDFs, EPUBs	✅ PDFs	✅ PDFs, EPUBs
Upload	✅ (default)	✅ (default)	✅ (default)
mkdir/move/rename/delete	✅ (default)	❌	✅ (default)
Setup	Developer mode	Enable in Settings	One-time code

📖 SSH Setup Guide

Write Tools (Cloud, SSH & USB Web)

Write tools let you upload, organize, and manage documents on your reMarkable. Enabled by default. Cloud and SSH modes support the full set; USB web supports upload only (its firmware exposes no folder operations). Pass --read-only to expose a read-only server.

Feature	Cloud Mode	SSH Mode	USB Web Mode
Upload	✅	✅	✅ (to root)
Mkdir	✅	✅	❌
Move	✅	✅	❌
Rename	✅	✅	❌
Delete	✅ (→ trash)	✅	❌

Disabling Write Tools (read-only mode)

Write tools are on by default in every mode. To run a read-only server, add the --read-only flag:

{
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp", "--read-only"]
    }
  }
}

It combines with any transport flag (--ssh, --usb):

{
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp", "--ssh", "--read-only"]
    }
  }
}

Or set the environment variable:

{
  "env": {
    "REMARKABLE_READ_ONLY": "1"
  }
}

The legacy --write flag and REMARKABLE_ENABLE_WRITE variable are still accepted for backward compatibility but are now no-ops (write is the default). --write and --read-only are mutually exclusive.

Available Write Tools

Tool	Description
`remarkable_upload(file_path, parent_folder, document_name)`	Upload a PDF or EPUB file (all modes; USB web ignores folder/name and uploads to root)
`remarkable_mkdir(folder_name, parent)`	Create a new folder (cloud and SSH)
`remarkable_move(document, dest_folder)`	Move a document or folder (cloud and SSH)
`remarkable_rename(document, new_name)`	Rename a document or folder (cloud and SSH)
`remarkable_delete(document)`	Delete a document or folder — destructive (cloud and SSH)
`remarkable_author(method, ...)`	Author native ink and notebooks — `draw` (append strokes), `add_page` (append a blank notebook page), `create_document` (new notebook) — SSH only

Safety

Upload registers in all modes — cloud, SSH, and USB web.
mkdir, move, rename, delete register in cloud and SSH modes only — they are not exposed on USB web (the tablet's USB web firmware has no folder/move/rename/delete endpoints), keeping the tool list scoped to what the active transport actually supports.
Delete prompts for confirmation when possible — if the client supports MCP elicitation, remarkable_delete asks the user to confirm before deleting. If the client can't show a prompt, the delete is refused (not performed) unless REMARKABLE_SKIP_CONFIRM=1 is set — so write-on-by-default can't silently delete from clients that lack elicitation. In cloud mode delete moves the item to the trash (recoverable from your device); set REMARKABLE_SKIP_CONFIRM=1 to allow deletes without a prompt in automated setups. All write tools carry ToolAnnotations(readOnlyHint=False) (and destructiveHint=True for delete) so an agent harness can gate writes at the MCP layer.
After each write operation in SSH mode, the tablet UI restarts automatically to reflect changes.

Examples

# Upload a PDF
remarkable_upload("paper.pdf", parent_folder="/Research")

# Create a folder
remarkable_mkdir("2024 Archive", parent="/Archive")

# Move a document
remarkable_move("Meeting Notes", "/Archive/2024 Archive")

# Rename a document
remarkable_rename("Untitled", "Q4 Planning Notes")

# Delete (destructive — confirms via elicitation when supported)
remarkable_delete("Old Draft")

# Author native ink and notebooks (SSH only)
# Append pen/highlighter strokes to a page (coordinates normalized [0,1] from
# the page's top-left). The interactive canvas Save button calls this too.
remarkable_author(
    method="draw", document="Ideas", page=1,
    strokes=[{"points": [[0.1, 0.2], [0.8, 0.2]], "tool": "highlighter", "color": "yellow"}],
)

# Append a blank, drawable page to the end of a notebook
remarkable_author(method="add_page", document="Ideas")

# Create a new (blank) notebook — the common case
remarkable_author(method="create_document", name="Sketches")

# Only seed typed text when the user explicitly requested it.
remarkable_author(method="create_document", name="Meeting notes", text="Agenda\nFollow-ups")

Interactive Canvas App (MCP Apps)

An interactive page viewer built on the MCP Apps extension (SEP-1865). Clients that support MCP Apps (such as ChatGPT, Claude, VS Code, and the MCP Inspector) render a canvas in a side panel where you can view a document page and navigate through it.

There is no flag to enable it — the remarkable_canvas tool and its ui://remarkable/canvas resource are always registered, and the capability is negotiated automatically at the MCP initialize handshake. App-capable clients open the interactive canvas; every other client simply receives the rendered page as an image, so the tool is safe and useful everywhere.

This registers one tool:

Tool	Description
`remarkable_canvas(document, page)`	Open a page in the interactive canvas viewer

How it behaves:

App-capable clients open the canvas (declared at ui://remarkable/canvas, MIME text/html;profile=mcp-app) and can page through the document via the MCP Apps postMessage bridge — the server delivers each rendered page in the tool result's structuredContent.
Other clients still get the rendered page back as an embedded PNG image, so the tool is useful everywhere; it just won't open the interactive panel. The _meta.ui / ui:// metadata is inert to clients that don't advertise the MCP Apps UI extension.

Drawing and authoring from the canvas

When write mode is on (the default) and the active transport is SSH, the canvas becomes a write surface:

Draw — pick a pen or highlighter and colour, draw over the page, and Save writes the strokes back to the device as native .rm ink. Strokes are buffered locally per page (with Undo and Cancel) and only touch the device on Save.
＋ Page (native notebooks only) — queues a new blank page locally that you can navigate to and draw on immediately. Save materializes the queued page(s) on the device first, then writes any cached strokes.
One source of truth: the canvas calls the same remarkable_author tool a model would call (method="draw" on Save, method="add_page" for ＋Page), so the human path and the model path produce byte-identical results.

The Save / Draw / ＋Page controls are hidden when the page isn't writable (read-only mode, or a non-SSH transport), and the canvas falls back to a plain image viewer. The iframe bridge follows the MCP Apps spec but is best validated against your specific client.

Advanced Configuration

Root Path Filtering

Limit the MCP server to a specific folder on your reMarkable. All operations will be scoped to this folder:

{
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp", "--ssh"],
      "env": {
        "REMARKABLE_ROOT_PATH": "/Work",
        "GOOGLE_VISION_API_KEY": "your-api-key"
      }
    }
  }
}

With this configuration:

remarkable_browse("/") shows contents of /Work
remarkable_browse("/Projects") shows /Work/Projects
Documents outside /Work are not accessible

Useful for:

Focusing on work documents during office hours
Separating personal and professional notes
Limiting scope for specific AI workflows

Custom Background Color

Set the default background color for image rendering:

{
  "servers": {
    "remarkable": {
      "command": "uvx",
      "args": ["remarkable-mcp", "--ssh"],
      "env": {
        "REMARKABLE_BACKGROUND_COLOR": "#FFFFFF"
      }
    }
  }
}

Supported formats:

#RRGGBB — RGB hex (e.g., #FFFFFF for white)
#RRGGBBAA — RGBA hex (e.g., #00000000 for transparent)

Default is #FBFBFB (reMarkable paper color). This affects both the remarkable_image tool and image resources.

Retry Configuration

Cloud API requests automatically retry on transient failures (HTTP 429, 500, 502, 503, 504) and network errors with exponential backoff and jitter. You can tune this via environment variables:

Variable	Default	Description
`REMARKABLE_RETRY_ATTEMPTS`	`3`	Maximum number of request attempts (minimum 1)
`REMARKABLE_RETRY_DELAY`	`2.0`	Base delay in seconds for exponential backoff

The retry logic honours the Retry-After header from rate-limited responses — both the numeric (seconds) form and the HTTP-date form (which Cloudflare, fronting the reMarkable cloud, often sends) — capped at 20 seconds. Auth failures (401) are not retried — they trigger automatic token renewal instead.

Cloud Performance & Caching

Cloud mode is built to make a device-free workflow fast:

Parallel traversal — document metadata is fetched concurrently instead of one document at a time, turning a multi-minute first load into a few seconds.
Connection pooling — HTTP connections are reused (keep-alive), avoiding a fresh TLS handshake per request.
Content-addressed blob cache — reMarkable's cloud is an immutable, hash-addressed store (like Git), so a blob's bytes can never change for a given hash. Downloaded blobs are cached on disk and reused on later runs; changed documents get new hashes and are re-fetched automatically. This makes warm startups and repeat document reads near-instant, and it is invalidation-safe by construction.

You normally don't need to configure any of this, but these environment variables let you tune it:

Variable	Default	Description
`REMARKABLE_SYNC_WORKERS`	`16`	Parallel workers for cloud fetches (clamped to `64`).
`REMARKABLE_DISABLE_CACHE`	unset	Set to `1` to disable the on-disk blob cache entirely.
`REMARKABLE_CACHE_DIR`	`~/.remarkable/cache/blobs`	Where cached blobs are stored.
`REMARKABLE_CACHE_MAX_BLOB`	`4194304` (4 MiB)	Blobs larger than this are streamed through but not cached.

The cache is purely a local accelerator: deleting REMARKABLE_CACHE_DIR only forces the next read to re-download. The mutable cloud root hash is always fetched fresh, so you never see a stale library.

Use Cases

Research & Writing

Use remarkable-mcp while working in an Obsidian vault or similar to transfer knowledge from your handwritten notes into structured documents. AI can read your research notes and help develop your ideas.

Daily Review

Ask your AI assistant to summarize your recent notes, find action items, or identify patterns across your journal entries.

Document Search

Find that half-remembered note by searching across your entire library — including handwritten content.

Knowledge Management

Treat your reMarkable as a second brain that AI can access. Combined with tools like Obsidian, you can build a powerful personal knowledge system.

Documentation

Guide	Description
SSH Setup	Enable developer mode and configure SSH
Google Vision Setup	Set up handwriting OCR
Tools Reference	Detailed tool documentation
Resources Reference	MCP resources documentation
Capability Negotiation	MCP protocol capabilities
Development	Contributing and development setup
Future Plans	Roadmap and planned features

Development

git clone https://github.com/SamMorrowDrums/remarkable-mcp.git
cd remarkable-mcp
uv sync --all-extras
uv run pytest test_server.py -v

📖 Development Guide

Multi-transport smoke test

When something looks broken, run the deterministic, no-AI smoke test first. It drives the real server over MCP and exercises every available tool in every reachable transport (cloud → usb-web → ssh):

uv run python smoke/run_smoke.py            # all available modes
uv run python smoke/run_smoke.py --read-only # connectivity + reads only

📖 smoke/README.md — what PASS / N/A / SKIP / FAIL mean and per-mode expectations.

License

MIT

Built with rmscene, PyMuPDF, and inspiration from ddvk/rmapi.

Available Tools

12 tools

remarkable_browseA

Read-onlyIdempotent

Browse your reMarkable library or search for documents. Three modes:

Browse mode (default): List contents of a folder
- Use path="/" for root folder
- Use path="/FolderName" to navigate into folders
Search mode: Find documents by name
- Set query="search term" to search across all documents
Filter by tags: Find documents with specific tags
- Set tags=["tag1", "tag2"] to filter by tags
- Works in both browse and search modes

Results include document names, types, modification dates, and tags.

Note: If REMARKABLE_ROOT_PATH is configured, only documents within that folder are accessible. Paths are relative to the root path.

path: Folder path to browse (default: "/" for root)
query: Search term to find documents by name (optional, triggers search mode)
tags: List of tags to filter documents (optional, case-insensitive)

ParametersJSON Schema

Name	Required	Default
`path`	No	/
`query`	No
`tags`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

The description adds significant behavioral context beyond annotations: the three modes, results included (names, types, dates, tags), and the note about REMARKABLE_ROOT_PATH restricting access. No contradictions with annotations (readOnlyHint, idempotentHint, destructiveHint).

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 well-structured with sections (usecase, instructions, parameters, examples), each sentence adds value, and it is front-loaded with the core use case. No unnecessary words.

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?

Given 3 optional parameters, an output schema, and annotations covering read-only behavior, the description is complete. It covers all modes, path restrictions, and examples. No missing information that would hinder tool selection or invocation.

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?

With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose (path for folder, query for search, tags for filtering), their defaults, and how they interact. Examples illustrate usage clearly.

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 explicitly states the tool's purpose: 'Browse your reMarkable library or search for documents.' It details three modes (browse, search, filter by tags) and provides clear examples, effectively distinguishing it from sibling tools like remarkable_search.

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?

The description provides explicit instructions for when to use each mode (browse, search, filter), includes a note about the REMARKABLE_ROOT_PATH configuration, and gives examples. However, it does not explicitly differentiate from the sibling tool remarkable_search, which might lead to confusion about which search tool to use.

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

remarkable_canvasA

Read-only

Open a reMarkable page in an interactive canvas viewer. Renders a notebook or document page and, in clients that support MCP Apps interactive UI, opens a canvas viewer that lets the user page through the document. This is the entry point for the interactive viewer.

The canvas is currently a read-only viewer (render + page navigation). For plain image extraction without the interactive surface, use remarkable_image instead.

Clients that do not support MCP Apps still get the rendered page back as an embedded PNG image, so this tool is useful everywhere; it just won't open the interactive panel.

document: Document name or path (use remarkable_browse to find documents)
page: Page number to open (default: 1, 1-indexed)

ParametersJSON Schema

Name	Required	Description	Default
`document`	Yes
`page`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true and openWorldHint=false. The description adds that the canvas is read-only with page navigation and explains different behavior for clients with/without MCP Apps support, plus return of embedded PNG for non-interactive clients. No contradictions.

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 well-structured with clear <usecase>, <instructions>, <parameters>, and <examples> sections. Every sentence adds value without unnecessary verbosity.

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?

The description covers the tool's purpose, usage, parameter details, behavioral differences, and includes examples. It is complete for a read-only tool with interactive capabilities, though error handling or conditional behavior when document is not found is not mentioned.

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%, but the description adds meaning for both parameters: document can be name or path (with hint to use remarkable_browse), page is 1-indexed with default 1, and examples are provided. This compensates well for the schema's lack of descriptions.

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 explicitly states 'Open a reMarkable page in an interactive canvas viewer' and distinguishes from sibling remarkable_image for plain image extraction, giving a specific verb and resource with clear differentiation.

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?

It provides clear context for when to use this tool (interactive viewing) vs alternatives (use remarkable_image for plain extraction) and advises using remarkable_browse to find documents. It does not explicitly list exclusions but implies the alternative use case.

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

remarkable_deleteA

Destructive

Delete a document or folder on the reMarkable tablet. DESTRUCTIVE operation. In cloud mode the item is moved to the trash (recoverable from the device's Trash). In SSH mode it is marked deleted in its metadata and disappears from the tablet UI after restart.

Works in cloud and SSH modes (default; --read-only disables). Not available over the USB web interface.

If the client supports elicitation, this tool asks the user to confirm before deleting. If the client cannot show a confirmation prompt, the delete is refused unless REMARKABLE_SKIP_CONFIRM=1 is set (for headless automation).

document: Name or path of the document/folder to delete

ParametersJSON Schema

Name	Required	Description	Default
`document`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Adds significant behavioral details beyond annotations: explains cloud vs SSH behavior (trash vs metadata deletion), confirmation process, and env variable override for automation.

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. Every sentence adds value, front-loaded with key info.

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?

Covers all necessary aspects: use case, behavior modes, confirmation logic, parameter description, and examples. Output schema exists to handle return value details.

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?

Description explains the single parameter 'document' as 'Name or path', adding meaning beyond the schema's bare 'string' type. Schema coverage is 0% so description compensates well.

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 clearly states the action ('Delete'), the resource ('document or folder on the reMarkable tablet'), and distinguishes it from siblings like remarkable_move or remarkable_rename.

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?

Specifies destructive nature, available modes (cloud/SSH), and confirmation requirements. Does not explicitly compare to alternative tools but provides clear conditions for use.

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

remarkable_imageA

Read-onlyIdempotent

Get an image of a specific page from a reMarkable document. Renders a notebook or document page as an image (PNG or SVG). This is useful for:

Viewing hand-drawn diagrams, sketches, or UI mockups
Getting visual context that text extraction might miss
Implementing designs based on hand-drawn wireframes
SVG format for scalable vector graphics that can be edited

Merged PDF + Annotation Rendering

Set render_merged=True to composite the PDF page with the annotation layer into a single image. This is ideal for annotated PDFs where the annotation-only render is hard to interpret without the printed page context. Only works with PNG format and documents that have a PDF underlay.

Response Formats

By default, images are returned as embedded resources (EmbeddedResource) which include the full image data inline:

PNG: Returned as BlobResourceContents with base64-encoded data
SVG: Returned as TextResourceContents with SVG markup

If your client doesn't support embedded resources in tool responses, set compatibility=True to receive a JSON response with just the resource URI. The client can then fetch the resource separately.

Optionally, enable include_ocr=True to extract text from the image using OCR. When REMARKABLE_OCR_BACKEND=sampling is set and the client supports sampling, the client's own LLM will be used for OCR (no API keys needed).

Note: This works best with notebooks and handwritten content. For PDFs/EPUBs, the annotations layer is rendered (not the underlying PDF content) unless render_merged=True is set.

document: Document name or path (use remarkable_browse to find documents)
page: Page number (default: 1, 1-indexed)
background: Background color as hex code. Supports RGB (#RRGGBB) or RGBA (#RRGGBBAA). Default is "#FBFBFB" (reMarkable paper color), or set REMARKABLE_BACKGROUND_COLOR env var to override. Use "#00000000" for transparent.
output_format: Output format - "png" (default) or "svg" for vector graphics
compatibility: If True, return resource URI in JSON instead of embedded resource. Use this if your client doesn't support embedded resources in tool responses.
include_ocr: Enable OCR text extraction from the image (default: False). When REMARKABLE_OCR_BACKEND=sampling, uses the client's LLM via MCP sampling.
render_merged: Composite PDF page + annotation layer into one image (default: False). Only works with PNG format and documents that have a PDF underlay.

ParametersJSON Schema

Name	Required	Default
`document`	Yes
`page`	No
`background`	No
`output_format`	No	png
`compatibility`	No
`include_ocr`	No
`render_merged`	No

TDQS

A4.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint=true and idempotentHint=true. The description adds significant behavioral context: rendering as PNG/SVG, embedded resource vs compatibility mode, OCR behavior, render_merged behavior, and note about notebook/handwritten content. No contradictions with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

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

The description is well-structured with sections (usecase, instructions, parameters, examples), but it is somewhat verbose. Some information is repeated (e.g., render_merged is mentioned in both instructions and parameters). Could be more concise.

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?

Given the tool has 7 parameters and no output schema, the description covers most aspects: return formats, use cases, parameter details, and examples. It explains how to handle embedded resources and OCR. It is fairly complete, though it could mention pagination or rate limits.

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?

Although the JSON schema has 0% description coverage, the description includes a <parameters> block with detailed explanations for each parameter (e.g., background color format, render_merged conditions). This adds meaning beyond the schema's property names and types.

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 clearly states the tool's purpose: 'Get an image of a specific page from a reMarkable document.' It specifies the resource (page from reMarkable document) and action (get image), and distinguishes from siblings like remarkable_browse (browsing) and remarkable_read (reading text).

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?

The description provides clear use cases (viewing diagrams, sketches, UI mockups) and instructions for when to use features like render_merged and OCR. It references remarkable_browse to find documents, offering some alternative guidance, but it doesn't explicitly state when not to use this tool or list all alternatives.

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

remarkable_mkdirA

Create a new folder on the reMarkable tablet. Creates a folder in the tablet's document hierarchy. In SSH mode the folder appears after xochitl restarts; in cloud mode it syncs to all your devices.

Works in cloud and SSH modes (default; --read-only disables). Not available over the USB web interface (the firmware exposes no folder-create endpoint).

folder_name: Name of the new folder
parent: Parent folder path (default: root "/")

ParametersJSON Schema

Name	Required	Description	Default
`folder_name`	Yes
`parent`	No		/

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Despite readOnlyHint=false annotation, description adds context about sync behavior, mode availability, and restart requirement in SSH mode. No contradiction.

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?

Structured with clear tags (usecase, instructions, parameters, examples). Each sentence is valuable, no redundancy. Front-loaded with purpose.

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?

Covers all essential aspects: purpose, modes, parameters, examples. Output schema exists, so return value explanation is unnecessary. Complete for a simple creation tool.

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 has 0% description coverage, but the <parameters> section explains folder_name and parent with defaults and examples, adding significant meaning beyond schema titles.

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?

Clearly states 'Create a new folder on the reMarkable tablet.' with a usecase tag. Differentiates from siblings like remarkable_delete and remarkable_rename by focusing on creation.

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?

Specifies modes (cloud/SSH, not USB web interface) and mentions that in SSH mode the folder appears after xochitl restarts. Provides examples but does not explicitly compare to sibling tools.

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

remarkable_moveA

Move a document or folder to a different location. Moves a document or folder by updating its parent reference in the metadata. Find the document name with remarkable_browse() first.

Works in cloud and SSH modes (default; --read-only disables). Not available over the USB web interface.

document: Name or path of the document/folder to move
dest_folder: Destination folder path (use "/" for root)

ParametersJSON Schema

Name	Required	Description	Default
`document`	Yes
`dest_folder`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

The description says it 'updates its parent reference', which implies a write operation, consistent with readOnlyHint=false. It also adds mode-level constraints not in annotations. However, it doesn't detail side effects like moving a folder with children, but annotations already cover the write nature.

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?

The description is well-structured with clear sections and front-loaded use case. The XML-like tags add minor noise but do not harm clarity. It is concise without being terse.

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?

Given an output schema exists, the description covers all necessary context: purpose, prerequisites (browse first), parameter details, mode restrictions, and examples. No gaps remain for this mutation tool.

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?

With 0% schema description coverage, the description fully explains both parameters: document as 'Name or path' and dest_folder as 'destination folder path (use "/" for root)'. Examples show concrete usage.

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 clearly states 'Move a document or folder to a different location.' This is a specific verb+resource combination, and it distinguishes from sibling tools like remarkable_rename or remarkable_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The instructions explicitly tell the agent to use remarkable_browse() first to find the document name. It also specifies that the tool works in cloud and SSH modes but not over USB, and that --read-only disables it.

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

remarkable_readA

Read-onlyIdempotent

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 (PDF/EPUB content + annotations)
"raw": Original PDF/EPUB text only (no annotations). Works in every transport, as long as the source file is present (very large PDFs/EPUBs may not be synced to the cloud).
"annotations": Only annotations, highlights, and handwritten notes

Use pagination to read large documents without overwhelming context:

Start with page=1 (default)
Check "more" field - if true, there's more content
Use "next_page" value to get the next page

Use grep to search for specific content on the 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), "raw" (PDF/EPUB only), "annotations" (notes only)
page: Page number (default: 1). For notebooks, this is the notebook page.
grep: Optional regex pattern to filter content (searches current page)
include_ocr: Enable handwriting OCR for annotations (default: False)

ParametersJSON Schema

Name	Required	Default
`document`	Yes
`content_type`	No	text
`page`	No
`grep`	No
`include_ocr`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing safety. The description goes beyond by detailing OCR behavior (REMARKABLE_OCR_BACKEND=sampling) and pagination mechanics, adding valuable behavioral context without contradiction.

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 use case, instructions, parameters, and examples sections. Information is front-loaded and each sentence adds value; no redundancy.

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?

Covers all relevant aspects: document reading, content types, pagination, searching with grep, OCR, and references sibling tool for document discovery. Complete given the presence of an output schema (not shown but mentioned).

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?

Despite 0% schema description coverage, the description's <parameters> section thoroughly explains each parameter (document, content_type, page, grep, include_ocr) and provides concrete examples, making the usage clear.

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 clearly states 'Read and extract text content from a reMarkable document.' It uses a specific verb and resource, and the inclusion of content types (text, raw, annotations) distinguishes it from sibling tools like remarkable_browse and remarkable_search.

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 pagination, grep usage, and content types. While it doesn't explicitly state when not to use the tool, it gives strong contextual guidance, such as using remarkable_browse to find documents and explaining when to use different content types.

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

remarkable_recentA

Read-onlyIdempotent

Get your most recently modified documents. Returns documents sorted by modification date (newest first). Optionally includes a text preview of each document's content.

Use this to quickly find what you were working on recently.

Note: If REMARKABLE_ROOT_PATH is configured, only documents within that folder are included.

limit: Maximum documents to return (default: 10, max: 50 without preview, 10 with preview)
include_preview: Include first ~200 chars of text content (default: False)

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`include_preview`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is clear. The description adds valuable context: sorting order, preview behavior, and the ROOT_PATH filtering. No contradictions.

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?

The description is well-structured with usecase, instructions, parameters, and examples tags. It is front-loaded with the main purpose. While the XML-like tags add some verbosity, every section provides distinct value. Could be slightly more concise but not excessive.

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?

Given the tool has 2 simple parameters, complete annotations, and an output schema, the description covers all necessary aspects: use case, parameter details with limits, example invocations, and an environmental note. Nothing essential is missing for a list tool.

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 fully compensates by detailing 'limit' with default, max values (50 without preview, 10 with preview) and 'include_preview' with content length (~200 chars). Examples further illustrate usage.

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 clearly states 'Get your most recently modified documents.' with explicit verb+resource. It further specifies sorting by modification date (newest first). This distinguishes it from sibling tools like remarkable_search (query-based) and remarkable_browse (file listing).

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?

The description provides explicit guidance: 'Use this to quickly find what you were working on recently.' It also mentions the REMARKABLE_ROOT_PATH restriction. However, it does not explicitly list when to avoid this tool in favor of alternatives, though the sibling tools context implies distinctions.

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

remarkable_renameA

Rename a document or folder on the reMarkable tablet. Changes the display name of a document or folder by updating its metadata. Find the document name with remarkable_browse() first.

Works in cloud and SSH modes (default; --read-only disables). Not available over the USB web interface.

document: Current name or path of the document/folder
new_name: New display name

ParametersJSON Schema

Name	Required	Description	Default
`document`	Yes
`new_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

The annotations already indicate readOnlyHint=false (write operation). The description adds that renaming updates metadata, works in cloud/SSH modes, and is disabled with --read-only. No side effects or permissions are mentioned, but the annotations cover the basic behavioral trait.

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?

The description is well-structured with <usecase>, <instructions>, <parameters>, and <examples> tags. It is slightly verbose but each section adds value. The examples are concise and helpful. Minor redundancy (e.g., 'Change the display name' in both usecase and instructions) could be trimmed.

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?

Given the tool's simplicity (2 string params), the description covers core aspects: purpose, prerequisite, mode restrictions. An output schema exists, so return value details are not needed. Could mention error scenarios or case sensitivity, but overall adequate for this tool.

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?

The schema has 0% description coverage, so the description's <parameters> section fully explains both parameters: 'document' as current name/path and 'new_name' as new display name. Examples further clarify usage. This adds essential meaning beyond the bare schema.

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 clearly states the tool renames documents/folders on the reMarkable tablet using <usecase> and mentions updating metadata. It differentiates from siblings like remarkable_browse by suggesting to find the document name first with that tool.

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?

The <instructions> section advises to find the document name with remarkable_browse() first, and specifies compatibility with cloud and SSH modes but not USB web interface. It lacks explicit when-not-to-use or comparisons to alternative rename-related tools like remarkable_move, but provides solid usage context.

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

remarkable_searchA

Read-onlyIdempotent

Search across multiple documents and return matching content. Searches document names for the query, then optionally searches content with grep. Can filter by tags to narrow results. Returns summaries from multiple documents in a single call.

This is efficient for finding information across your library without making many individual tool calls.

Limits:

Max 5 documents per search (to keep response size manageable)
Returns first page (~8000 chars) of each matching document
Use grep to filter to relevant sections

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`grep`	No
`limit`	No
`include_ocr`	No
`tags`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Description adds behavioral context beyond annotations: searches document names, optionally content with grep, returns summaries, max 5 docs, first page ~8000 chars. Annotations (readOnlyHint, idempotentHint) are consistent. No contradictions.

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?

Description is structured with XML tags (usecase, instructions, parameters, examples) that improve readability. Content is front-loaded with purpose. Each section adds value; examples are helpful. Could be slightly shorter but not redundant.

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?

Given 5 parameters, output schema exists, and sibling tools, the description covers purpose, parameters, limits, examples, and usage context. It explains output returns summaries from multiple documents. Adequate 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.

Parameters4/5

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

With 0% schema description coverage, the <parameters> section provides essential meaning: describes each parameter's purpose and default behavior (e.g., 'optional pattern to search within document content' for grep, 'Enable OCR for handwritten content' for include_ocr). Adds value beyond schema titles.

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 clearly states it searches across multiple documents and returns matching content, with specific verb 'Search' and resource 'Documents'. Examples further clarify usage. Distinguishes from siblings like remarkable_read (single document) and remarkable_browse (folder listing).

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?

The description includes explicit usage guidelines: efficient for cross-document search, limits (max 5 docs, first page ~8000 chars), and filtering options. It doesn't explicitly state when not to use, but the context is clear from instructions and sibling tools.

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

remarkable_statusA

Read-onlyIdempotent

Check connection status, active transport, and write capabilities. Returns authentication status, the active transport (cloud, ssh, or usb-web), the document count, and a capability matrix describing what each transport can do. Use this to verify your connection, choose a transport, or troubleshoot.

Capability notes:

Cloud (default): full read/render/upload/mkdir/move/rename/delete — no device needed, works from anywhere your token is valid.
SSH: full capabilities over a local/USB connection to the tablet.
USB web: read, render, and upload (to root) only — the tablet's USB web interface firmware exposes no folder/move/rename/delete endpoints. For full write parity over a USB cable, use SSH mode pointed at the USB IP. Write tools (upload/mkdir/move/rename/delete) are enabled by default; run with --read-only (or REMARKABLE_READ_ONLY=1) to expose a read-only server.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior5/5

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe read behavior. The description adds substantial context: it details capabilities per transport (cloud, SSH, USB web), write tool enablement, and read-only mode. No contradiction with annotations.

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 well-structured with sections (usecase, instructions, capability notes, examples). It is front-loaded with the core purpose and uses markup for clarity. Every sentence adds value without redundancy.

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?

Given no parameters and an existing output schema, the description explains the return value (authentication status, active transport, document count, capability matrix). It covers all necessary context for a zero-parameter status tool.

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?

The tool has zero parameters, so schema coverage is 100%. The description does not need to add parameter details. Baseline 4 applies as there are no parameters to describe.

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 clearly states it checks connection status, active transport, and write capabilities. It distinguishes from sibling tools (e.g., remarkable_browse, remarkable_read) by focusing on status and connectivity rather than file operations.

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?

The description provides explicit usage guidance: 'Use this to verify your connection, choose a transport, or troubleshoot.' It explains different transports and their capabilities, helping the agent decide when to use this tool. However, it does not explicitly mention when not to use it or compare to alternatives beyond transports.

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

remarkable_uploadA

Upload a PDF or EPUB file to the reMarkable tablet. Uploads a local file to the tablet. Only PDF and EPUB formats are supported. Works in all three transports:

Cloud: uploaded via the sync protocol; supports parent_folder + document_name
SSH: transferred over SSH, metadata created; supports parent_folder + document_name
USB web: uploaded via POST /upload; lands at the root (the firmware's upload endpoint has no folder or rename field)

Requires write mode (the default; disabled with --read-only).

file_path: Absolute path to the local PDF or EPUB file
parent_folder: Destination folder path on tablet (default: root "/"). Honored in cloud and SSH modes; ignored by the USB web interface.
document_name: Display name on tablet (default: filename without extension). Honored in cloud and SSH modes; ignored by the USB web interface.

ParametersJSON Schema

Name	Required	Default
`file_path`	Yes
`parent_folder`	No	/
`document_name`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

Beyond the annotation (readOnlyHint=false), the description details transport-specific behavior (cloud, SSH, USB web) and parameter handling, adding significant transparency about limitations and prerequisites (write mode). No contradiction with annotations.

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 structurally organized with clear sections (usecase, instructions, parameters, examples). Every sentence adds value, and the most critical info is front-loaded.

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?

Given the parameter count and complexity, the description covers use case, supported formats, transport differences, and parameter semantics. An output schema exists, so return values need not be detailed. Slightly missing error handling or success indication, but overall complete.

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?

The input schema has 0% description coverage, so the tool description fully compensates by explaining each parameter's meaning, defaults, and transport-dependent behavior. Examples further clarify usage.

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

Purpose4/5

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

The description clearly states the tool uploads PDF or EPUB files to the reMarkable tablet, specifying the resource and action. While it distinguishes from sibling tools implicitly, it does not explicitly differentiate usage scenarios.

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 provides usage context such as supported formats and transport modes, but lacks explicit guidance on when to use this tool versus alternatives (e.g., sibling tools). It does not state when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv0.1.0Jun 21, 2026
- First observedremarkable_browse
- First observedremarkable_canvas
- First observedremarkable_delete
- First observedremarkable_image
- First observedremarkable_mkdir
- First observedremarkable_move
- First observedremarkable_read
- First observedremarkable_recent
- First observedremarkable_rename
- First observedremarkable_search
- First observedremarkable_status
- First observedremarkable_upload

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Scored 2026-06-21 16:25 across 12 tools

Disambiguation4/5

Tools are mostly distinct, but remarkable_browse and remarkable_search overlap in searching by name and tags. remarkable_canvas and remarkable_image both render pages, though they serve different interactive vs static purposes. Overall boundaries are clear.

Naming Consistency4/5

All tools follow the 'remarkable_<word>' pattern in snake_case, but the words mix verbs (browse, delete, move, read, rename, search, upload) and nouns (image, canvas, status, recent, mkdir). The pattern is predictable but not strictly verb_noun.

Tool Count5/5

12 tools cover the core operations for a reMarkable tablet: browsing, reading, viewing, searching, organizing (create folder, move, rename, delete), uploading, and status. The count is well-scoped without redundancy.

Completeness4/5

Core CRUD-like operations are present, but missing download, explicit tag management, and update existing document. Browsing and search cover metadata and tags. Minor gaps that agents can work around.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

second-brain-bridgeOAuth
io.github.IsaiahDupree
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Note Taking Knowledge & Memory Search
1
LeafOAuth
app.readwithleaf
AI assistant integration for Leaf — track books, log reading sessions, and manage your library.
Knowledge & Memory Note Taking
2
Hint-Services-obsidian-github-mcp
ai.smithery
Connect AI assistants to your GitHub-hosted Obsidian vault to seamlessly access, search, and analy…
Note Taking Version Control File Systems
29
MemOAuth
io.github.mem-labs
Securely search, create, and organize your Mem notes and collections from AI assistants.
Knowledge & Memory Search
1

Related MCP Servers

Readbook MCP Server
Education & Learning Tools Note Taking Search
mkafw
F
license
Not graded
quality
D
maintenance
Enables AI assistants to help users manage their reading experience by searching books, tracking reading progress, managing bookmarks, and generating personalized recommendations and summaries.
Updated 9 months ago (2025-12-08 02:21 UTC)
-
remark-mcp
File Systems Note Taking
robbogd76
A
license
Not graded
quality
D
maintenance
Enables AI assistants to browse and read documents from a reMarkable tablet connected via USB, rendering PDF pages as images for the AI to see.
Updated 4 months ago (2026-05-13 01:43 UTC)
Apache 2.0
GoodNotes MCP Server
Note Taking Search
withsivram
A
license
A
quality
D
maintenance
Enables reading and searching handwritten notes from GoodNotes on macOS, providing OCR text, search, and notebook management tools for AI assistants.
Updated 5 months ago (2026-04-05 22:49 UTC)
6
MIT
rm-brain MCP server
Note Taking Search
gabrielanhaia
A
license
Not graded
quality
B
maintenance
Enables searching and exploring handwritten reMarkable notebooks through a natural conversation with Claude Desktop, with full-text search, classification, and source citations.
Updated 2 days ago (2026-09-09 23:14 UTC)
9
MIT

reMarkable MCP Server

Why remarkable-mcp?

Quick Install

🔌 USB Web Interface (Recommended)

⚡ SSH Mode (Advanced)

☁️ Cloud Mode (Wireless)

1. Get a One-Time Code

2. Convert to Token

3. Install

Connection Modes

Automatic cloud fallback

OpenClaw Integration

Tools

Smart Features

Example Usage

Resources

OCR for Handwriting

Quick Setup

Default Behavior (auto)

SSH vs USB Web vs Cloud Comparison

Write Tools (Cloud, SSH & USB Web)

Disabling Write Tools (read-only mode)

Available Write Tools

Safety

Examples

Interactive Canvas App (MCP Apps)

Drawing and authoring from the canvas

Advanced Configuration

Root Path Filtering

Custom Background Color

Retry Configuration

Cloud Performance & Caching

Use Cases

Research & Writing

Daily Review

Document Search

Knowledge Management

Documentation

Development

Multi-transport smoke test

License

Available Tools

Output Schema

Output Schema

Merged PDF + Annotation Rendering

Response Formats

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Default Behavior (`auto`)