reMarkable MCP Server

by rbonitz

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
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.
Average 4.7/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

reMarkable MCP Server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![reMarkable MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/rbonitz/remarkable-mcp-http-/badges/card.svg)](https://glama.ai/mcp/servers/rbonitz/remarkable-mcp-http-)

Score Badge

Copy to your README.md:

[![reMarkable MCP Server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/rbonitz/remarkable-mcp-http-/badges/score.svg)](https://glama.ai/mcp/servers/rbonitz/remarkable-mcp-http-)