reMarkable MCP Server

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds context about return values (names, types, dates, tags) and the effect of REMARKABLE_ROOT_PATH, but does not exceed what annotations already imply for safety.
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-organized with usecase, instructions, parameters, and examples sections. Every sentence adds value, and the content is front-loaded with the primary 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?
Given the tool's simplicity (3 optional parameters, no required params) and the presence of an output schema, the description covers all necessary context: modes, parameter defaults, configuration note, and multiple examples.
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 description fully compensates by explaining the role of each parameter: path for folder navigation, query for search activation, tags for filtering. It also describes the interaction between parameters (e.g., query and tags working together).
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 is for browsing or searching the reMarkable library. It defines three distinct modes (browse, search, filter by tags) which differentiate it from siblings like remarkable_search and remarkable_recent.
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, including default behavior and optional parameters. It also mentions the REMARKABLE_ROOT_PATH configuration. However, it does not explicitly state when not to use this tool in favor of a sibling.
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 destructiveHint=false. The description adds behavioral details: returns summaries from multiple documents, limits on response size, OCR option, and tag filtering, without contradicting annotations.
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 uses structured XML tags (usecase, instructions, parameters, examples) for clarity. It is informative and well-organized, though slightly verbose in places but earns its content.
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?
With an output schema present, the description doesn't need to detail return values. It covers limits, parameters, and usage context well. Minor gap: it doesn't specify what 'summaries' entails exactly, but overall adequate.
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 <parameters> section fully describes all 5 parameters, compensating for the 0% schema description coverage. Each parameter's purpose is clear, and examples illustrate usage effectively.
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. It specifies searching document names and optionally content with grep, distinguishing it from siblings like remarkable_read or remarkable_browse.
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 <usecase> and <instructions> provide context for efficient cross-document search, with explicit limits (max 5 docs, first page ~8000 chars). It lacks explicit when-not-to-use guidance but implies alternatives via sibling list.
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 destructiveHint=true and readOnlyHint=false. The description adds valuable context: item moved to trash (cloud) vs marked deleted (SSH), confirmation requirement, and mode restrictions. This goes well beyond annotations.
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?
Structured with usecase, instructions, parameters, and examples. Front-loaded with purpose. Minor redundancy in instructions (e.g., 'DESTRUCTIVE operation' already implied by annotations), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers modal behavior, confirmation, and parameter usage. Since an output schema exists (not shown), return values do not need explanation. No significant gaps given the tool's simplicity.
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 schema has only one parameter 'document' with no description (0% coverage). The description adds meaning: 'Name or path of the document/folder to delete' and provides examples, compensating for the lack of schema description.
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 'Delete a document or folder on the reMarkable tablet.' This directly states the verb and resource, distinguishing it from sibling tools 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?
Extensive guidance is provided: destructive operation, recovery in cloud vs SSH, mode availability, and confirmation behavior including a flag to skip. However, it does not explicitly state when not to use it (e.g., preferring other tools for listing or reading).
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?
Discloses it updates parent reference (mutation). Warns about mode dependencies (not available over USB). No annotations beyond readOnlyHint=false, so description adds useful behavioral context. Could mention permissions or behavior if destination exists.
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?
Structured into usecase, instructions, parameters, and examples. Each section adds value. Slightly verbose due to XML tags, but concise in content. Examples are helpful.
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 prerequisites, modes, parameter details, and examples. Output schema exists but not shown; description adequately explains behavior for a move operation. No missing critical information.
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 coverage, description adds full parameter meaning: document as 'name or path' and dest_folder as 'destination folder path (use / for root)'. Examples clarify usage. Compensates for schema lack completely.
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 it moves a document or folder to a different location. Verb 'move' and resource 'document or folder' are specific. Distinguishes from siblings like rename or delete.
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?
Advises to first find the document with remarkable_browse(). Notes availability in cloud/SSH modes but not over USB. Implies usage context but lacks explicit alternatives or when-not-to-use scenarios.
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 declare readOnlyHint and idempotentHint, indicating safety. The description adds valuable behavioral details: documents sorted by modification date (newest first), optional preview of ~200 chars, and path restriction if REMARKABLE_ROOT_PATH is configured. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured using XML tags (usecase, instructions, parameters, examples) and is front-loaded with the primary purpose. Every sentence is informative and necessary. No wasted text.
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?
For a simple read tool with two parameters, the description covers all necessary aspects: purpose, usage, behavioral notes, parameter details, and examples. Output schema exists, so return values are already documented. The description is fully adequate for agent invocation.
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 description compensates by explaining both parameters: limit (default 10, max 50 without preview, 10 with preview) and include_preview (default False, includes ~200 chars). This adds meaningful guidance beyond the schema's type/default values.
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 your most recently modified documents.' It uses a specific verb ('get') and resource ('recently modified documents'), and distinguishes itself from siblings like 'remarkable_search' (search by query) and 'remarkable_browse' (browse folders) by focusing on recency.
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 usage context: 'Use this to quickly find what you were working on recently.' While it does not explicitly state when not to use or mention alternatives, the context is sufficient for an agent to understand appropriate use cases.
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?
Describes that it changes display name by updating metadata, mentions mode restrictions, and consistent with readOnlyHint=false annotation; adds value beyond 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?
Well-structured with usecase, instructions, parameters, and examples; every section earns its place without verbosity.
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 for a rename action: purpose, prerequisite (browse), parameters, examples, and mode restrictions; output schema present so return values not needed.
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 coverage, the description's <parameters> section explains both parameters (current name/path and new name), adding essential semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Rename' and the resource 'document or folder on the reMarkable tablet', distinguishing it from siblings like remarkable_browse 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instruction to find the document name with remarkable_browse() first and states availability across modes, though it does not explicitly list when not 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?
Annotations already mark the tool as readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds valuable context: pagination with 'more' and 'next_page' fields, OCR behavior based on environment variable, and content type behavior like 'raw' working without annotations. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with usecase, instructions, parameters, and examples. Each section is useful, though slightly lengthy. It is front-loaded with the usecase and instructions.
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's complexity (5 parameters, output schema exists), the description covers all aspects: purpose, pagination, content types, OCR, grep filtering, and references sibling tool for document discovery. It is complete without needing to explain return values due to output schema.
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%, but the description provides a dedicated <parameters> section explaining each parameter: 'document' as name/path (use browse), 'content_type' with enum explained, 'page' as page number, 'grep' as optional regex, 'include_ocr' default false. This fully compensates 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?
Description starts with '<usecase>Read and extract text content from a reMarkable document.</usecase>', providing a specific verb and resource. It clearly distinguishes from sibling tools like remarkable_search (searching) and remarkable_image (images).
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?
Instructions include pagination and content type usage, and mention using remarkable_browse to find documents. However, it does not explicitly state when not to use this tool or compare it to alternatives like remarkable_search.
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 provides extensive behavioral details beyond the annotations: it explains the returned capability matrix, the differences between transports, and the optional read-only mode. This significantly enriches the agent's understanding of the tool's behavior.
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 <usecase>, <instructions>, and <examples> tags. Every sentence adds value, and the most important content (purpose and capability matrix) is front-loaded. It is appropriately sized for the complexity.
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 (not shown but indicated), the description fully covers what the tool returns (authentication status, active transport, document count, capability matrix) and when to use it. Nothing essential is missing.
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?
There are no parameters, so schema coverage is 100%. The description correctly adds no parameter information, which is appropriate given zero parameters. Baseline for 0 params is 4.
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 uniquely identifies the tool's purpose among siblings, as no other tool serves this status-checking role.
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 explicitly says 'Use this to verify your connection, choose a transport, or troubleshoot.' It implies the appropriate context but does not provide explicit when-not or alternatives. Still, it offers clear guidance for when to invoke the tool.
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 important behavioral context beyond annotations: it notes transport-specific behaviors (parent_folder/document_name ignored in USB web) and the requirement for write mode. This complements readOnlyHint=false.
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 XML tags for usecase, instructions, parameters, and examples. It is front-loaded with the key purpose and every sentence adds value. No waste.
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's complexity (three transports, multiple parameters with conditional behavior), the description is complete. It covers formats, transport modes, parameter behavior, and requirements. Output schema exists so return values are not needed.
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 coverage, the description fully compensates by explaining each parameter: file_path (absolute path, supported formats), parent_folder (default '/', honored in cloud/SSH, ignored in USB web), document_name (default filename without extension, honored in cloud/SSH, ignored in USB web). This adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Upload a PDF or EPUB file to the reMarkable tablet.' It specifies the verb (upload), resource (file to tablet), and format restrictions. This distinguishes it from sibling tools like remarkable_read 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a use case and instructions that explain when to use this tool (uploading local files, only PDF/EPUB, works in three transports) and mentions that it requires write mode. It does not explicitly say when not to use or provide alternatives, but the context is clear.
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, destructiveHint=false, idempotentHint=true. The description adds valuable behavioral details: response formats (embedded resource vs compatibility mode), background handling with defaults and env var, OCR behavior with optional LLM sampling, and the effect of render_merged. 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 sections for use case, instructions, parameters, and examples. It is front-loaded with the main purpose. However, it is somewhat lengthy due to the detailed parameter explanations and examples, but this is justified by the complexity.
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 7 parameters, no output schema, but the description covers return values (embedded resource with blob/text content, compatibility mode with JSON), edge cases like transparent backgrounds, and special features like OCR with different backends. It is comprehensive for an image retrieval 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 must compensate. It does so thoroughly by explaining each parameter (document, page, background, output_format, compatibility, include_ocr, render_merged) with defaults, use cases, and even additional info like the environment variable for background color. This fully compensates for the lack of schema 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 clearly states 'Get an image of a specific page from a reMarkable document,' specifying the verb (get), resource (image of page), and distinguishing from siblings like remarkable_read (text) and remarkable_browse (browse files). It also provides use cases such as viewing hand-drawn diagrams and sketches.
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 description provides explicit use cases and directs users to remarkable_browse for finding documents. It explains when to use features like render_merged for annotated PDFs and OCR for text extraction, giving clear context on when this tool is appropriate.
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 declare readOnlyHint=true, and description confirms read-only nature. Also describes the fallback behavior (embedded PNG for non-interactive clients) and the interactive panel for supporting clients, adding value beyond 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?
Description is well-structured with clear sections (usecase, instructions, parameters, examples). Every sentence is informative and concise, no fluff.
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?
Despite no output schema, the description explains the return behavior (PNG for non-interactive clients) and covers usage, parameters, examples, and differentiation from siblings. It provides a complete understanding for an agent.
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 explains both parameters: document is a name/path with recommendation to use remarkable_browse, and page is 1-indexed with default 1. This adds meaningful context beyond the schema structure.
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 it opens a reMarkable page in an interactive canvas viewer. Distinguishes from sibling remarkable_image by noting that for plain image extraction without the interactive surface, the user should use remarkable_image instead.
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?
Explicitly states that this tool is the entry point for the interactive viewer, describes behavior on different clients (MCP Apps vs. non-MCP Apps), and provides alternative tool (remarkable_image) for a different 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?
Discloses behavioral traits beyond annotations: folder creation effects differ by mode (cloud sync vs SSH restart), and USB limitation. No contradiction with readOnlyHint=false annotation.
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, examples. Every sentence is informative with no redundancy. Efficient for agent consumption.
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 2 parameters, existing output schema, and annotations, the description fully covers mode-specific behavior, limitations, and parameter details. No gaps.
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?
Though schema has 0% description coverage, the XML-like <parameters> section adds meaning: explains folder_name and parent, with default value for parent and examples showing 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 'Create a new folder on the reMarkable tablet.' It distinguishes from sibling tools by specifying modes (cloud/SSH vs USB) and behavior. Examples further clarify purpose.
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?
Explicitly states when to use (cloud and SSH modes) and when not to use (USB web interface). Also notes SSH mode requires xochitl restart, providing clear context for invocation.
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

Copy to your README.md:

[![remarkable-mcp-http- MCP server](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-http- MCP server](https://glama.ai/mcp/servers/rbonitz/remarkable-mcp-http-/badges/score.svg)](https://glama.ai/mcp/servers/rbonitz/remarkable-mcp-http-)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rbonitz/remarkable-mcp-http-'

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